Security challenges for the summer

Hello! The summer is here and the holidays are near!

Planning something to do? Too much free time as you don't have to do any exams in September? Looking for something to learn? Me too! :)

Each summer I plan something to learn, something to investigate... basically something to help me enjoy my free time! This summer I'm going to focus on:

• Firefox addons development (Check this Hackbar Google Code website)
• HTML5

I'll also try to keep my mind fit by playing online challenges games. If you want to practice and learn about security you can check the following websites:

• The Bright Shadows
• Try2Hack
• Hack This Site

Enjoy and keep out of direct sunlight ;)

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

Mixed content in different browsers

In security, one of the most old and famous attacks is Man In The Middle attack. With this technique we can read all the packets the user is sending to a server and analyse it. The solution? Use a secure layer to encrypt all the traffic.

This, for web sites, require that the user browser use the HTTPS protocol. This relay in the authenticity of the server certificate and the trust relation between the browser and the certificate authority. It can be broken, but is not the point of this post, maybe for other one :)

If a website mix secure (HTTPS) and insecure (HTTP) content in the same page an attacker sniffing the net will be able to see, for example, our session cookie in clear text. This is a big risk if the attacker has control over the web content we are browsing (using a stored XSS attack) and insert some insecure reference on it to catch our cookie session.

The way the browsers controls this is different in each one, but always insecure. The last version of Internet Explorer can be configured to check if we are loading insecure resources and block them. The result is that we don't see the insecure images if we decide to block. But it's really blocking the resources or only hiding them?

I create a secure web page which load different (mixed) content. Using Wireshark to look the request my browser is doing I can determine that IE8 is currently making the request and, if the user decide to "block" it, only hide it.

 

This can make the user think he is safe when the request (and his cookie sessions) has been sended in clear text.

The other browser I tested is Firefox. When Firefox detect mixed content it load it and show an alert to the user to warn him about it. This is the same insecure process that Internet Explorer, but in this case the webpage is render normally so the user doesn't have the false security feeling when the images are blocked by IE.

I, a huge fan of Firefox and the possibility to expand it using addons, have created a Greasemonkey script to try to prevent this insecure behaviour of Firefox. It's called Mixed Content Protection and can be installed from the userscripts community web page. It requires Greasemonkey to work.

The script is very simple. It works only when we are accessing to HTTPS web pages and search for all the insecure references* in the HTML source code. It executes before the page loads, so it can change "on-the-fly" all these insecure references for the secure ones. If the secure object is not accessible it will not be loaded using a insecure protocol.

Currently it search for:

• All src attributes: img, iframe, object, script, etc.
• The href attribute of link tags for css files
• The insecure value in the param tag to the movie resource.

I think with these references it will cover mostly of the cases but, if you know any other resource can be loaded insecurely, please, feel free to comment me. Also it can fail in some cases, if you detect any issue please let me know :)

* Currently the script only works for the body tag elements, so any insecure reference in the header of the file will be load. It also doesn't work with resources loaded from Javascript or CSS files.

Thanks to Chema Alonso for draw my attention[Spanish blog, sorry] to this web browsers issue.

Using Firefox as a penetration test tool

Today I'm going to do a speak at "Reading Geek Night 4" about how to use Firefox as a pentesting tool.

It's going to be a short talk with some demos and I'll show different more or less common Firefox extensions and how use them to bypass or test the security in web pages. You can read more about it at the official web page.

See you there!

UPDATE: I just post in my personal blog some information about the talk and the extensions I used.