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

The danger of the default files

(This post was originally posted in my own personal blog)

During my current research I have found some default files that some web frameworks includes into their installations that can compromise the security of a website. It also can allow an attacker to determine which framework a web page is using.

The first of these files is from the symfony framework. They offer to the developers a useful script called frontend_dev.php which show internal information about the current install and the server. As you can see in the following screenshot the information can be very useful…



It’s deactivated by default and can be activated changing the “lib\config\config\settings.yml” file:

# Logging and debugging settings

web_debug: false # Enable the web debug toolbar

By default the framework is configure not to show the toolbar, but a lot of web pages (indexed by Google) have activate it and allow to any user to read the private data of their websites.



Moreover another default files that I found researching into the default Zend Server installation are the alias /server-info and /server-status. These are part of the mod_info module and, hopefully, in Zend Server, are configured to be access only from localhost:

<Location>
SetHandler server-info
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

<Location>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

This is a secure default configuration that other domains using this Apache module should adopt for the security of their web pages. This is a problem discussed sometimes ago with the revelation of the /server-status file in twitter.com. It’s also known that other servers like Apache.org are offering his status and his info, but you can also found a lot of websites sharing their server-status and server-info pages.

I have found that these default files are not include in the wordlist of wfuzz or even Wikto. I don’t know why are they ignoring these files, but I’m going to add these to my default dictionaries files :)

Cheers!