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: 

  
  
  
  
  

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

  
  
  foo
  
  

http://www.evil.site/3.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 [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: 

  
  
  
  
  

http://www.evil.site/2.asp: 
  <%
  Response.addHeader "Proxy-Connection","Keep-Alive"
  %>
  
  
  foo
  
  

http://www.evil.site/3.asp: 

  <%
  Response.addHeader "Proxy-Connection","Keep-Alive"
  %>
  
  
  
  
  
  
  
  
  
  

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:

  
  
  
  foo
  
  

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: 

  
  
  
  
  

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

  
  
  
  foo
  
  

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

  
  
  
  
  

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