HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Displaying articles for: January 2009

Changing Road Signs is Dangerous. Zombies are not funny.

Zombie warning signsLike mentioning a bomb while in the TSA line, there are some things you just don’t joke about. As any sane person with a Zombie Escape Plan (ZEP) will tell you, you’ve got to heed warnings and take immediate and drastic measures to ensure survival—cutting across lanes, the center divider, and heading in the opposite direction would be a good start in this situation.


So, I urge these “hackers” to please refrain from putting up messages about zombies. Or robots. Or aliens. Anything else is fair game, including… puppies, kittens and the geniuses behind the “credit default swap.”


Well, perhaps a better solution would be to change the default passwords, or locking the control panels up?


We’ve been preaching the changing of defaults in the security business for years, and it has finally taken root in the rest of IT and in many cases our business units. But it seems the message isn’t being heard outside office environment. However, end-user education is only one step in the process—manufacturers of all types of equipment need to take security seriously.


As more and more traditionally non-computerized equipment is attached to computers (and networks) this type of issue will be on the rise. Sure, a road sign hack seems funny, but what important message was there before? What if a computerized crane were recalibrated in some way to make distance measurements inaccurate? Is there a “secret” string of zeroes that will let you mess with the software running your shiny new hybrid?


Who knows the answers to these things… manufacturers, of course! Only by forcing their end-users to change default passwords, or better yet, not having them at all, can we prevent the “easy hack” that allowed the fake zombie warning. After all, you don’t need to educate them if they have no insecure choice.


In the meantime (and just like security testing), sane people please adjust your ZEP to account for false positives.  The rest of you: don’t cry zombie.



Health Information Technology Upgrade Included In Stimulus Package

In high school and college I worked as a pharmaceutical technician.  We entered every prescription in our new computer, but we still listed each prescription on a simple ledger sheet, too. In some cases, that information went back over 50 years. It was easy to see from looking at the record if anything was potentially amiss with a new prescription. We haven't progressed very far when that still seems to be the best method of archiving medical information. It's incredibly telling when only 17% of doctors utilize computers in their practice. No wonder that a visit to the same facility 18 months apart won't stop you from having to provide your entire medical history all over again. And just try avoiding a fresh set of x-rays when you switch dentists. Long story short, there is a definite, urgent need for upgrading our medical systems to be both more cost-effective and to provide better overall health care.  But while doing that, security needs to be baked in, not brushed on, as the expression goes. Right now, there is still no good answer as to how you allow access to the most sensitive of data while also preventing unauthorized intrusion. Congress has yet to answer that. PCI hasn't stopped credit card information data breaches, and it's highly doubtful that HIPAA will prevent security issues from arising when this new method of medical record storage is implemented. Regardless, with a massive implementation like this on the horizon, security professionals can at least feel good about one form of security...what they have in their jobs.



70 Of Top 100 Web Sites Spread Malware

According to Websense, Inc, seventy percent of the top 100 web sites  (according to Alexa)  either hosted malicious content or contained hidden links designed to redirect users to malicious sites. That's an amazing statistic. In just six months, the percentage of compromised sites went up 16%, so it's more than an anomaly. The top 100 sites are based on traffic, so it's not like these were chosen haphazardly. There are a lot less 'obvious' risky sites in their current top 100 lists than I would have thought. It's primarily a blend of search, social networking, and major retail sites. In other words, they make their point that any site can be dangerous.

When you couple that with the major data breaches announced this week and the state of the economy in general, this has the potential to snowball into something ugly, even if it's just a general sense on the part of consumers that the web is no longer safe to use. How will average users react when they can no longer tell good sites from the bad? It used to be enough to stay away from  'dangerous' sites...a user could be relatively assured his information was secure. Now, any site can be malicious. If this story does manage to gain traction,  I think consumers will ultimately react like they've done in the real world...use it as yet another reason to delay an unnecessary purchase.

What are the attackers after? Basically, they're either installing data-stealing trojans, or using the web server as a platform to launch another wave of attacks against the thousands of users who visit the web application. It's interesting to see that attacks have shifted from using compromised computers as botnets, and now are focused on utilizing compromised web servers.


Your online persona –trouble for you?

I keep reading in articles (which are generally meant to scare “regular people”) about how you should limit the personal information you reveal to websites like Facebook, LinkedIn, etc. A friend of mine, when job hunting, even password protected his website and requested cached pages be removed from various engines.


Couple this with some recent posts I’ve seen about people search engines (which love to say they search the “deep web”) getting better at aggregating this information, I decided it was the time to see what was out there about me.


So armed with my name, an email address, and the name of the town I live in (none of which is too hard to track down), I decided to see what I could find out about myself out there on the tubes. The results surprised me.


My first stop was pipl.com, which can search by email, name (with city/state), username or phone. Pipl searches various social networking sites, as well as common web resources. From MySpace, it claimed that I live in Cranston, RI (not true—and I told it so in my search) and that I am a serious Goth who is a Guitar Hero fanboy (not true. OK, I do enjoy a little Guitar Hero). It pulled up my LinkedIn profile accurately enough, and some other true info.


When I searched Pipl by email address, oddly, I got back an error that said “No results found for <redacted>@comcast.net.” The interesting thing is that the comcast.net address isn’t remotely close to what I typed in. So I tried it again, and this time it found no results for “Masongeary.”  Apparently, this is what others are searching on (I contacted Pipl and within the hour they responded that the issue was resolved). The third time, it actually pulled up some old mail list posts that were mine. They can’t even keep your search query straight, let alone the info about you.


Next up, I tried 123people.com. This one pulls back pictures of “me”… interesting:

Pictures of Chris Sullo?

Think I’m in there? Think again (though one of those faces looks oddly familiar…hmmm...).  They also got some info correct, but added to my online persona that I’m an indoor track runner (nope, sorry) and a soccer player (nope, sorry again). Apparently, I like to upload videos to YouTube (which I’ve never done).


Next up was Spokeo. This site has a special section for HR Recruiters… interesting. It claims I have three social networks, and I can tell that one of them is correct—but the other two I’m not sure about. It wants greenbacks to tell me for sure, so there’s where my experiment ends with this site.


I tried several others. Zoominfo.com says I worked at “Massachusetts Maritime.” Isearch.com thinks I may live in Nashville, Los Angeles, or perhaps my name is actually “Lil Chris.” Spock.com suggests I own a spa or maybe a law firm.


And The Google?  Well, it makes some of those same mistakes… and the image search is no better than 123people.com’s (it pulled up a bunch of other guys, including a high-jumper—yeah right!).


So what’s the point of all this? Good question. Some of the information I found out about me is true, and some of it I never knew—I’m actually beginning to feel a little like Ed Norton in Fight Club. Armed with my email address and/or name, what would a recruiter or hiring manager think they found out about me?  It’s not news to me that there is a high concentration of the “Sullo” surname in New England (where I am also from), so confusion seems highly likely. As a matter of fact, I once unexpectedly found myself on a conference call with another Chris Sullo (from NY) who also works in security, if you can believe it. Could some other “Chris Sullo” have an impact on a future job prospect? Could I have a negative impact on him (this seems more likely)? 


What about identity theft? Sure, some breaches only have a tiny bit of info, but… how much more do they need when your address is out there, your mom’s maiden name is on Geni, and your date of birth and names of y our kid/dog are proudly displayed on Facebook?


The privacy advocate in me (which generally rules the roost) is thrilled there is a bunch of confusion. However, as the web gets “deeper” and more information moves online (President Obama’s digital healthcare initiative, anyone?), this is going to be a larger and larger problem.  If we’re not careful about the data we give out to public sources, it will be relatively easy for someone to gather enough information to commit fraud or, at the least, impact decisions on jobs and security clearances.


Maybe it’s time I start using a different email address for each web site? A service to do this sort of thing (with less pain than doing it manually) and aggregate my mail would be nifty.


For now, I’m just going to change my bio to read: Chris Sullo, the high-jumping, soccer playing, track running, spa and law firm owning, Guitar Hero loving Goth who goes by “Lil Chris” and may or may not live in Los Angeles, Cranston or Nashville, and could work at either Massachusetts Maritime or Hewlett-Packard.

Sun releases Netscape Enteprise source--let the bug hunt begin?

Sun Microsystems announced today that Netscape Enteprise Server, one of the original grand-pappys of "modern" web servers (which excludes NCSA--sorry fanboys... I know you're out there), has been released under the BSD license. This isn't the really old one that (hopefully) no one uses, but the modern version, now called JES Web Server (part of the OpenSolaris Web Stack). Yep, it was also iPlanet for a bit. And SunONE. And possibly still Sun Java System Web Server. And probably a few other names people with too much time on their hands will find buried in the source.

No matter what you call it, it will be interesting to see over the next few days/weeks/months to see what the security research community does with the source. I suspect we'll at least see a short-term uptick in the number of vulnerabiltiies for the server as people start looking into it and running their analysis tools. Corporations running the Java System Web Server should keep a keen eye on the Sun Alerts.

Some links for you:

Paris Hilton's Web Site Infecting Users

Paris Hilton’s website was infected with some pretty nasty malware over the past weekend. ScanSafe (who discovered the compromise) said that over 15,000 sites were detected to have this malware installed, including an ad on MLB.com.   So far, most AV products aren't stopping it, either. Visitors to  parishilton.com were prompted with a sham pop-up that they needed an 'upgrade' to continue browsing the site.  Both the 'Cancel' and 'OK' options caused the malware to be downloaded. According to ScanSafe, only a hard quit (CTRL-ALT-DELETE) would stop it from occurring (by closing it via the Task Manager? Not sure what that really means).  Basically, an I-frame was embedded in the site, which pointed to a .pdf on a malicious site (you69tube.com). Once the downloader was executed by clicking ‘OK’ or ‘Cancel’, a Trojan rootkit was installed on the user’s system.  A normal user would have had their banking credentials and personal information put at risk (software designed to capture banking information was the first malicious package installed). Enterprise users risked having their HTTP and network traffic redirected and intercepted. That's just as bad as it sounds. The working theory now is that the original vulnerability in the site was in the open CMS package Joomla...more than likely via our old friend, SQL Injection.   Seems the operators of the site haven’t weren’t keeping up to date with their patches. <br><br>
How can you protect yourself? For starters, businesses should block youtube69.com. Users should realize AV products are no guarantee against infection and should stick to trusted sources when upgrading anything. Be aware when visiting obvious targets (celebrity sites, etc.) of the potential risks.




The CWE/SANS Top 25 Most Dangerous Programming Errors

This week saw the release of the “Top 25 Most Dangerous Programming Errors” list from MITRE and SANS.  At first skim, I nearly discarded it as just an effort to pad resumes—after all, do we really need another “top X” list (every group with a barely pronounceable acronym has their own)? Weighing heavily into that opinion is that of the Top 25, there is some serious overlap that, I think, won’t really help developers.


For example, CWE-20 is “Improper Input Validation” and CWE-116 is “Improper Encoding or Escaping of Output.”  If developers fully understand these two and the associated risks of not doing them, they will almost certainly resolve several of the other 25, including:

-          CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')

-          CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')

-          CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')

-          CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer


Isn’t “Failure to Preserve SQL Query Structure” just another way of saying that you didn’t properly filter and encode tainted data? MITRE’s Steve Christey, in discussing the CWE Top 25, says the following about mixed reviews on including both input validation and encoding:


Part of it seems to come down to different ways of looking at the same problem. For example, is SQL injection strictly an input validation vulnerability, or output sanitization/validation/encoding or whatever you want to call it? In a database, the name "O'Reilly" may pass your input validation step, but you need to properly quote it before sending messages to the database. And the actual database platform itself has no domain model to "validate" whether the incoming query is consistent with business logic.

I’m not disagreeing with Steve that they should both be included, but rather that they should be included rather than the CWE numbers listed above.  After all, the programming error is not properly filtering and/or encoding tainted data, the resulting vulnerability is SQL injecting, Cross-Site Scripting, etc.


One other thing struck me as odd, which is the “Remediation Cost.”  This seems like sheer nonsense—it’s not something a document can define across the board without regard to the underlying application or technology, not to mention the (corporate) environment one has to work in. Is input validation remediation cost really “Low” when you might have to first educate your developers, make sure they understand the context and application logic (to make smart decisions about proper changes), and finally go through testing to ensure nothing is broken as a result? Likely not.

 All that said—and those are things that may be changed in future versions of the list—my opinion has softened to where I’m now in “mixed bag” mode. This is a 1.0 release of a document, and while the authors certainly hope it is perfect, the first release of anything almost definitely isn’t.  


The truth is that any effort which gets more security knowledge into the heads of developers is a Good Thing and, hopefully, successful at causing applications to be more secure than they were. Also, any type of release that makes headlines outside of the security industry—where it may trigger a positive reaction in a programmer or developer—is definitely a win for security.  Certainly New York State took notice, now let’s hope their software suppliers do as well.


These are just a few issues that came to mind when reading the list. Gary McGraw wrote “Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work,” and while I don’t agree with everything he says, there are a few that make reading the list worthwhile.  I’ll point out #8:


Automated tools can find bugs — let them. Teaching all developers the 700+ bad things in the Common Weakness Enumeration (or the even larger set of permutations allowed by languages like C++) is a futile exercise. We can start by using static analysis tools to remember all of the potential bugs and alert us to their presence.

I wholeheartedly agree with the second part of this one, and not just because I work for a company that sells automated security tools. With the complexity and sheer volume of code in existence these days, automated tools used throughout the dev lifecycle are a cost effective way to catch these issues.


I disagree with Gary that educating developers is a futile exercise—in fact it should be a requirement in every shop and school. Even if the developers are still not great at avoiding the problems in the first place, when the automated tool spits out a list of potential issues, an educated programmer will need to determine if/how/where to make a code change to fix the issue. Improper fixes have lead to dozens of incomplete bug remediations, and in some cases, additional vulnerabilities.


Anyway, to summarize (since I rambled on), I think the CWE Top 25 Programming Errors list is a little flawed, but given the attention it has received this week I can only applaud the efforts of MITRE and SANS for drawing more attention to security. After all, we’re all (ok, mostly) working toward the same goal: secure applications.



Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.