HTTP Request Smuggling

cyphersteve writes "Multiple vendors are vulnerable to a new class of attack named 'HTTP Request Smuggling' that revolves around piggybacking a HTTP request inside of another HTTP request, which could let a remote malicious user conduct cache poisoning, cross-site scripting, session hijacking, as well as bypassing web application firewall protection and other attacks. HTTP Request Smuggling works by taking advantage of the discrepancies in parsing when one or more HTTP devices are between the user and the web server. CERT has ranked this attack and the associated vulnerabilties found in multiple products as High Risk. The authors (Amit Klein, Steve Orrin, Ronen Heled, and Chaim Linhart) have published a whitepaper describing this technique in detail."

Comments

Validation

[ilyanep]

Now let's take packet A. Do an MD5 sum (or similar) on it. Send it to the end user. Have the end user's browser do a similar check on it and send it to the server. IF the server green flags it, then show the page.

This shouldn't become a speed problem on broadband machines because it'll only mean 2 or 3 times more packets (but you can always increase packet size).

Call the new standard something like HTTPS 2.0.

Re:Validation

[Anonymous Coward]

It would mean not only 2 or 3 more packets but another full roundtrip, per transaction. It's also not feasible for the very reason why these attacks work: Intermediate HTTP devices modify the requests (proxies add Client-IP: headers, for example). That would invalidate the checksum.

Article Text

[Anonymous Coward]

AC = No Karma Whoring

HTTP REQUEST SMUGGLING
CHAIM LINHART (chaiml@post.tau.ac.il)
AMIT KLEIN (aksecurity@hotpop.com)
RONEN HELED
AND STEVE ORRIN (sorrin@ix.netcom.com)
A whitepaper from Watchfire
TABLE OF CONTENTS
Abstract 1
Executive Summary 1
What is HTTP Request Smuggling? 2
What damage can HRS inflict? 2
Example #1: Web Cache Poisoning 4
Example #2: Firewall/IPS/IDS evasion 5
Example #3: Forward vs. backward HRS 7
Example #4: Request Hijacking 9
Example #5: Request Credential Hijacking 10
HRS techniques 10
Protecting your site against HRS 19
Squid 19
Check Point FW-1 19
Final note regarding solutions 19
About Watchfire 20
References 21
Copyright © 2005 Watchfire Corporation. All Rights Reserved. Watchfire, WebCPO, WebXM,
WebQA, Watchfire Enterprise Solution, WebXACT, Linkbot, Macrobot, Metabot, Bobby,
Sanctum, AppScan, the Sanctum Logo, the Bobby Logo and the Flame Logo are trademarks or
registered trademarks of Watchfire Corporation. GómezPro is a trademark of Gómez, Inc., used
under license. All other products, company names, and logos are trademarks or registered
trademarks of their respective owners.
Except as expressly agreed by Watchfire in writing, Watchfire makes no representation about the
suitability and/or accuracy of the information published in this whitepaper. In no event shall
Watchfire be liable for any direct, indirect, incidental, special or consequential damages, or
damages for loss of profits, revenue, data or use, incurred by you or any third party, arising from
your access to, or use of, the information published in this whitepaper, for a particular purpose.
www.watchfire.com
HTTP REQUEST SMUGGLING
© Copyright 2005. Watchfire Corporation. All Rights Reserved. 1
ABSTRACT
This document summarizes our work on HTTP Request Smuggling, a new attack technique that has
recently emerged. We'll describe this technique and explain when it can work and the damage it can do.
This paper assumes the reader is familiar with the basics of HTTP. If not, the reader is referred to the
HTTP/1.1 RFC [4].
EXECUTIVE SUMMARY
We describe a new web entity attack technique - "HTTP Request Smuggling." This attack technique, and
the derived attacks, are relevant to most web environments and are the result of an HTTP server or device's
failure to properly handle malformed inbound HTTP requests.
HTTP Request Smuggling works by taking advantage of the discrepancies in parsing when one or more
HTTP devices/entities (e.g. cache server, proxy server, web application firewall, etc.) are in the data flow
between the user and the web server. HTTP Request Smuggling enables various attacks - web cache
poisoning, session hijacking, cross-site scripting and most importantly, the ability to bypass web application
firewall protection. It sends multiple specially-crafted HTTP requests that cause the two attacked entities to
see two different sets of requests, allowing the hacker to smuggle a request to one device without the other
device being aware of it. In the web cache poisoning attack, this smuggled request will trick the cache
server into unintentionally associating a URL to another URL's page (content), and caching this content for
the URL. In the web application firewall attack, the smuggled request can be a worm (like Nimda or Code
Red) or buffer overflow attack targeting the web server. Finally, because HTTP Request Smuggling enables
the attacker to insert or sneak a request into the flow, it allows the attacker to manipulate the web server's
request/response sequencing which can allow for credential hijacking and other malicious outcomes.
HTTP REQUEST SMUGGLING
© Copyright 2005. Watchfire Corporation. All Rights Reserved. 2
WHAT IS HTTP REQUEST SMUGGLING?
HTTP Request Smuggling ("HRS") is a new hacking technique that targets HTTP devices. Indeed, whenever
HTTP requests originating from a client pass through

Question of Compatibility vs. Reliability

[l2718]

This exploit is interesting, and is related to a cultural issue: how do you handle malformed input?

There are two basic approached to this: either you reject it (the sound, security-concious way), or you attempt to make sense of it (the compatible way). The second solution allows your software to interface with badly-written external code, at the cost of interfacing with intentionally malformed requests like the exploit the describe.

The reason the exploit works is that different people have different methods for determining what the sender of the malformed packet really meant, and if two different interpretations are applied to the same packet you can use the resulting "confusion" to your advantage. Different recount results which depend on guessing "voter intent" from malformed ballots in Florida comes to mind.

Re:Question of Compatibility vs. Reliability

[iabervon]

The actual issue is cases where someone makes sense of malformed input and then passes that input on to something else. The proper thing to do is always pass on correctly-formed input. If you get malformed input and interpret it somehow, you then need to pass on your interpretation, not the original. The guideline is to be permissive in what you accept and strict in what you transmit; when you're passing something on, you need to canonicalize it in transit.

A good example of this is how the legal system works. When a court makes a decision on the application of a law to an unclear situation, that becomes part of the case law, such that there is a consistent interpretation, rather than an ambiguous situation being interpreted randomly each time it occurs.

Be very careful

[Anonymous Coward]

It is unethical and immoral. Some HTTP requests even time-out and have died doing this! Also be aware that some vigilante border gateway protocols have sprung up in the south looking for smuggled HTTP requests. Also new federal legislation may require all web servers to validate the HTTP request's green packets before responding.

Re:and here's where...

[Anonymous Coward]

Actually the whitepaper sates that IIS and Apache automatically dump the malformed packet.

Microsoft does write a few good lines of code.

Re:Problem reading the PDF...

[Anonymous Coward]

Here is a link:
http://www.gatech-edu.org/HTTP-Request-Smuggling.p df

Possible way to burn down RSS?

[krowten21]

Scenario: Vulnerable web server for popular blogging site, compromised by this or other attack, RSS feed used to broadcast exploit against vulnerable IE 7.0 clients. predicted at www.threatchaos.com att he beginning of the year.

Quick Summary

[MojoRilla]

Due to bad handling of borderline html, some web servers will see extra requests that front end servers (cache, proxies) don't see. This is due http keepalive (so that more than one request can be processed in a stream) and malicious http headers. This seems to be implemented mostly by sending duplicate or invalid content length headers.

I'm sure that all of these problems will be quickly patched. All of these issues would be fixed by tighter HTTP parsing specifications. However, buggy software will always exist, and always be exploited.

publicfile

[sugarmotor]

http://cr.yp.to/publicfile.html, publicfiloe, is not mentioned.

That's already what Apache does

[wtarreau]

Why not just (a) be less trusting of Content-Length, and (b) reject malformed requests with two of them?

Apache already does this. Multiple content-length fire an error, as well as
requests using chunked transfer-encoding.

You're forced to trust Content-Length because it's the only way to know when
to stop reading. It's just as if you proposed to be less trusting on the length
field in an IP packet.

Willy

Re:Hype it up?

[Sven Tuerpe]

Why not just issue seperate advisories and inform the respective vendors? Seems to me like they bundled multiple flaws in multiple products so they could be creditied with discovering a new class of vulnerability.

Because the whole point of this type of vulnerability is undesired interaction between different implementations of the same protocol. No single product will ever be vulnerable and each and every vendor might well point to the next one saying it's their fault.

Re:Why is this news?

[segmond]

Shut up! RTFP!

The attack allows attack worse than XSS if an XSS vulnerability exists since this time, it doesn't require you to intereact with the client. It allows cache poisoning. It allows you to smuggle data past some firewall/filters that try to prevent HTTP attacks by parsing requests, for example, so servers will filter out GET requests like /foo/../../../whatever or /foo?cmd.exe You can use this to bypass it. This is NEWS because it is a NEW attack. This is not about using HTTP as a tunnel for other form of communication.
This exploits the fact that the cache server/firewall and webserver might parse the same request different when it has two "Content Length:" in it... Read the paper.