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

Top Five Web Application Vulnerabilities 8/17/09 - 8/30/09

1) Adobe Flex SDK 'index.template.html' Cross Site Scripting Vulnerability

Adobe Flex SDK is susceptible to a Cross-Site Scripting vulnerability. This can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials in context of a web application built using the SDK. Updates which resolve this issue are available. Contact the vendor for additional information.


2)Adobe ColdFusion Multiple Vulnerabilities

Adobe ColdFusion is susceptible to multiple vulnerabilities including instances of Cross-Site Scripting, HTML Injection, session fixation, and information disclosure. Victims can have their session hijacked and give an attacker unauthorized access to the application. Other possible attacks include having content added into a web server’s response, which can then be used to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. The information disclosure vulnerability could also reveal sensitive information which could  lead to more damaging attacks. Updates which address each of these vulnerabilities are available. Contact the vendor for more information.

http://www.securityfocus.com/bid/36046 (HTML Injection)
http://www.securityfocus.com/bid/36096  (Double-Encoded NULL Character Information Disclosure)
http://www.securityfocus.com/bid/36056  (Cross Site Scripting)
http://www.securityfocus.com/bid/36053 (Multiple Cross-Site Scripting)
http://www.securityfocus.com/bid/36054 (Session Fixation)

3) Adobe JRun Multiple Unspecified Cross-Site Scripting Vulnerabilities

Adobe Jrun is susceptible to multiple instances of Cross-Site Scripting. 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 issue are available. Contact the vendor for more details.


4)  IBM WebSphere Commerce Unspecified Information Disclosure Vulnerability

IBM WebSphere Commerce is susceptible to an information disclosure vulnerability.  An attacker can gather sensitive information, possibly leading to brute-force attacks against user accounts. Updates which resolve this vulnerability are available. Contact the vendor for further information.


5) Xerox WorkCentre Web Services Extensible Interface Platform Unauthorized Access Vulnerability

Xerox WorkCentre is susceptible to a unauthorized access vulnerability. An attacker can leverage this vulnerability to access the device’s configuration settings and possibly acquire customer passwords. An advisory and patch which resolves this issue have been released. Contact the vendor for additional details.


stop the alert();

For nearly a decade, those of us in web security have been doing a disservice to ourselves and, more importantly, our customers. Like Pavlov, we've trained people to respond to certain stimuli. Rather than a bell, we've relied heavily on the alert() dialog box to prove our point--that cross-site scripting is possible.

And why shouldn't we (assuming we're not doing hardcore pentesting where we really need to abuse it)? It's easy to exploit, it's easy to explain, and most importantly: it's in your face.

I'm not saying everyone does it but... everyone does it. We've all proven our point, at one time or another, to a skeptical business person or developer by sending the trivial-but-hard-to-ignore link containing a <script>alert('Vulnerable+to+XSS' )</script> variant. Don't deny it, you know you have.

So what's the end result of all this alert() training? "There was no popup, therefore it's a false positive."  I have heard this more times than I want to admit. When I hear this, I have to sit back and wonder where we went wrong. When did that (business security consultant|developer|manager) become a dog salivating for another alert? When did I let it happen?

At this point you of course have to prove it's somehow dangerous, which means taking time to make the alert work or some sexier attack. Did the developers clobber alert() for some reason (Facebook), or does it need a simple tweak? Who knows... the point is, it takes time. The guy that can fix it didn't just look the source and say "oh crap, the kitchen sink is making it through unfiltered" simply because he didn't get smacked in the face with an alert box.

So what do we do? Well, there's no going back in time... but consider using other examples when you can. Liberal use of the <blink> and <marquee> tags with a "business has closed due to pending litigation" message or a redirect to a competitor's website will often do just as well. Or maybe someone should make an injectable version of jsAscii that replaces all the images on a page (that would be pretty sweet).

So stop demonstrating XSS with alerts and stop being lazy. Mix it up a little and give some different examples--in the end it will make all of our lives easier, our sites more secure, and just may stop that infamous developer who thinks the fix is to filter out the word 'alert'...

One vulnerability can be your downfall

Court papers recently filed in conjunction with the indictment of Albert Gonzalez reveal that SQL Injection attacks were behind the data breach that allowed hackers to steal massive amounts of data from Heartland Payment Systems, TJX, and other businesses. Over 130 million credit and debit card numbers were ultimately obtained, all because of the failure in a web application to properly validate user-supplied data. The level of knowledge required to enact such devastating attacks continues to plummet, and the criminal desire behind them continues to rise. It's amazing what could have been prevented with proper application security in place.



This attack also perfectly illustrates how exploitation techniques have changed in just the past few past years. Once upon a time, hackers were content to steal the data from a database and then leave. Now, they infect the system with malicious software and perpetuate attacks across a much larger time frame, exponentially escalating the damage. The harm that can come from one relatively simple exploitable hole is phenomenal. Keeping your web applications secure has never been more important.  



Jessica Biel ‘most dangerous’ celebebrity search name

Jessica Biel is the most dangerous celebrity on the Internet, at least as far as searches go. According to McAfee, a whopping 20% of searches for Jessica Biel images, videos, and dowloads lead to sites that contain malicious software of one type or another.  It might not be very sophisticated, but it's certainly effective. Cybercriminals are masters of manipulation if nothing else. As long as users are 'too quick to click,' as the expression goes, this type of attack will continue to entice large numbers of victims into downloading malware and infecting their systems.



Labels: Malware

ASC Products are "Production Ready"

A recent blog post from Jeremiah Grossman caused a bit of discussion this past week. Jeremiah was trying to create a much needed chart showing all the different vendors who have an application scanning offering be it SaaS or a product, and be it dynamic scanning or static/source scanning. WAF vendors were not included. He rated each offering against a set of criteria. One criteria "Production Safe" struck me as a vague metric. Certainly scanning production systems has additional challenges that scanning internal test systems do not. How easily a product can be configured to overcome these challenges is critical. However, there was no clarification about how the chart defined "Production Safe."

In the comments of the post, Jeremiah stated:

Adjusting scan speed, simultaneous thread, and ensuring the tests themselves do not have active payloads is most common. Also very important is having a person mark forms as safe for testing. I'd argue though that these steps are function of people/process and not a feature of the scanner itself. Hence, no check mark.

This last sentence concerned me. It seemed to imply that scanners are not "production safe"... it's the people that use them that make them "production safe" or not. So I emailed Jeremiah for clarification.


I want to make sure I understand. Does your benchmark that "these steps are function of people/process and not a feature of the scanner itself" require a human driven SaaS offering to receive a checkbox under "Production Safe?" In other words by your criteria is it impossible for a product to be "production safe?"


I want to be careful as not to suggest my definition is set is stone. Im open to a better or more refined one. Having said that, I'd say if a scanner is testing forms blindly (for example / some links too) without human decision making, then this is inherently dangerous. As is injection executable code.  If however the forms are custom configured by "someone", then the tool can in theory run reasonably safely. This combo can be delivered by a service (SaaS/Consultant) in a package, but to the best of my knowledge products don't ship with enough AI to do it autonomously. I guess this is the crux of my distinction.

I responded:

Software is never going to, out of the box, "know" what it should and should not audit. It requires intelligence to properly configure and launch. Whether that intelligence is provided by the customer who is using the product or a man-behind-the-curtain using technology inside of  a SaaS offering should not matter. However you are making that  distinction.


I think the distinction matters a great deal from the customer perspective. The solution is production-safe upon pressing "Go" or  it isn't. Or maybe "production-safe" should have a qualifier like   ready-to-go production-safe or something.

Jeremiah later emailed me saying he was going round and round on his opinion and might have a few things wrong. Admittedly it is a tough point to articulate. Hopefully he will publicly clarify what "product safe" means. Regardless, the "how do you properly scan a production application" is an important discussion that the industry needs to have.

So let me state ASC's position: A scanner should be considered "production safe" if what it can and cannot crawl or audit can be configured and controlled by an informed user. We say unequivocally that HP's Application Security Center products are "Production Safe" as we provide a diverse group of settings that allow a user to:

  • Record macros to whitelist parts of the application to test

  • Step the product through a business process to focus the scanner to specific areas of your application

  • Use regexs to define what urls should or should not be crawled and/or audited.

  • Use regexs to define what HTML Forms should or should not be submitted or audited

  • Configure the number of threads used to crawl or audit the web server

  • Manually control speed through our proxy tool

  • Define file extensions or Mime-types to discard should the product inadvertently encounter them

  • Turn on/off execution of various technologies like Flash, JavaScript, etc.

Furthermore, from a customer experience point of view, we do everything we can to ensure our customers know how to use our products properly. We have a comprehensive 2 day training course that is included in nearly every product sale and additional training available. We have countless online videos, tutorials, and support documentation. We even offer a managed SaaS offering for ASC products. In short, we have multiple different efforts to ensure that our customers know how to use our products effectively from Day 1.

Remember: Scanning products should never be considered "fire and forget" tools. Care should always be used when configuring and launching a security assessment. This rule apples to application security scanners just as it applies to network security scanners and other security auditing tools. Any vendor who characterizes their products in a purely "fire and forget" fashion is irresponsible at best and flat out lying at worst.

The bottom line is as long as a tool has a diverse number of settings that allow you to easily control what it can and cannot be assessed, the tool can be used against production systems. An informed user, and not some animated piece of code makes something "Production Ready." Make sure you check for features to control the scope of the security assessment when evaluating any security tool.


Rules for web-based health repository breach notifications announced

The Federal Trade Commission (FTC) has released the final rules concerning breach notifications for Personal Health Information (PHI) that were required under the American Recovery and Reinvestment Act of 2009 which was passed in February (otherwise known as the stimulus package). The Department of Health and Human Services (HHS) and the FTC were tasked with issuing rules requiring vendors of personal health records and related entities to notify individuals when the security of their individually identifiable health information was breached. This closes a loophole in the Health Insurance Portability and Accountability Act (HIPAA) for web-based companies that gather health information. Until now, they had typically not been covered under HIPAA. The new rules go into effect 30 days after publication in the Federal Register. The FTC plans to begin enforcement 180 days after that.


 Some interesting items in the new rules:


 ·         Encrypted data is considered secure (hope it's strong).


 ·         The media must be notified if more than 500 individuals have had their information accessed.


 ·         Companies have up to 60 calendars days to provide notifications.


 ·         Law enforcement can delay notifications if it would impede an investigation or be a threat to national security.


 ·         If the contact information for 10 or more individuals is out of date, alternate notice may be given via a posting on the vendor web site or through the media. (10 is not a lot. It might be 'easier' to find those and do the notification on your web site…and then save the postage.) Read the rules here.




Read the rules here.







Advice for a Hacked Site

If Google detects that your website is hosting malware, it is pretty clear your site has been attacked. Attackers are consistently using automated attack tools looking for SQL Injection points, trying to include files remotely, or attempting to determine ssh passwords via guessing. A frightening trend with SQL Injection attacks concerns how an attacker will insert links to javascript content used to serve malicious links that may try and automatically compromise the users of your website.  When this happens, Google will automatically detect this and actively deter users from visiting your  website. Here are some of the  basic recovery steps that need to be taken to ensure all content that was  possibly modified by the attacker will be removed. It is also  important to note this is not legal advice and should not  be used as such. If you are experiencing monetary loss, consider engaging the proper authorities and hiring a consultant  who is certified to handle these situations. The steps below are  simply a very rough set of guidelines on one way that a security  analyst might approach securing a hacked website.




0. Disconnect from the Internet


The last thing you need is to get attacked again while  performing forensic analysis or restoring your       database/website to its former glory. Remove your server from this possibility by disconnecting it from the Internet. If your website was hacked, simply turning off the webserver is probably a sufficient countermeasure.


1. Backups!


You need to backup your entire site and backend database at this point. It is important to perform this step as later you will actually be deleting all your current content and replacing it with a backed-up version. This is recommended to ensure the attacker has not modified anything on your site. For example, the attacker might have installed a backdoor or a dynamic script that would allow shell access to the server.


1b. Save All Logs and Analyze Them


All server logs should be saved from the attacked machine. If your organization has familiarity with web/network based attacks, then spending some time looking through logs would be beneficial as it may help identify the attackers point of entry. This will obviously help in remediating the issues and detecting how widespread the vulnerability may be.


2. Change all Authentication!


If an attacker has been able to modify your database or filesystem, it is very likely he/she has also stolen the   credentials needed to access your website. This includes usernames/passwords needed to login to any private areas on the website, and any usernames/passwords that are also users on the local machine such as the root user or the administrator passwords, especially if any remote administration (like OpenSSH) is used on the website. Don't forget to remove any ssh/rsa private keys either as they can no longer be trusted.


2b. Reinstall OS (optional? maybe)


Pedantic administrators worried about security and not able to pinpoint the vector used to compromise their website wuld completely reimage the webserver, as bots or key-loggers may have been installed. This is most likely a severe case.However, it may be an acceptable precautionary step depending on how sensitive the webserver or content is to the organization.


 3. Restore Previous Backups


You can no longer trust the code or data that your website is serving or using to serve data. Thus you need to restore to a point in which you did trust your code and data. This is probably going to be a painful process, but it will still be better than being consistently hacked multiple times in the future.  If you have no database backup, don't give up. Consider using the OWASP Scrubbr utility. This utility is designed to analyze database records and look for suspicious looking links that will help you identify and remove malicious content. It also has the side affect of helping you pinpoint where your problems may lie. Generally writing to specific fields within the database only occurs on a few pages, so the search for where the input validation needs to occur will be limited.


4. Perform Some Simple Code Audits


You already have accepted that a hack has occurred, so it makes sense to spend some time looking through critical path code to make sure no obvious mistakes were made.This could mean hiring a consultant to analyze your codebase or utilizing your developers to examine the code by running opensource tools like Nikto on your site. Both would provide beneficial data as to where to suspect malicious activity, and improve your security posture. If you found something suspicious in the logs of your webserver, you should spend some time verifying those specific areas but it is important to note that even though the attacker used door #1, that doesn't mean  door #2 isn't sitting there available right now. Security is an ongoing process and especially after an attack time should be spent securing and analyzing your current codebase. This is important because generally mistakes within webapps are systemic and not just a one off error that only happens in one place within your codebase.


5. Turn the Site Back On


Feeling better, hopefully having identified some issues, it is now time to turn on the web server (hopefully with a clean bill of health).




You're probably thinking to yourself, "this seems like a lot of work, is it really all necessary?". The answer to this question is maybe. Of course this is a nebulous answer to that question, but the actual recovery from an attack might only require a few of the steps listed above. The real trick is in deciding which of those steps are needed (optimization) and the answer to that depends on the type of attack you've encountered. For example, if your site was attacked by just a simple drive-by SQL Injection bot then it is probably sufficient take the following subset of steps.


(1 + 1b) To make sure you have your bases covered and by looking at the logs you can identify the injection points the bots were trying to exploit. (4) Once you've identified the pages being attacked, you (or a consultant) can then verify those pages either have or do not have SQL Injection vulnerabilities. (3) Clean up your database, make sure all offending links can be cleaned, whether this is manually, with your own tool, or using OWASP's Scrubbr.


Of course it is not always easy to identify what type of malware has been attacking your website. There are services available that will perform this types of analysis for you. You can contact either Armorize (http://hackalert.armorize.com/default.php) or ClickFacts (http://www.clickfacts.com/) who will audit the types of malware being served by your website. Since they have specific knowledge in these areas, they will probably be able to tell you specifically which attack has been used and recommend steps for cleaning up your website.





Labels: hacked| Malware

Top Five Web Application Vulnerabilities 8/03/09 - 8/16/09

1) Oracle Config Management Multiple SQL-injection Vulnerabilities

Oracle Config Management is susceptible to multiple SQL Injection vulnerabilities.  SQL Injection can give an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system.  Successful exploitation of these vulnerabilities requires  'Valid Session' privileges. Updates which address these issues are available. Contact the vendor for additional information.


2) SAP NetWeaver Application Server 'uddiclient/process' HTML Injection Vulnerability

SAP NetWeaver Application Server is susceptible to an HTML Injection vulnerability. HTML Injection is used to add content into a web server’s response, which can then be used to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. Updates which resolve this issue are available. Contact the vendor for more details.


3) WordPress 'wp-login.php' Admin Password Reset Security Bypass Vulnerability

WordPress is susceptible to an admin password reset security bypass vulnerability. Successful exploitation will allow an attacker  to reset the administrator password of the application. Updates which address this issue have been released. Contact the vendor for more information.


4) SQLiteManager 'main.php' Cross Site Scripting Vulnerability

SQLiteManager is susceptible to a Cross-Site Scripting vulnerability.  An attacker can leverage this issue to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. A fix has not yet been released. Contact the vendor for further details.


5) WordPress Plugin WP-Syntax Remote PHP Code Execution Vulnerability

The WP-Syntax plugin for WordPress is susceptible to a remote code execution vulnerability. Attackers can leverage this issue to execute arbitrary PHP code within the context of the affected webserver process. A fix has not yet been released. Contact the vendor for additional details. 



Active Template Library vulnerability requires developers to recompile their ActiveX controls

As the Internet grew, it became increasingly clear that HTML alone was insufficient to meet the demand for a more interactive and ultimately more rewarding user experience.  For one thing, the use of server-side technologies for rendering UI’s meant painfully slow response times.  For another, functionality was limited to static content.  Since, then, though, Rich Internet Applications have managed to vastly improve the web user’s experience by providing media rich content and interactivity comparable to desktop applications.


It’s no surprise that the components that enable this functionality are now widespread.  An amazing 99% of Internet users have AdobeÒFlashÒ installed. In addition, 20-25% of users have Microsoft ÒSilverlightÒ installed, and 31% have  RealOne PlayerÒ. These and various other third-party ActiveX controls are becoming a necessity to interact with a major portion of the web. 


The best solutions available today use AJAX to speed up response times and ActiveX content to create media rich applications. Sharing videos on YouTube, streaming movies from Netflix, even ordering pizza online… all require the users to install ActiveX controls.


So what happens when a vulnerability is discovered that could affect a majority of these ActiveX controls? I am by no means a brilliant mathematician, but I would guess that such a scenario would put the vast majority of Internet users at risk of getting owned by hackers. Such a vulnerability was presented last week at the Blackhat security conference. Mark Dowd and David Dewey of IBM, and Ryan Smith of iDefense presented a talk titled “The Language of Trust: Exploiting Trust Relationships in Active Content” about their research on the analysis of  browser architecture, specifically the interoperability layer of the architecture that allows collaboration between embedded objects and the scripting engines and its impact on the security features of the host application. They also discovered a vulnerability in Microsoft’s Active Template Library that could allow attackers to perform remote code execution attacks. A paper detailing the architecture issues as well as the vulnerabilities is available here .


The Active Template Library (ATL) is a collection of classes that simplify the development of COM objects . Developers of controls such as Flash, Silverlight, windows media player and other third-party ActiveX controls thus make extensive use of the Active Template Library to take advantage of the helper routines it provides. Thus a vulnerability in the Active Template Library also makes all controls that use the library vulnerable.


Microsoft released an out-of-band update on July 28th, just prior to the talk, to fix the ATL vulnerability. But by no means does this fix all the ActiveX controls that are already installed by the users. Since the Active Template Library is statically linked by these ActiveX controls, the ATL routines used by them are actually copied into the target ActiveX control application. Thus even if the ATL routines have been fixed the controls still contain the older, vulnerable versions of these routines. To fix the vulnerability, the ActiveX developers need to get the latest version of ATL by installing the recent Microsoft update for Visual Studio. Then they must recompile their control(s) using the fixed ATL version and deploy the updated control. Developers can refer to security update for ATL provided by Microsoft here.


If your web application hosts ActiveX content that requires users to install an ActiveX control, it is extremely important that you approach the developer(s) of the control (either inhouse of third-party) and make sure that they have updated and deployed a fixed version of the control to the users.


WebInspect can help.


We realize the importance of this vulnerability and want to make sure that the developers understand the urgency of this issue. Hence, WebInspect now has a check to detect ActiveX content present in web applications. It alerts the user about the detected ActiveX content and provides fix information and references to help mitigate this critical vulnerability. This specific check is included by default in WI's standard policy. If you want to run only that check, then create a policy with Adaptive Agents enabled and select the "ActiveX Control Discovery" check 10925.

Top Five Web Application Vulnerabilities 7/20/09- 8/2/09

1) Hitachi Multiple Business Logic Products Unspecified Cross-Site Scripting Vulnerability

Multiple Hitachi Business Logic products are 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 advisory and updates which address this issue have been released. Contact the vendor for additional information.


2) IBM Tivoli Identity Manager Session Fixation Vulnerability

IBM Tivoli Identity Manager is susceptible to a session fixation vulnerability.  Victims who are enticed into visiting a malicious URI can have their session hijacked and give an attacker unauthorized access to the application. A fix has been released. Contact the vendor for further details.


3) Apache HTTP Server HTTP-Basic Authentication Bypass Vulnerability

Apache HTTP Server is susceptible to an HTTP-Basic authentication bypass vulnerability.  Successful exploitation will give an attacker access to protected resources, likely leading to more damaging attacks.  A fix has not yet been released. Contact the vendor more information.


4) WordPress Multiple Cross-Site Scripting Vulnerabilities

WordPress is susceptible to multiple instances of Cross-Site Scripting. These vulnerabilities can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials.   A fix has not yet been released for the 'wp-comments-post.php' issue, while a patch that resolves the Comment Author URI issue is available. Contact the vendor for additional information.


5) Bugzilla 'show_bug.cgi' Information Disclosure Vulnerability

Bugzilla is susceptible to an information disclosure vulnerability. Successful exploitation would give an authenticated attacker access to sensitive information, and would likely lead to more damaging attacks.  A fix has been released. Contact the vendor for more details.


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.