2007-09-22

Cross Site Tracing

Overview
When i first discovered XST I thought this seems really bad. TRACE is a method accepted by the web server like GET, POST, etc but TRACE basically echoes back the htttp data that you throw at it. Its usually used for debugging and should not be enabled on your production environment after it has been loaded. Since it echoes back the request, it is highly susceptible to Cross Site Scripting. The Goal here is to collect the users session cookie.

The problem is that I cannot think of a way that a user could be mis-lead into executing a XST vulnerability that would be advantagous to the attacker. There are a couple of ways to execute XST... Java sockets, Microsoft.XMLHTTP activeX object, and Flash. The problem with Java sockets is that they will create their own connections separate from the browser and therefore not transmit cookies or sessions. It seems possible with the other two but all three seem to need an existing XSS vulnerability. The only thing that XST gets you is the possibility to steal httpOnly cookies. HttpOnly cookies are not accessible with javascript. To me the real vulnerability would be the XSS and not the XST.


How to test if your server is vulnerable to XST.
To test if your server is vulnerable I will use Burp Suite. Open Burp and choose repeater. Change the request to something similar to :
TRACE / HTTP/1.0
Header1: <script>alert(document.cookie);</script>

The reply should look like this if TRACE is enabled:

HTTP/1.1 200 OK
Date: Sun, 23 Sep 2007 02:48:05 GMT
Server: Apache/1.3.34 (Ubuntu) mod_perl/1.29
Connection: close
Content-Type: message/http

TRACE / HTTP/1.0
Header1: <script>alert(document.cookie);</script>






If you use WebScarab as your proxy then select Manual Request and perform the same steps.

Defenses
Prevention of this vulnerability is really simple. If your using apache then you need to install the mod_rewrite engine. Add the following lines to your httpd.conf file.

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

If your using IIS then you need to filter out everything but GET, POST, and HEAD with urlScan

References
http://msdn2.microsoft.com/en-us/library/ms533046.aspx
http://jeremiahgrossman.blogspot.com/2007/04/xst-lives-bypassing-httponly.html
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
http://www.microsoft.com/technet/security/tools/urlscan.mspx





Slashdot Slashdot It!

5 comments:

Rafa Sánchez said...

I agree with you.

I tried to prove to obtain authentication parameters like basic auth using java sockets but i didn´t get it. I made a proof of concept using apache and one xss and TRACE vulnerable web.

I can see the server logs and the TRACE request is in there but nothing else. No authentication parameters anyway.

XST is not so dangerous i believe.

Anonymous said...

I just found your blog and it looks really good, thanks for that.

Wireless penetration testing said...

Very interesting post I have found, its good to read about confessions of a penetration tester. Thanks for sharing.

Ashutosh Jain said...

Thanks.. It helped..!! :)

ashish kulkarni said...

interesting.........i totally agree with your post