RE: A new Sanctum white paper: "Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics"

From: Amit Klein (amit.klein_at_sanctuminc.com)
Date: 03/07/04

  • Next message: Tim Yamin: "[ GLSA 200403-01 ] Libxml2 URI Parsing Buffer Overflow Vulnerabilities"
    Date: Sun, 07 Mar 2004 12:13:14 +0200
    To: jeremiah@whitehatsec.com, webappsec@securityfocus.com, bugtraq@securityfocus.com
    
    

    Hi Jermiah, lists.

    Jeremiah and I exchanged few emails over the weekend, and I would like
    to summarize them into this response.

    Please see below (my comments are marked with "***").

    Thanks,
    -Amit

    -----Original Message-----
    From: Jeremiah Grossman [mailto:jeremiah@whitehatsec.com]
    Sent: Friday, March 05, 2004 19:41
    To: webappsec@securityfocus.com; bugtraq@securityfocus.com
    Cc: Amit Klein
    Subject: Re: A new Sanctum white paper: "Divide and Conquer - HTTP
    Response Splitting, Web Cache Poisoning Attacks, and Related Topics"

    Amit's paper is extensive and very detailed. It contains interesting
    results and illustrates clever techniques used to poison web cache.

    *** Thanks :-)

    I am attempting to condense the material to its core concepts. Amit,
    please correct me if I make any errors.

    *** Sure. The original message you sent was very good - it really did
    capture my intention. Few comments follow...

    This technique builds upon the scenario that user-supplied data is
    inserted into the headers of an HTTP response message. When this occurs,
    a misbehaving web server/application may cause adverse affects of an
    intermediary cache.

    Scenario 1: Vulnerable web site

    GET /redirect%0aX-Test:%20foo_test HTTP/1.0

    *** The "canonical" way of doing this is to inject both CR (%0d) and LF
    (%0a), thus making sure the response(s) conform to the standard...

    HTTP/1.1 302 Found
    Date: Fri, 05 Mar 2004 16:41:31 GMT
    Server: Apache/1.3.29
    Location: http://foo.com/redirect
    X-Test-Header: foo_test
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

    In this case, the web server/application unescaped the user-supplied
    data destined for the Location header. The result added a new "X-Test"
    header to the response. The new header could have easily been anything
    else, including "Set-Cookie". The important part is that an attacker has
    the ability to force the web site to serve up altered or invalid HTTP
    responses.
    Including making the result look like two separate HTTP Responses (Hence
    HTTP Response splitting). I have found a few places in the wild that
    exhibit this behavior.

    Example:

    GET
    /redirect%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/
    1.0%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-
    Length:%200%0d%0a%0d%0a

    The result would "look like" two independent HTTP responses.

    HTTP/1.1 302 Moved Temporarily
    Date: Wed, 24 Dec 2003 15:26:41 GMT
    Location: http://foo.com/redirect
    Content-Length: 0

    HTTP/1.0 200 OK
    Content-Type: text/html
    Content-Length: 0

    A cache may improperly parse the response since it looks like two
    independent messages. The next HTTP request recieved might be attached
    to the seemingly second HTTP response.

    *** Basically this is a good description. But for sake of accuracy (and
    for the fun in splitting hairs...), it should be said that the proxy
    server probably first parses the first response (wihtout parsing the
    rest of the data), and only parses the rest of the data as the second
    response when it is needed, i.e. when after the second request is
    processed by it (the proxy). So (I think), at no time does the proxy has
    two *parsed* HTTP responses in the "queue".

    If it does, then you have the cache poisioning scenarios outlined in the
    white paper.

    Scenario 2: Not-Vulnerable web site

    GET /redirect%0aX-Test:%20foo_test HTTP/1.0

    HTTP/1.1 302 Found
    Date: Fri, 05 Mar 2004 16:41:31 GMT
    Server: Apache/1.3.29
    Location: http://foo.com/redirect /redirect%0aX-Test:%20foo_test
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

    In this case, the web server/application did NOT unescape the
    user-supplied data. The URL encoded data remains, as is, within the
    Location header. I would say the web site should have done some addition
    sanity checking by not allowing certain URL encoded characters to pass.
    But its hard to classify this as a vulnerability. If the cache is still
    confused, then the issue is there.

    *** "cache confused" means (per a private discussion) that the cache
    server URL-decodes the Location URL *while* parsing the line, thus
    CRs/LFs found in the URL are mistakingly considered as end of header. I
    find this quite unlikely for a popular proxy server to behave this way,
    as it breaks application logic (such proxy will also misinterpret
    encoded spaces, #, &, =, as well as "innocent" CRs and LFs).

    Here are the vulnerability requirements.
    1) User-supplied data is inserted in the headers of an HTTP Response
    2) User input is unescaped.

    *** I would like to mention that re-URLencoding the data in the Location
    header (or in other HTTP headers?), or keeping the data in its encoded
    form, are not the only solutions. For many applications, simply
    filtering out the CR/LF characters should do the trick.

    The results could have the ability to poison the cache in an
    intermediary device or a web browser.

    *** Yes. That's the main focus of the paper. But there's more, so, per
    Jeremiah's suggestion, I list below all the results:
    1. HTTP Response Splitting technique
    1.1 Usable for Web Cache Poisoning
    1.1.1 Poisoning reverse proxies (usually at the site)
    1.1.2 Poisoning forward proxies (usually at the ISP)
    1.1.3 Poisoning browser cache
    1.2 Usable for cross-user defacement
    1.3 Usable for response hijacking
    1.4 Usable for XSS
    2. Cross-host web cache poisoning (virtual hosting scenario)
    3. Cross-host limited cache poisoning (virtual hosting scenario),
    without owning a virtual host
    4. Overcoming ASP.NET 1.1 anit-XSS pattern when CRLF injection is
    possible into the Set-Cookie header

    Regards,

    Jeremiah-

    On Thursday, March 4, 2004, at 10:12 AM, Amit Klein wrote:

    > Hi
    >
    > Today, Sanctum released a new whitepaper, titled "Divide and Conquer
    > - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related
    > Topics". The full paper can be found in the following link:
    > http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf
    >
    > The paper's abstract is copied below:
    >
    >


  • Next message: Tim Yamin: "[ GLSA 200403-01 ] Libxml2 URI Parsing Buffer Overflow Vulnerabilities"

    Relevant Pages