TELECOM Digest OnLine - Sorted: Http Request Smuggling


Http Request Smuggling


Lisa Minter (lisa_minter2001@yahoo.com)
Sun, 12 Jun 2005 21:10:39 -0500

Some comments of interest from SlashDot over the weekend you might
find interesting to read:

Posted by CmdrTaco on Sunday June 12, @11:28AM
from the this-could-get-fun dept.
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."

The Fine Print: The following comments are owned by
whoever posted them. We are not responsible for them in any way.

by ilyanep (823855) on Sunday June 12, @11:34AM
(#12795033)
(Last Journal: Thursday June 09, @07:18PM)
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.
[ Reply to This ]
a.. Re:Validation by Anonymous Coward (Score:3) Sunday
June 12, @11:40AM
b.. Re:Validation by mp3LM (Score:2) Sunday June 12,
@11:40AM
a.. Ah! by ShaniaTwain (Score:3) Sunday June 12,
@11:58AM
b.. Re:Validation by Jeff DeMaagd (Score:2) Sunday
June 12, @12:19PM
a.. Re:Validation by Master of Transhuman (Score:1)
Sunday June 12, @05:10PM
a.. 1 reply beneath your current threshold.
c.. Re:Validation by AndroidCat (Score:2) Sunday June
12, @11:52AM
a.. That's already what Apache does by wtarreau
(Score:2) Sunday June 12, @12:33PM
a.. Re:That's already what Apache does by AndroidCat
(Score:1) Sunday June 12, @01:00PM
d.. Re:Validation by Lord Kano (Score:2) Sunday June 12,
@02:30PM
e.. Re:Validation by Bert690 (Score:2) Sunday June 12,
@02:55PM
f.. 3 replies beneath your current threshold.

This has been going on for some time. (Score:2, Flamebait)
by WindBourne (631190) on Sunday June 12, @11:41AM
(#12795077)
(Last Journal: Sunday September 21, @09:34PM)
I noticed that 3 months ago.
[ Reply to This ]

Article Text (Score:3, Informative)
by Anonymous Coward on Sunday June 12, @11:43AM
(#12795088)
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

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 m
Read the rest of this comment...

[ Reply to This ]
a.. patent blanket! by matt me (Score:1) Sunday June 12,
@03:17PM
b.. Re:Article Text -- Karma whoring???? by camusflage
(Score:2) Sunday June 12, @02:02PM
c.. 1 reply beneath your current threshold.

piggybacking (Score:2, Funny)
by Edzor (744072) on Sunday June 12, @11:53AM (#12795146)
I like to use 'piggybacking' as well, it makes me sound
technical but cool at the same time.
[ Reply to This ]

Why is this news? (Score:2, Insightful)
by duh_lime (583156) on Sunday June 12, @11:54AM
(#12795156)
If there is ANY communications path, it can be used for
anything... If you have cooperating applications, anything that passes at
least "a bit" can be subverted for another purpose. You could do Morse code
using ICMP Echo Requests, with the packet size determining whether it's a
dot or a dash... Whatever... Again, why is this particular technique news?
[ Reply to This ]
a.. Re:Why is this news? by cduffy (Score:2) Sunday June
12, @12:39PM
Re:Why is this news? (Score:5, Insightful)
by segmond (34052) on Sunday June 12, @03:26PM
(#12796508)
(http://www.segmond.com/)
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.
[ Reply to This | Parent ]

a.. Re:Why is this news? by argent (Score:2) Sunday
June 12, @10:02PM
b.. 1 reply beneath your current threshold.

I think this appeared in DDJ sometime ago... (Score:1)
by soapdog (773638) on Sunday June 12, @11:54AM
(#12795158)
(http://www.soapdog.org/)
Folks, hiding one HTTP request inside another is not the
same HTTP request hijacking technique that appeared in Doctor Dobbs journal
some months ago... I can't recall the edition...
[ Reply to This ]
a.. Re:I think this appeared in DDJ sometime ago... by
cyphersteve (Score:1) Sunday June 12, @02:57PM

Question of Compatibility vs. Reliability (Score:5,
Insightful)
by l2718 (514756) on Sunday June 12, @11:55AM (#12795161)
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.

[ Reply to This ]
Re:Question of Compatibility vs. Reliability
(Score:4, Insightful)
by iabervon (1971) on Sunday June 12, @01:11PM
(#12795669)
(http://iabervon.org/~barkalow/ | Last Journal:
Saturday May 31, @03:01AM)
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.
[ Reply to This | Parent ]

a.. Re:Question of Compatibility vs. Reliability by
Lord Kano (Score:2) Sunday June 12, @02:39PM

Be very careful (Score:5, Funny)
by Anonymous Coward on Sunday June 12, @11:58AM
(#12795178)
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.
[ Reply to This ]
a.. Re:Be very careful by PerspexAvenger (Score:1)
Sunday June 12, @12:08PM
b.. 1 reply beneath your current threshold.

Possible way to burn down RSS? (Score:3, Interesting)
by krowten21 (891493) on Sunday June 12, @12:03PM
(#12795215)
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.
[ Reply to This ]
a.. Re:Possible way to burn down RSS? by SpaceLifeForm
(Score:2) Sunday June 12, @04:55PM

Quick Summary (Score:3, Informative)
by MojoRilla (591502) on Sunday June 12, @12:08PM
(#12795244)
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.
[ Reply to This ]
a.. Re:Quick Summary by wfberg (Score:2) Sunday June 12,
@01:10PM
a.. Re:Quick Summary by John Hasler (Score:2) Sunday
June 12, @02:26PM
b.. Re:Quick Summary by MooseGuy529 (Score:3) Sunday
June 12, @02:38PM
c.. 1 reply beneath your current threshold.

Hype it up? (Score:1, Insightful)
by Anonymous Coward on Sunday June 12, @12:12PM
(#12795264)
This paper discusses potential exploitation of poor HTTP
parsing in specific applications. Potential applications include cache
poisoning and hijacking user credentials but it requires the victim to be
behind a vulnerable proxy/firewall.

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.
[ Reply to This ]
a.. Re:Hype it up? by Sven Tuerpe (Score:2) Sunday June
12, @12:46PM
b.. 2 replies beneath your current threshold.

publicfile (Score:2, Informative)
by sugarmotor (621907) on Sunday June 12, @12:12PM
(#12795271)
(http://stephan.sugarmotor.org/)
http://cr.yp.to/publicfile.html [cr.yp.to], publicfiloe,
is not mentioned.
[ Reply to This ]

Well this is not good (Score:2, Insightful)
by suitepotato (863945) on Sunday June 12, @12:33PM
(#12795404)
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.
[ Reply to This ]
a.. Tomcat workaround by mparaz (Score:2) Sunday June
12, @03:24PM

Working example available? (Score:2)
by pongo000 (97357) on Sunday June 12, @12:36PM
(#12795423)
The world is full of hypotheticals...can someone actually
point us to a working example of this alleged exploit? If not, I'll just
file it away as "cool information with little practical impact on my daily
life."
[ Reply to This ]
a.. Re:Working example available? by failure-man
(Score:2) Sunday June 12, @01:25PM
b.. Re:Working example available? by slavemowgli
(Score:2) Sunday June 12, @01:44PM

PCCA?? (Score:2, Interesting)
by d3ac0n (715594) on Sunday June 12, @12:56PM (#12795570)
(Last Journal: Monday October 13, @10:39AM)
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.
[ Reply to This ]
a.. Re:PCCA?? by cyphersteve (Score:2) Sunday June 12,
@02:50PM
b.. Re:PCCA?? by d3ac0n (Score:1) Sunday June 12,
@01:25PM
c.. 1 reply beneath your current threshold.

Smuggling, eh? (Score:1)
by Aldric (642394) on Sunday June 12, @03:43PM (#12796617)
When will HTTP Customs be introduced as a fix?
[ Reply to This ]

Re:Problem reading the PDF... (Score:3, Funny)
by Dogers (446369) on Sunday June 12, @11:39AM (#12795064)
(Last Journal: Saturday May 07, @10:10AM)
Tried to do a copy and paste, but the lameness filter wont
let me. DRM in force! ;)
[ Reply to This | Parent ]
a.. I AC posted the article by camusflage (Score:2)
Sunday June 12, @11:50AM
b.. Re:Problem reading the PDF... by Damhna (Score:1)
Sunday June 12, @11:54AM

Re:and here's where... (Score:3, Interesting)
by Anonymous Coward on Sunday June 12, @11:59AM
(#12795191)
Actually the whitepaper sates that IIS and Apache
automatically dump the malformed packet.

Microsoft does write a few good lines of code.
[ Reply to This | Parent ]
a.. Re:and here's where... by ohzero (Score:1) Sunday
June 12, @12:15PM
b.. Re:and here's where... by gtwilliams (Score:1)
Sunday June 12, @01:12PM
c.. Re:and here's where... by drumist (Score:1) Sunday
June 12, @05:06PM

Re:Problem reading the PDF... (Score:3, Informative)
by Anonymous Coward on Sunday June 12, @12:00PM
(#12795197)
Here is a link:
http://www.gatech-edu.org/HTTP-Request-Smuggling.p df
[gatech-edu.org]
[ Reply to This | Parent ]
a.. Re:Problem reading the PDF... by arose (Score:2)
Sunday June 12, @01:37PM
b.. Re:Problem reading the PDF... by shepmaster
(Score:1) Sunday June 12, @05:25PM

Re:and here's where... (Score:1)
by ohzero (525786) <mharrigan@f8e n t ertainment.com> on
Sunday June 12, @12:12PM (#12795272)
(http://www.f8entertainment.com/ | Last Journal: Tuesday
September 09, @02:59PM)
flamebait? Anyone with half a clue would understand that
this is just a fact. If you don't believe me.. watch the updates. I
guarantee you that headlines will read almost verbatim what I said come
Monday.

Then again, this is slashdot... I guess I shouldn't expect
people to understand things.
[ Reply to This | Parent ]

Re:Prediction (Score:1, Insightful)
by Anonymous Coward on Sunday June 12, @12:36PM
(#12795426)
This is Slashdot, News for Nerds, not "your average bloke
on the street".

Your post would make alot more sense if the article was
mentioned on CNN.com or the like, but not here.
[ Reply to This | Parent ]

Re:Old news... (Score:2)
by Panaflex (13191) on Sunday June 12, @01:57PM
(#12795941)
I wrote my own web server 5 years ago.. faster than
Apache, cheaper than others. Doesn't have this problem.

-Pan
[ Reply to This | Parent ]
a.. Re:Old news... by rbarreira (Score:2) Sunday June
12, @03:45PM
b.. 1 reply beneath your current threshold.

Re:Old news... (Score:2)
by JRHelgeson (576325) on Sunday June 12, @02:26PM
(#12796125)
(Last Journal: Sunday October 19, @05:54PM)
Bah, I'm a reseller who enjoys a product... is it so wrong
to share it with people? I have no dog in this fight.
[ Reply to This | Parent ]

a.. 9 replies beneath your current threshold.

By failing to prepare, you are preparing to fail.
All trademarks and copyrights on this page are owned by their
respective owners. Comments are owned by the Poster. The Rest © 1997-2005
OSTG.

[ home | awards | contribute story | older articles | OSTG | advertise
| about | terms of service | privacy | faq | rss ]

Post Followup Article Use your browser's quoting feature to quote article into reply
Go to Next message: Lisa Minter: "Snocap Opens to Independent Artists"
Go to Previous message: Joseph: "Re: Mac iBook and Bluetooth Cordless Headphones?"
TELECOM Digest: Home Page