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: June 2009

News of Michael Jackson's death blazes across the web--what if it were a hoax?

Over at the SEOmozBlog, Danny Dover has a really interesting post about how, and how fast, the news of Michael Jackson's death travelled across the web. I won't go through it here, but it's a fascinating read. Less than an hour after the 911 call the news was appearing on the web. Less than three hours after the call and Twitter was a little sluggish with all the happenings (approximately 1500 mentions per minute of Michael Jackson's death), whereas MSNBC, the first "traditional" news organization to confirm his death, was just posting the first confirmation.

So what does this have to do with security, really? Well, not much on the face. But this information travelled so amazingly fast, I couldn't help but wonder what would have happened if it were all a big fake--if the earliest source(s) of information on this story were either made up or placed with malicious intent by insiders or hackers? It seems to me that a well-orchestrated hoax might get picked up by some minor celebrity news sites, then a few larger ones, maybe Digg, and from there the Twitter blaze seems inevitable. How many users could be duped into following links to a "story" (through bit.ly or tinyurl.com of course) before it can be investigated, denied and squashed? I'm betting a lot.

We have read countless stories of scammers/spammers/phishers using hot news stories (Iran, for example) in order to drive traffic to their malware, but have there been any instances of them faking potentially hot news for this purpose? I'd love to hear of any that have already happened--but if there are none, I'm betting one will be here soon.

Labels: Malware| phishing

Uncharted Territories: the personal-corporate-social-web-mashup

Corporate web communications have grown from simple web pages to massive and complex applications. The security department has mostly kept up and maintained a secure perimeter—even when that perimeter included outsourced and vendor systems. Contracts were in place, systems were secured, and life was good—even when the executives had their own blogs.


But just when everyone was getting comfortable again--enter the social web: MySpace, Twitter, and Facebook. People started using them and corporations followed.  Born of this are the corporate MySpace pages, Facebook groups, Facebook fan pages, management’s Twitter accounts, LinkedIn recruiting pages and more…


Did you see what happened there? No? It’s okay, neither did the security department.


So what was it? The customer contact point shifted from the corporate web environment to one controlled by a third-party.


Unlike most arrangements made with third-party vendors, this relationship is likely not covered by any type of contract, agreement or partnership. There is no guarantee for reliability, privacy, security or any type of regulatory controls. Your corporate users/administrators, as well as your customers, are bound by the third-party’s terms of service and policies, not yours, and you are also at their whim with regard to functionality and design.


These are no small issues when you consider the spider-web of laws, regulations and agencies that may cover many large businesses: Sarbanes-Oxley, HIPAA, GLB, etc. The security team, human resources and PR/brand all have a vested interest in keeping your sites and customer information secured, protected and private, and they just lost control of a key piece of the infrastructure.


This is not a completely theoretical risk. Looking at the news for the past few years, it’s easy to come up with examples that could have business, customer or employee impact. Even if no laws were violated or charges filed, in the internet age a negative story can spread like wildfire and damage brand.


Here are a few quick examples:


These are simply a few recent examples, but represent the tip of the iceberg. It’s hard to find news stories of confidential or proprietary corporate information posted to these sites, but you can safely bet it happens.


As marketing and PR types take a bigger interest in these channels to reach additional markets, and more and more users flock to these sites, the corporate presence there is going increase drastically.


So what should a company do? With regard to employees, here are a few suggestions:


  • Remind employees it is their responsibility to safeguard corporate and customer information.
  •  Incorporate messages about social networking into existing employee training and policies, and if applicable, give employees refresher courses.
  • Ensure employees realize the internet isn’t actually anonymous, and that they should behave ethically and in a manner that that doesn’t reflect poorly on themselves or the company.


If the company is creating an official presence on third-party web sites, some additional suggestions come to mind:


  • Determine the proper ownership for these channels—perhaps marketing or public relations—and establish a centralized point of contact.
  • Implement policies, guidelines and/or a code of ethics which clearly determine what information can and cannot be posted, and have a review procedure for anything questionable.
  • Implement policies/procedures for managing accounts and passwords to third-party systems, which include controls for changing passwords after employee attrition, choosing strong passwords, etc.
  • Implement procedures for monitoring the sites on a regular basis to ensure the messages, conversations and the brand “image” are appropriate (this can be contracted to other parties).
  • With the legal department, review the terms and conditions of the web site to look for potential pitfalls with regard to marketing through the site as well as ownership of uploaded content.
  • Thoroughly investigate privacy and security settings on the web site, and determine which should be enabled to best protect the company, customers and the user accounts.
  • If any relationship becomes mission critical or an important piece of the business, pursue contracts with the site operators which attempt to establish things like official support, uptime guarantees, additional security features, etc.   

These may all seem like daunting tasks, but any company with even a partially mature security department and polices should be able to integrate these types of changes fairly easily—in almost every case these are simply extensions, additions or clarifications to things already present in the corporate culture.


Given the immense popularity of these sites and their growth rates, the problem isn’t going away any time soon. Before the next wave of change comes to the internet, social networking policies and changes should be dealt with in a way that respects what employees do in their off-hours, protects the company and provides a new opportunity for corporate growth. The company that sticks its head in the sand may find itself in a nasty situation that could have been easily avoided with a little forethought.

Top Five Web Application Vulnerabilities 6/08/09 - 6/23/09

1) F5 Networks FirePass SSL VPN Unspecified Cross-Site Scripting Vulnerability

F5 Networks FirePass SSL VPN is susceptible to a Cross-Site Scripting vulnerability.  If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. An update which resolves this issue has been released. Contact the vendor for more details.


2) ModSecurity SQL Injection Rule Security Bypass Vulnerability

ModSecurity is susceptible to a SQL Injection rule security bypass vulnerability due to improper validation of user-supplied input.  An attacker can leverage this to bypass security restrictions and perform a number of web-application attacks.  A fix has not yet been released. Contact the vendor for additional information.


3) Apache Tomcat 'RequestDispatcher' Information Disclosure Vulnerability

Apache Tomcat is susceptible to an information disclosure vulnerability. Successful exploitation would give an attacker access to sensitive information which could likely be used to conduct more damaging attacks. Updates which resolve this issue have been released. Contact the vendor for further information.


4) FireStats 'firestats-wordpress.php' Remote File Include Vulnerability

FireStats is susceptible to a remote file include vulnerability due to improper validation of user-supplied input. Successful exploitation could lead to a complete compromise of the application and underlying system.  The latest version (1.6.2) resolves this issue. Contact the vendor for more information.


5) Kerio MailServer WebMail Cross Site Scripting Vulnerability

Kerio MailServer WebMail is susceptible to a Cross-Site Scripting vulnerability. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site.  Updates which resolve this issue have been released. Contact the vendor for further details.





Hello darknets, my old friend...

Billy Hoffman and Matt Wood of the HP Web Security Research Group are generating serious heat with their upcoming BlackHat USA presentation which will detail their browser-based darknet. Articles on Dark Reading, Forbes.com, and Slashdot are just the beginning. Why the buzz? Well, darknets are virtual private networks where users only connect to other 'trusted' users. Darknets normally require installation of some sort of client-side software, firewall configuration, and all other sorts of rigmarole. What Billy and Matt have done is to create a darknet that gives users a way to communicate and share files anonymously just using a browser. It's impressive stuff. Check out the articles here, and stay tuned for more details:











Labels: Darknet

Top Five Web Application Vulnerabilities 5/26/09 - 6/07/09

1) Sun Java System Web Server Reverse Proxy Plug-in Cross-Site Scripting Vulnerability

Sun Java System Web Server is susceptible to a Cross-Site Scripting vulnerability. If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Updates which resolve this vulnerability have been released. Contact the vendor for further details.


2) PHP-Nuke 'main/tracking/userLog.php' SQL Injection Vulnerability

PHP-Nuke is susceptible to a SQL Injection vulnerability. Successful exploitation could give an attacker the means to access or modify backend database contents, or in some circumstances be utilized to take control of the server hosting the database. A solution has not yet been released. Contact the vendor for additional information.


3) phpBugTracker Multiple SQL Injection Vulnerabilities

phpBugTracker is susceptible to multiple SQL Injection vulnerabilities.  SQL Injection can allow an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system. Solutions have not yet been released. Contact the vendor for more information.


4) Apache Tomcat Form Authentication Existing/Non-Existing Username Enumeration Weakness

Apache Tomcat is susceptible to a username-enumeration weakness because different login results can be exploited to determine whether usernames are valid. Updates which resolve this issue are available. Contact the vendor for additional details.


5) IBM FileNet Content Manager Cached Subject Security Bypass Vulnerability

IBM FileNet Content Manager is susceptible to a security bypass vulnerability that may allow access to sensitive information. Fixes which address this issue have been released. Contact the vendor for further information. 


Talking Headers: Part 3: The Fun

In Part 1 of the series on interesting headers, I talked about leaking hostnames. In Part 2, it was PHP errors. In Part 3 I bring you... the funny stuff. Not funny, like how Mark Mcgwire's rookie card is now $5 on ebay compared to the hundreds it once was (and that I have 5 of them for some reason), but funny like watching a 1984 episode of Miami Vice and wondering how humanity survived the clothing and hair.

Note, a link to each site is on the header name:

I thought "x-hackers" typically got government jobs, or at least wrote books?

At least these guys at admit they cobbled it together... but gave themselves credit nonetheless:

Nick, Mic, or Andy (or all three?) must also get the warm fuzzies from Ashley, beacuse they've also got:

I'm not quite sure what to make of this next one, but I'm pretty sure it freaks me out just a little, like clowns. Actually, clowns freak me out a lot:

And finally... one that should need no explanation or almost-witty comment:

There are certainly tons more funny or odd headers out there, and I tried not to duplicate those in Andrew Wooster's post--what else have you seen?

Labels: Headers| HTTP| Research

Schneier on security in the age of cloud computing

Bruce Schneier offers a great perspective on why security is even more important in the age of cloud computing. As the expression goes, three can keep a secret if two of them are dead. In a nutshell, cloud computing forces you to increase the number of people you have to trust to keep the secret.





Talking Headers: Part 2

While my rookie Mark McGwire cards aren't appreciating at all, my header collection is.  Check these actual headers out:

  • php warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20020429/mysql.so' - Cannot open "/usr/local/lib/php/extensions/no-debug-non-zts-20020429/mysql.so" in Unknown on line 0

  • php: Error parsing /usr/www/users/bob/cgi-bin/php.ini on line 125

  • php warning: Function registration failed - duplicate name - pdf_new in Unknown on line 0, Function registration failed - duplicate name - pdf_delete in Unknown on line 0...

Yes, those are actual HTTP header names and values. That's some serious ugliness right there. Why PHP would be reporting errors through the headers I can only guess--but it is.

Finding any information on this via a search engine has proven impossible, as it's polluted with PHP syntax error messages and relevant discussions. So, if you have any ideas as to they why/how of this, I'd be interested to hear them.

And of course, my shameless product plug: WebInspect will alert on these.

Labels: Headers| HTTP| PHP| Research

Hacking has evolved

This is a great article about the value of a hacked PC to an attacker. While this focuses on personal PCs, all of these reasons can also apply to compromised web servers. Remember, web hacking has evolved. Script kiddies began by defacing web sites and conducting other forms of cyber vandalism. As applications grew in complexity, so did the attacks. Suddenly, it was all about the data as hackers learned how to extract the data contained in applications via SQL Injection and other methods. Now, though, the attacks are designed to compromise a web server and use it as a platform to spread malware (or worse) and conduct other crime. And as the threats grow, so does the need to integrate security throughout the application lifecycle.    


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.