Welcome!

If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, PC Security Journal, Oracle Journal, Apache Web Server Journal, Security Journal, CIO/CTO Update, F5 Networks

Blog Feed Post

Zero-Day Apache Exploit? Zero-Problem

It’s called “Apache Killer” and it’s yet another example of exploiting not a vulnerability, but a protocol’s behavior

A recently discovered 0-day Apache exploit is no problem for BIG-IP. Here’s a couple of different options using F5 solutions to secure your site against it.

It’s called “Apache Killer” and it’s yet another example of exploiting not a vulnerability, but a protocol’s behavior.

UPDATE (8/26/2011) We're hearing that other Range-* HTTP headers are also vulnerable. Take care to secure against these potential attack vectors as well!

In this case, the target is Apache and the “vulnerability” is in the way multiple ranges are handled by the Apache HTTPD server. The RANGE HTTP header is used to request one or more sub-ranges of the response, instead of the entire response entity. Ranges are sometimes used by thin clients (an example given was an eReader) that are memory constrained and may want to display just portions of the web page.  Generally speaking, multiple byte ranges are not used very often.image

RFC 2616 Section 14.35.2 (Range retrieval request) explains:

quote-badge HTTP retrieval requests using conditional or unconditional GET methods MAY request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request:

      Range = "Range" ":" ranges-specifier

A server MAY ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large entities.

The attack is simple. It’s a simple HTTP request with lots – and lots – of ranges. While this example uses the HEAD method, it can also be used with a GET.

  HEAD / HTTP/1.1 Host:xxxx  Range:bytes=0-,5-1,5-2,5-3,…

According to researchers testing the vulnerability, a successful attack requires a “modest” number of requests.

BIG-IP SOLUTIONS

There are several options to prevent this attack using BIG-IP solutions.

1

HEADER SANITIZATION

First, you can modify the HTTP profile to simply remove the Range header. HTTP header removal – and replacement – is a common means of manipulating request and response headers as a means to “fix” broken applications, clients, or enable other functionality. This is a form of header sanitization, used typically to remove non-compliant header values that may or may not be malicious, but are undesirable. The Apache suggestion is to remove any Range header with 5 or more values.

Note that this could itself break clients whose functionality expects a specific data set as specified by the RANGE header. As it is a rarely used header it is unlikely to impact clients adversely, but caution is always advised. Collaborate with developers and understand the implications before arbitrarily removing HTTP headers that may be necessary to application functionality.

 

2

HEADER VALUE SCRUBBING

You can also use an iRule to scrub the headers. By inspecting and thus detecting large numbers of ranges in the RANGE header, you can subsequently handle the request based on your specific needs. Possible reactions include removal of the header, rejection of the request, redirection to a honey pot, or replacement of the header.

Sample iRule code (always test before deploying into production!)

when HTTP_REQUEST {

# remove Range requests for CVE-2011-3192 if more than 5 ranges are requested

if { [HTTP::header "Range"] matches_regex {bytes=(([0-9\- ])+,){5,}} } {

HTTP::header remove Range

}

}

Again, changing an HTTP header may have negative consequences on the functionality of the application and/or client, so tread carefully.

3

BIG-IP ASM ATTACK SIGNATURE clip_image002

Another method of mitigation using BIG-IP solutions is to use a BIG-IP Application Security Manager (ASM) attack signature to detect and act upon an attack using this technique. The signature to add looks like:

pcre:"/Range:[\t ]*bytes=(([0-9\- ])+,){5,}/Hi";

 

It is important to be aware of this exploit and how it works, as it is likely that once it is widely mitigated, attacks will begin (if they already are not) to explore the ways in which this header can be exploited. There are multiple “range” style headers, any of which may be vulnerable to similar exploitation, so it may be time to consider your current security strategy and determine whether the field of potential exploitable headers is such that a more negative approach (default deny unless specifically allowed) may be required to secure against future DoS attacks targeting HTTP headers.

There are also alternative solutions available already, including this writeup from SpiderLabs with a link to an OWASP mod_security rule file for mitigations.

Stay safe out there!


Connect with Lori: Connect with F5:
o_linkedin[1] google o_rss[1] o_facebook[1] o_twitter[1] o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

AddThis Feed Button Bookmark and Share

Related blogs & articles:

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.