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

[Amit Klein <amit.klein () sanctuminc com>]

Hi Jim,

From your question, I assume you try to poison a browser cache. Let's 
assume that this browser is IE 6.0 (I would speculate that web cache 
poisoining is possible for other browsers as well, but I didn't try it. 
Also, from my experience, each cache entity has its own quirks, which 
must be addressed in order for the attack to succeed). You'd need to 
ensure that the cache setting in IE ("Check for a newer version of the 
page") is set to "every time". Now, the problem with redirection is that 
it may terminate the TCP connection (I don't know the particular 
situation you face, I assume the worst...). Not to mention that IE may 
maintain up to 4 TCP connections (to the same site) in parallel. Keeping 
in mind that the second request (to /index.html) should be sent (by IE) 
on the same TCP connection used for the first (response splitter) 
request, you see that this is a problem (race condition). So what you'd 
ideally need is a way to send multitude of "basic attacks", hoping that 
one of them would succeed. Actually, this is not so hard. Using frames, 
I managed to demonstrate this. I think this is what you're looking for - 
using frames, I forced the browser to send a multitude of requests - a 
blend of response splitters and requests for /index.html. So in many 
cases, this amounted to having IE send a response splitter followed by 
/index.html, on the same TCP connection. In short, you need to send the 
victim an HTML page (e.g. a URL to a site under your control, or an 
email) with a frameset, such that the frames alternate between "response 
splitter" requests and requests to /index.html.
(BTW - you also need to pad the first response to 1024 bytes boundary. 
This has to take into consideration YOUR site, i.e. the exact response 
headers sent by YOUR server).

So, to answer your questions ;-)
1. If you want to poison the browser cache, it's best to start without 
having any additional cache servers on the way to the server. That will 
make sure your situation is kept simple and straight forward ;-)
2. Due to this race condition, it's probably best to have the browser 
send the request to /index.html automatically, alhtough in theory it may 
perhaps be possible to set up a scenario wherein a user request is sent, 
thus forcing the browser to cache the "Shazam" page as matching the user 
request.

I suggest you read pages 19-20 of the paper 
(http://www.sanctuminc.com/pdf/WhitePaper_HTTPResponse.pdf) for a more 
detailed discussion.

Thanks, good luck, and feel free to ask further questions,
-Amit
Amit Klein
Director of security and research, Sanctum
W: +972-9-9586077 x225, F: +972-9-9576337
1 Sapir St., Ampa Bldg., Herzlia 46733 Israel
amit.klein () sanctuminc com <blocked::mailto:amit.klein () sanctuminc com>



Amit,
I reproduced the exploit on IIS with asp pages, and I get the 2 
responses after the first user request to the redir page (I can see them 
using proxytrace tool), but I don't understand how to feed the target 
(my browser) with a second request that would show the shazam page. What 
I see now is the browser redirects to the by_lang page, and any 
subsequent site or page I point my browser to is successful. Is the 
second response held in the browser or does there have to be a caching 
proxy between the browser and web server? Does the second request (to 
index.html in your paper) have to come in the exploit string or can it 
be from any normal user action in the browser?
Thanks, Jim