A bit of information about TRACE and OPTIONS

Hi!! Another post here after a some time... I'm really busy at work right now but I also need these small breaks to carry out my own testing and share a bit of what we learn here at Pentura.

I want to write today about the TRACE, OPTIONS and others HTTP verbs. Sometimes in reports we can see that they discovered the TRACE verb active in our server. How they (us ;) ) do it? How do we test to understand if it's a real vulnerability? If it's a vulnerability... what is the risk?

First of all when we test a web application, we perform an OPTIONS request to the server to discover the verbs the server offers. It can be done using a simple telnet or ncat connection to the server but today we are going to use the Metasploit framework:

Using the auxiliary/scanner/http/options module we can easily discover the HTTP verbs we offer in www.pentura.com. In this case we only accept GET, HEAD, POST and OPTIONS :)

Sometimes we can also see the TRACE method listed in the OPTIONS request and programs will warn you about this. OK, but, is it a risk?

Before knowing if it's a risk or not we have to understand how can an attacker use the TRACE method to exploit your server. The attack is called XST or Cross Site Tracing. Using this, an attacker could steal our cookies and use them to hijack our session in the server. This is useful when the cookies have the httpOnly flag. This is a small attribute that can be applied to cookies to prevent the access to them using Javascript.

The TRACE method responds back with the same headers that we sent in the request so, if our request contains our cookies, they will come back in the TRACE response.

But... don't worry! Sometimes people add this to reports because the automatic scanner discovers it but they don't test manually if it's possible to exploit this vulnerability. I'll show you how to do it!

pedro@pedro:~$ ncat www.apache.org 80
OPTIONS / HTTP/1.1
Host:www.apache.org

HTTP/1.1 200 OK
Date: Wed, 09 Jun 2010 16:13:37 GMT
Server: Apache/2.2.12 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.7d mod_wsgi/3.2 Python/2.6.5rc2
Allow: GET,HEAD,POST,OPTIONS,TRACE
Cache-Control: max-age=86400
Expires: Thu, 10 Jun 2010 16:13:37 GMT
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/html

pedro@pedro:~$ ncat www.apache.org 80
TRACE / HTTP/1.1
Host:www.apache.org
X-Header: Test

HTTP/1.1 200 OK
Date: Wed, 09 Jun 2010 16:14:49 GMT
Server: Apache/2.2.12 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.7d mod_wsgi/3.2 Python/2.6.5rc2
Transfer-Encoding: chunked
Content-Type: message/http

TRACE / HTTP/1.1
Host: www.apache.org
X-Header: Test

As you can see, when we send the OPTIONS verb we see that the TRACE verb is allowed. This means that we need to test it, not only put in our report as a vulnerability. The next request I made is a TRACE request with the X-Header fake value. The server responds with a 200 OK code and with my fake header value. This is the proof that the risk is present in this server. If the response is other means that the server is not vulnerable to XST attacks.

I hope this helps you understand better whats means these TRACE enabled vulnerability in the reports :)

P.D. For those Firefox lovers... Check this extension to test the OPTIONS headers inside your browser: HTTP Resource Test