HTTP Response Splitting (HRS) is one of those webappsec attacks that’s poorly understood, even among the experts (myself included), despite Amit Klein’s best efforts to show us the light. The common understanding is vulnerabilities are rare, severity is high, but the preconditions necessary for an attack lower the threat profile. Recently Arian Evans, WhiteHat’s Director of Operations, took a renewed interest in the complexities of HRS with the assistance of Amit (original discoverer) and several customers. Arian added new checks to Sentinel, adjusted others, and run scans across a few hundred websites to test the vulnerability identification rate. The results were eye opening to say the least. We sent out a customer newsletter last week talking a lot about our HRS R&D, which I thought other would be interested in.
HTTP Response Splitting is a little known, very complex, and frequently misunderstood website vulnerability.
The best way to think about Response Splitting is that it’s executed similarly to Cross-Site Scripting (XSS), but more powerful. Take a loose analogy of a written letter in an envelope. XSS targets the message inside the envelope, while Response Splitting targets not only the message inside the envelope, but the envelope itself.
There several different variations of Response Splitting and many emergent behaviors that make accurate vulnerability identification challenging. WhiteHat has been investing a lot of R&D time perfecting the accuracy of our tests and has started pushing the results to Sentinel users last week. WhiteHat Security plans to release a paper on this subject, breaking down the details of various conditions, implications, and how to measure them. In the meantime, the results of our testing contained a few surprises:
HTTP Response Splitting issues are far more widespread than expected.
Simply put: We’re finding it everywhere. The interesting thing about many Response Splitting vulnerabilities is that the Web application is not necessarily doing anything wrong compared to strict RFC specification. Though this doesn’t change the fact that the website is vulnerable to a malicious attacker taking control of it. Do not be surprised if we find this in a few places on your website(s).
HTTP Response Splitting issues are far more severe than expected.
HTTP Response Splitting issues can be very, very bad, especially on production sites if a caching server is present. If you are using an intermediary caching server/proxy/load-balancer there is a chance that one of several conditions could be true:
1. One-to-Many: One attack can target many users.
2. Persistence: HTTP Response Splitting attacks will be persistent.
3. Domino Effect: One vulnerability may be exploited to take over an entire site.
These issues only occur in very specific situations. We will actively notify you if we discover that those conditions are true. But, this can be tough to measure and we may not always know if the above worst case scenario conditions are possible. This evaluation may require some investigation on your end.
WhiteHat Website Vulnerability Management Practice Tips:
Q. How do I fix a vulnerability to HTTP Response Splitting?
A. Whew, tough question…you should likely take two approaches:
1. Input Validation: You can try to remove every CRLF (\r \n) from input. The problem you will have is that the CRLF is likely to be encoded in some fashion. It could simply be URI-escaped (%0d%0A) or some other Hex or Decimal encoding variant.
If you do not find all the encoded CRLF variants that your application is capable of decoding, you will still be vulnerable.
2. URI-escaping: If you properly escape the URI in every place it is output, like the HTTP Location Header, the CRLF will not be parsed by the browser.
The problem with this approach is that there are some conditions, like personalization cookies, that are not URI data but could be a Response-Splitting attack. We could take our personalization cookie that is name=WhiteHat and make that name=WhiteHat%0D%0A and craft our attack after that.
When your application goes to set that cookie with our name and subsequent attack, the HTTP Response Splitting attack will occur when it reaches the browser.
You would have to try and catch that on input validation, or write a special library to escape \r \n anywhere you found it in output that was potentially user-supplied data.
8 comments:
Would you say though that the minimum necessary condition for a HRS vulnerability to exist, a web app has to take user input verbatim to later use it to create an HTTP header?
Chrisp:
Yes, the basic premise of HTTPRS is that the HTTP headers are rewritten to create two responses where only one should be (there's then some jiggery-pokery to get the 2nd response - the "malicious" one - associated with a request of your choosing that is then cached).
The usual place to look for this are any user input that finds itself in HTTP headers - usually Location (for redirects) or Cookies, but it could appear in others (although in my experience not that likley).
A good resource to read some more is http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
I proposed it to the PHPIDS project last month. Not only HTTP Response splitting which is actually still based upon a CRLF injection, but also Worm signatures which behave the same way but remotely activated or inserted.
it's actually one of those things that is forgotten by many, or many did not know about. I think one of the first things I learned was CRLF injection, changing or modifying HTTP1.1 to HTTP1.0, sending arbitrary headers. A lot of servers where vulnerable to some of the same attacks with a ton of nulls or spaces/slashes.
If I find the time I was planning to write some Apache rules for it, cause it mainly falls under server protection IMHO.
Regards,
0x000000
ChrisP, yes, that is one of the necessary pre-conditions. The others have a lot to do with "exploitability". That's the paper Arian is working on with Amit.
Is there built in detection of this attack in IIS6 now? I tried this on a vulnerable site and it threw an error stating that a malacious value was found in the cookie value(an IIS error page).
Thanks for the post btw, great stuff!
Re: IIS 6
So, the webserver itself I believe is still "vulnerable".
However, IIS 6 on Windows 2003 has two different checks and balances.
(1) URL-scan is built-in, which could easily strip out CRLFs from input, given the right encoding type.,
(2) the .NET Framework does not like CRLFs in user-supplied data and will throw an I/O expection IIRC which could easily translate into an error page.
We see this with previous versions of IIS, every version of Apache, and IBM's HTTP server (basically apache) I will research Microsoft-IIS/6.0 and see what I find.
PHP versions 5.1.2 and later provide some protection against this exploit by ensuring that the header() function can only output a single line.
However, it is still a good idea to run any incoming data being used in a header through a regular expression, and to protect privacy by ensuring that any cookies set do not contain user data at all.
Thanks.
I have been looking for info on how to solve a HTTP Response Splitting which I am having - and this has been very helpful.
Much appreciated!
Post a Comment