Message-ID: <404AF5BA.3060402@sanctuminc.com>
Date: Sun, 07 Mar 2004 12:13:14 +0200
From: Amit Klein <amit.klein@...ctuminc.com>
To: jeremiah@...tehatsec.com, webappsec@...urityfocus.com,
	bugtraq@...urityfocus.com
Subject: RE: A new Sanctum white paper: "Divide and Conquer - HTTP Response
 Splitting, Web Cache Poisoning Attacks, and Related Topics"


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@...tehatsec.com]
Sent: Friday, March 05, 2004 19:41
To: webappsec@...urityfocus.com; bugtraq@...urityfocus.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:
 >
 >

Powered by blists - more mailing lists