Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security IT

HTTP Request Smuggling 99

Posted by CmdrTaco 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."
This discussion has been archived. No new comments can be posted.

HTTP Request Smuggling More

HTTP Request Smuggling

Comments Filter:

  • Validation (Score:3, Funny)

    by ilyanep ( 823855 ) on Sunday June 12, 2005 @10:34AM (#12795033) Journal
    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 (Score:3, Insightful)

      by 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.

    • Re:Validation (Score:2, Insightful)

      by mp3LM ( 785954 )
      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).

      Are you serious?!?!? This could kill an already decently loaded web-server.
      If it's twice as many packets, that's doubling the workload!

      Also, I think you mis-read the issue. The issue isn't someone hijacking someone elses HTTP request, it's someone who wants to attack a server by sending a request inside there own request, in which case the checksum

      • Ah! (Score:3, Funny)

        by ShaniaTwain ( 197446 )
        Yes, but if you use HTTP Request Snuggling you wont mind the extra packets.

        Everybody likes snuggling.
      • If it's twice as many packets, that's doubling the workload!

        Now you have both typing and and conversational math. You will go far.
        • Nice.

          I was about to cut and paste your "and and", then say "You will not." Unfortunately I cannot, so the rest of this post is not directed at you. Instead it is a rant about Firefox.

          One of Firefox's NUMEROUS bugs just bit, and I can no longer cut and paste!

          Somebody kindly fix Firefox's NUMEROUS MEMORY LEAKS!

          Jesus, now I can NOT use the goddamn APOSTROPHE without it jumping to the FIND bar!

          If this shit keeps up, it IS back to Opera!

          Mozilla, STOP adding FEATURES until you FIX THE FUCKING BUGS!

    • Re:Validation (Score:2, Informative)

      by AndroidCat ( 229562 )
      Why not just (a) be less trusting of Content-Length, and (b) reject malformed requests with two of them?
      • 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
        • A HTTP request is supposed to end with a CR/LF. If that's not what's at the end of the Content-Length, perhaps the request should be dumped? (I'm too lazy to check the RFCs to see how binding that requirement should be.)

    • Re:Validation (Score:3, Insightful)

      by Lord Kano ( 13027 )
      Anyone capable of pulling off a man in the middle attack could intercept the MD5 sum. Send the user a false one, return a valid MD5 to the server and go on as usual.

      LK

    • Re:Validation (Score:3, Informative)

      by Bert690 ( 540293 )
      Getting the server to ack each page is going to be very costly, plus it doesn't actually solve the fundamental "man in the middle" vulnerability of HTTP, which is the basis of this and many other attacks on HTTP and its implementations.

      There are already some simple proposals [ibm.com] that go a long way to solving the man in the middle issue already, without resorting to grossly inefficient schemes such as yours (or HTTPS). The problem is in getting them adopted.

  • I noticed that 3 months ago.
    • lamefilter: # Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

  • Article Text (Score:4, Informative)

    by Anonymous Coward on Sunday June 12, 2005 @10: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
    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

  • piggybacking (Score:2, Funny)

    by Edzor ( 744072 )
    I like to use 'piggybacking' as well, it makes me sound technical but cool at the same time.

  • Why is this news? (Score:1, Insightful)

    by duh_lime ( 583156 )
    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?
    • Because some applications are cooperating although they're not supposed to.

    • Re:Why is this news? (Score:5, Insightful)

      by segmond ( 34052 ) on Sunday June 12, 2005 @02:26PM (#12796508)
      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.
  • 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...

  • Question of Compatibility vs. Reliability (Score:5, Insightful)

    by l2718 ( 514756 ) on Sunday June 12, 2005 @10: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.

    • Re:Question of Compatibility vs. Reliability (Score:5, Insightful)

      by iabervon ( 1971 ) on Sunday June 12, 2005 @12:11PM (#12795669) Homepage Journal
      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.
      • ...The proper thing to do is always pass on correctly-formed input...

        That's what this attack exploits: two interpretations of what is 'correctly-formed input'. The cache/proxy looks at the request and says "yep looks good" and sends it on. It sees valid input. The workstation, on the other hand, takes the same request and sees something different, hence the exploit. It won't make a difference if the cache/proxy rewrites it or not, because it will simply repeat the attack to the workstation. If you mean t

  • Be very careful (Score:5, Funny)

    by Anonymous Coward on Sunday June 12, 2005 @10: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.

  • Possible way to burn down RSS? (Score:3, Interesting)

    by krowten21 ( 891493 ) on Sunday June 12, 2005 @11:03AM (#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.

  • Quick Summary (Score:5, Informative)

    by MojoRilla ( 591502 ) on Sunday June 12, 2005 @11:08AM (#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.
    • Or to look at it another way;
      crappy firewall/proxy software does a crappy job at parsing pipelined HTTP and allows people to get at banned content or to have their caches poisoned. You wouldn't expect them to do a half-assed job, as it's their entire purpose in life to make sure malicious traffic doesn't occur, so the least they could do is strict parsing.

      Webservers do a better job of parsing HTTP headers, and where they fail, it just results in an additional request that's interpreted as per usual, so no

    • Re:Quick Summary (Score:3, Insightful)

      by MooseGuy529 ( 578473 )
      Due to bad handling of borderline html

      You mean HTTP, right?

  • Hype it up? (Score:1, Insightful)

    by Anonymous Coward
    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.

    • Re:Hype it up? (Score:4, Insightful)

      by Sven Tuerpe ( 265795 ) <sven@nospAm.gaos.org> on Sunday June 12, 2005 @11:46AM (#12795509) Homepage
      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.

  • publicfile (Score:3, Insightful)

    by sugarmotor ( 621907 ) on Sunday June 12, 2005 @11:12AM (#12795271) Homepage
    http://cr.yp.to/publicfile.html [cr.yp.to], publicfiloe, is not mentioned.
  • 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
  • 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."
    • 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?
      • Giving the tools to the script kiddies keeps the noise ratio high. It's not too likely that someone is going to be able to keep a vulnerability as their own personal in, so by making the tools commonly available, it makes the random attacks indistinguishable from the targeted attacks.

  • PCCA?? (Score:2, Interesting)

    by d3ac0n ( 715594 )
    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.
  • When will HTTP Customs be introduced as a fix?

  • The fault here lies with broken HTTP implementations, not with the protocol or with interactions between compliant implementations. Taking just the first example from the paper, any implementation that receives 2 "Content-Length" headers should reject the request because it's an illegal format.

    Content-Length: 0[CRLF]
    Content-Length: 44[CRLF]

    is exactly the same as

    Content-Length:0, 44

    by the multiple-header rule (RFC 2616 sec. 4.2), but Content-Length doesn't allow multiple values (ibid sec. 14.13).

Slashdot Top Deals

I THINK THEY SHOULD CONTINUE the policy of not giving a Nobel Prize for paneling. -- Jack Handley, The New Mexican, 1988.

Close