Slashdot Mirror
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."
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.
~Ilyanep
To get message, take amount of carrier pigeons at each stage mod 2. Then decode binary.
Tried to do a copy and paste, but the lameness filter wont let me. DRM in force! ;)
I am a viral sig. Please copy me and help me spread. Thank you.
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
I like to use 'piggybacking' as well, it makes me sound technical but cool at the same time.
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.
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.
Yes, but if you use HTTP Request Snuggling you wont mind the extra packets.
Everybody likes snuggling.
Starsucks
Actually the whitepaper sates that IIS and Apache automatically dump the malformed packet.
Microsoft does write a few good lines of code.
Here is a link:p df
http://www.gatech-edu.org/HTTP-Request-Smuggling.
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.
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.
http://cr.yp.to/publicfile.html, publicfiloe, is not mentioned.
http://stephan.sugarmotor.org
From TFA:
Conclusion: We have seen that there are many pairs (proxy/firewall servers and web servers) of vulnerable systems. Particularly, we demonstrated that the following pairs are vulnerable: PCCA o IIS/5.0 o Tomcat 5.0.19 (probably with Tomcat 4.1.x as well) Squid 2.5stable4 (Unix) and Squid 2.5stable5 for NT o IIS/5.0 o WebLogic 8.1 SP1 Apache 2.0.45 o IIS/5.0 o IS/6.0 o Apache 1.3.29 o Apache 2.0.45 o WebSphere 5.1 and 5.0 o WebLogic 8.1 SP1 o Oracle9iAS web server 9.0.2 o SunONE web server 6.1 SP4 ISA/2000 o IIS/5.0 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 DeleGate 8.9.2 o IIS/6.0 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 Oracle9iAS cache server 9.0.2 o WebLogic 8.1 SP1 SunONE proxy server 3.6 SP4 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 FW-1 Web Intelligence kernel 55W beta (the IIS 48K technique probably works with R55W) o IIS/5.0 This is a partial list - there are many pairs we did not test and there are likely many other web servers and cache servers we did not test for lack of hardware and software. Of course, there are probably many more similar techniques.
Yeah, really? I'd like to see a much broader list laid out, and preferably before it becomes another net disaster.
If this was strictly a Microsoft thing we'd be hearing cries for blood, or at least an app to check if your setup was vulnerable. Since it is much broader than that, if checking for this doesn't become part of a security toolkit, we may well wish it had.
Oh well. At least we got this much warning this much in advance. Anyone want to take bets on how long till some malware weasels make this a point and click thing in another script kiddie kit? My guess is before the security world makes a test app to check for it.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
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
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.
http://erichsieht.wordpress.com/category/english/
Does anyone have any idea what the Popular Commercial Cache Appliance is? The PDF doesn't say and we have a few cache appliances at my office (intranet and internet). I'd like to know just vunerable we are to this type of thing.
Official Heretic from the "Church of Global Warming". Proven right thanks to whistle blowers. AGW = Flat Earth Theory
Check back in twelve hours. Whoever feeds the script-kiddies is working on it I'm sure.
Side question: who feeds the script kiddies their "1337 h4x0ring t00ls" anyway? What's in it for them to give weapons to the little bastards? I assume it isn't for the money since I would think that an unknown exploit technique would be immensly valuable in that regard. Is it for the sheer destruction of the thing without the fingerprints?
Can they not just patent the technique and then sue the pants off any hackers?
Shut up! RTFP!
/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.
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
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.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
AC:
Don't worry, we fired the guy who did this on the spot. Thanks for bringing it to our attention.
Signed,
Bill