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

SSLv3/TLS Renegotiation Stream Injection

Recently, Thursday 11/5/09, a few folks over on the IETF mailing list went public with a limited Man-in-the-Middle attack on SSLv3 and TLS. There has been quite a bit of press coverage on this issue's severity. However, the way this attack can be used is proving to be more dangerous in specific contexts than at first thought. This vulnerability affects almost every SSL/TLS implementation: IIS (5|6|7), Apache mod_ssl < 2.2.14, OpenSSL < 0.9.8l, GnuTLS < 2.8.5, Mozilla NSS < 3.12.4, and certainly more. Any products using these libraries as their underlying secure transport layer are also vulnerable to this content injection vulnerability. This vulnerability has been assigned CVE-2009-3555 by Mitre and I'm sure they will continue to update their listing with newly affected packages as they are found.

At a high level, this is not a true Man-in-the-Middle attack. An attacker leveraging this vulnerability can only inject data and is unable to read client traffic or server responses. While this is not an entire compromise, there are novel attacks that can be performed in the context of HTTP and SSLv3/TLS. In order for SSLv3/TLS to support long running sessions, at a protocol level, encryption keys must be changed to ensure cryptographic security. However, the real problem manifests within the communication between an application and the SSLv3/TLS library the server is using. Since HTTP requests cannot be processed until they are complete, web servers keep the request in a buffer until it is complete. When the SSLv3/TLS libraries receive new packets they are immediately forwarded to the web server once decrypted at a protocol level. The issue here lies within that caching behavior; before completing the HTTP request, the client initiates a key renegotiation then sending new keys. Except these new keys could have been from the client connecting to the man-in-the-middle and just simply forwarded by the attacker. This is especially malicious because the client will never know he has been man-in-the-middled as the communication between her and the server appears completely normal. Unfortunately, prior to this vulnerability disclosure SSLv3/TLS enabled web servers do NOT flush the data buffers before the renegotiation. Thus an attacker can leverage this optimization/feature/whatever to inject data into the beginning of the conversation between the unexpecting client and the web server.

Given an attacker can get traffic routed through him (this is easy in a WiFi environment or with arp poisoning) the attacker can effectively transparently proxy a client's request through him. Now using this vulnerability, any HTTPS connection through him can have arbitrary data from the attacker prepended to anything the client sends. This is especially bad for HTTP requests.

These theoretical attacks all require some type of renegotiation to occur. Luckily, for an attacker, there are simple ways that can be utilized. The possible ways renegotation can be forced are:

  • Any server that allows client renegotiation.

  • Servers with public access to a subset of folders, and a set of secure folders requiring a client certificate.

  • Servers that renegotiate for any reason.

Of course the libraries have quickly identified and fixed some of the issues that cause this vulnerability. OpenSSL has disabled renegotiation for SSLv3 and TLS in a patch. GnuTLS has implemented some of the drafted larger fixes for TLS specifically. Apache has fixed the some of the issues at the application layer associated with the prepended attacks, but this still requires patches of openssl to completely solve all the certificate attacks (doesn't prevent from server initiated renegotiation).

WebInspect will now also test any SSL web servers for this vulnerability with Check ID 10942. Simply SmartUpdate to receive the latest checks.

Labels: MitM| Research| SSLv3| TLS

Top Five Web Application Vulnerabilities 10/27/09 - 11/8/09

1) HP Power Manager Management Web Server Login Remote Code Execution Vulnerability

HP Power Manager is susceptible to a remote code execution vulnerability via the login form of the web based management web server due to improper bounds-checking of user-supplied data. Exploitation of this vulnerability can give an attacker the means to enact SYSTEM level commands and possibly lead to a complete compromise of the affected system. Even failed attempts will likely cause a denial-of-service condition. Updates which resolve this issue have been released. Contact the vendor for additional information.


2) Oracle WebLogic Server Administration Console HTML Injection Vulnerability

Oracle WebLogic Server is susceptible to an HTML Injection vulnerability via the Web Administration Console. 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 address this issue are available. Contact the vendor for more details.


3) Xerox Fiery WebTools 'summary.php' SQL Injection Vulnerability

Xerox Fiery WebTools is susceptible to a SQL Injection vulnerability. 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. A fix has not yet been released. Contact the vendor for more information.


4) IBM Lotus Connections Mobile Activities Pages Cross-Site Scripting Vulnerability

IBM Lotus Connections is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage this 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. Updates which resolve this issue have been released. Contact the vendor for further details.


5) Roundcube Webmail Multiple Cross-Site Request Forgery Vulnerabilities

Roundcube Webmail is susceptible to multiple instances of Cross-Site Request Forgery. Cross-Site Request Forgery leverages the trust a web application places in a user to make authenticated requests that appear completely legitimate, and can be used to abuse any type of functionality the web application contains. Updates which resolve these issues have been released. Contact the vendor for additional information.


Now Hiring: HP Security Center Pen Tester

HP is looking for a qualified Sr. Application Security Consultant that has deep Application Security experience.  Consultant should have experience with performing Web Application Assessments, Network Penetration Testing, and be capable of manually exploiting/validating any vulnerabilities identified.    In addition to being able to perform security testing the consultant must have strong technical writing skills, so that exploits can be properly documented. 
Job will also involve implementing HP Application Security Products (ex. AMP, WebInspect, and QAInspect). 50% of the job will be performing security assessments and the other 50% will be devoted to security product implementations.  Applicants should have experience with application security products from HP/SPI Dynamics or IBM/Watchfire.
Candidate must be willing to work with minimum supervision to accomplish customer objectives.  Network Security experience is a plus.  Candidate must be willing to travel 75% of the time. 
Candidates may be located anywhere in the USA.

The following qualifications are expected from potential applicants:
·      3 years Web Application Security experience
·      Experience with Application Security products from HP/SPI Dynamics or IBM/Watchfire
·      Strong Unix, Windows and networking security skills
·      Degree in Computer Science, Information Systems, Engineering or related major
·      Minimum of 5 years Information Security experience
·      Strong communication skills (written and oral)
·      CISSP Certified
·      75% travel may be required

Job - Services
Primary Location - United States
Schedule - Full-time
Job Type - Experienced
Shift - Day Job
Travel - Yes, 75% of the time

For more information and to apply, go to http://www.hp.com/go/jobs and search for: 327230.  

Labels: Pen Tester

Take your %00 and shove it

We've recently been optimizing our Local File Inclusion (LFI) audit engine. Part of that effort has included poking around in different frameworks (php, .NET, java, ruby/rails, python, perl... etc) and seeing how many ways a developer might fall prey to this vulnerability. One of the common ways to leverage this vulnerability is by appending  a null byte (%00, 0x00, ASCIIZ), c-style string terminator, to the end of a parameter that might be susceptible to an LFI vulnerability. Sadly, this type of injection has worked in almost all known major web development languages. Microsoft's .NET is the outlier. While there are currently no known API's that allow null bytes, it has had its fair share of issues in the past (fixed in 2007 KB928365).

So how does this happen? Some common ways this might happen in PHP are shown in the following snipit of code...

In the above code, the developer needs to include some file, or some template, and is using a raw HTTP parameter as the file name. Require/fopen/fpassthru will try to load files relative to the current working directory. However, if an attacker were to specify a full path (such as "/etc/passwd"), PHP would automatically try to read that file directly into memory (and in these cases, reflect it). Of course the PHP process user (usually Apache's user) would need to have access to that file but that doesn't exclude a lot of interesting attacks...

So why did you tell me about the null byte? The null byte trick helps when there is an appended value (like ".template"). A crafty attacker knows that the underlying system functions are all written in C and %00 is the url encoded version of the C string terminator (0x00, ASCIIZ). With this information you can effectively cause the appended value to be ignored. When "/etc/passwd\0.template" is passed to the underlying operating system the null byte (\0) will be interpreted as the end of the string, thus "/etc/passwd" will be loaded as the file. This type of vulnerability is severe. It's well known that this generally leads to arbitrary code execution on the server. Clearly, though, there is an even more immediate problem. Attackers now have complete access to your server-side source code. We've run into this problem so often during penetration tests that we wrote a tool to "mirror" website's source code based on a single LFI vulnerability and the pages we crawled.

You might be saying to yourself now, "Ok. Well thats fine, but I've never seen this. Why would anyone do that?". Well.,hopefully you're not thinking that but it is true that our previous example was fabricated... but Google Code Search doesn't index any of my example code, just real code. I wonder...how I can use this to my benefit?

Google Code is pretty awesome. You can search code with full regexs. (I wonder why I can't do this with Google itself! grr). So given that awesome functionality, here is a quick regex search to automatically find opensource PHP projects that have LFI vulnerabilities.

Of course its not all about PHP. Here are some other common ways we've seen LFI happen...

Here is some Ruby on Rails:

Here is some Java:

This is one snip-it of PHP, an image uploader and resizer, that really suprised me. This was essentially an insecure file upload as well as an LFI.

This all begs the question, why the f*$k do web development languages still forward these strings directly into the libc versions? Stefan Esser figured this out years ago when he was creating a the Hardened PHP project (althought not bullet proof as Esser points out himself). Hardened PHP has included file system wrappers that will not allow null bytes to be injected into underlying OS system calls. In fact, this was reported to PHP as early as 2001 in their bug database, but have chosen to ignore this for whatever reason. I have no idea why a developer would need that functionality. Perhaps their rationale is a performance one... but I can't believe the benefits in performace in this instance outweigh the security impact. I imagine thousands of vulnerabilities in OSS projects would not have existed if the uses of open in *nix or OpenFile in windows were wrapped and checked for bad characters. Microsoft has got this right, though. This is exactly what they and the Suhoshin patch do to protect the developers on the web. 

As a side note... Props to Ubuntu for distributing PHP with the Suhoshin patches applied to the default install. And to any other vendors that do this as well... although you should check your PHP install to make sure you have the Hardened PHP patches installed. Stefan et al. have done an excellent job tying up some of the loose ends PHP seems to leave all over the place.

HP Application Security Center at OWASP DC 11/11-13

The HP Application Security Center has several presentations at the upcoming OWASP Global Summit In Washington, DC. Ryan English, Rafal Los, Dennis Hurst and Kim Dinerman will all be there.  More information about the summit can be found here: OWASP Global Summit. Details concerning each of our presentations follow here:

 Dennis Hurst at OWASP

Understanding the Implications of Cloud Computing on Application Security” (11/12, 10:30-11:30)

Understanding the Implications of Cloud Computing on Application Security Cloud Computing paradigms spell fundamental changes for where your applications run, the platforms on which they run, who controls these platforms and the boundaries corporate data  crosses. The speaker will address the distinct security challenges posed by each of the three Cloud Computing models: Infrastructure as a Service (IaaS), where hosted servers, software and network equipment are deployed in the cloud; Platforms as a Service (PaaS), where the organization develops its own applications, but does so within the provider’s framework or specified platform; and Software as a Service (SaaS), where the organization trusts its  application to both the provider’s hardware and software.  What steps should you take in each case to protect your data?  Companies that choose not to use the Cloud model at all run a different risk--  rogue departments doing it anyway.  What is a logical, predictable, and mature approach to adopting Cloud Computing?

 “SDLC Industry Panel” (11/12, 2:30pm - 4:30pm)

A  panel discussion on the growth of secure SDLCs/Application Development Program/Application Life Cycles, where you can share the facets that have made your organization's efforts successful and unique, what you feel others should know so that they can improve their programs, and to talk about the future of the application security space with regards to life cycle processes.
OWASP envisions having each participant give a (very) brief introductory talk, where they discuss the highlights of their program and what has set their program apart. This will be followed by a moderated Q&A discussing overcoming hurdles in implementing an SDLC and what the next steps are in the evolution of Secure SDLCs, which will then opened to general questions from the audience.

Rafal Los at OWASP

When Web 2.0 Attacks: UnderstandingAJAX, Flashand Highly Interactive Technologies”(11/12 5:30pm-6:30pm)                                         

Web 2.0 -love it or hate it, thetechnology driving the highly interactive web experience is in your browser andcoming to your enterprise. Securing Web 2.0 requires extraordinary means due tothe increased attack surface, new breed of "Web 2.0 developers" and increasedvisibility of sites and applications. Understanding the risks associated withWeb 2.0 and beyond is essential to building "less risky" web applications intothe next phase of the web. This talk focuses on how 2 prevalent technologies;AJAXandAdobe Flash!, create the potential forcatastrophic failure. Focus is given to understandingeach technology's attack surface, most common security failures, andexploitation of common coding mistakes. This workshop-style walk-through of theWeb 2.0's ugly underbelly will give participants a deeper understanding of whysecurity professionals are terrified of "highly interactive web technologies"and why we say that "everything old is new again."

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.