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

New version of Wfuzz!

I don't like automatic tools. Full stop. Well... not full... I like some semi-automatic tools.

One of these tools is wfuzz. I love this python script to perform a quick look over all the directories in a website and sometimes to test against some basic authorization bypass fuzzing a numeric parameter.

The use of this tool is very easy and I'm not going to explain here, you can read the README file from the package but I'm going to explain you some of the changes in this new version.

First of all if you want to download it you will need a subversion client as they are starting to use Google Code to distribute wfuzz and they don't offer any zip file right now.

Then you can test it as I show in the screenshot:

python wfuzz.py -z file -f wordlist/general/common.txt --hc 404 -c -t 1 http://test.acunetix.com/FUZZ

If you are a wfuzz user you already notice the inclusion of the chars column in the result output. This can be useful when either lines and words are the same in a specific page. First new feature!! You can filter using the number of chars with the --hh parameter

Other of the differences in this new version is the inclusion of more dictionaries. Now they add more and split them into categories:

pedro@pedro:~/wfuzz$ tree wordlist/
wordlist/
|-- general
|   |-- admin-panels.txt
|   |-- big.txt
|   |-- catala.txt
|   |-- common.txt
|   |-- euskera.txt
|   |-- extensions_common.txt
|   |-- medium.txt
|   |-- megabeast.txt
|   |-- mutations_common.txt
|   |-- spanish.txt
|   `-- test.txt
|-- Injections
|   |-- All_attack.txt
|   |-- bad_chars.txt
|   |-- SQL.txt
|   |-- Traversal.txt
|   |-- XML.txt
|   `-- XSS.txt
|-- others
|   |-- common_pass.txt
|   `-- names.txt
|-- stress
|   |-- alphanum_case_extra.txt
|   |-- alphanum_case.txt
|   |-- char.txt
|   |-- doble_uri_hex.txt
|   |-- test_ext.txt
|   `-- uri_hex.txt
|-- vulns
|   |-- apache.txt
|   |-- cgis.txt
|   |-- coldfusion.txt
|   |-- dirTraversal-nix.txt
|   |-- dirTraversal.txt
|   |-- dirTraversal-win.txt
|   |-- domino.txt
|   |-- fatwire_pagenames.txt
|   |-- fatwire.txt
|   |-- frontpage.txt
|   |-- iis.txt
|   |-- iplanet.txt
|   |-- jrun.txt
|   |-- netware.txt
|   |-- oracle9i.txt
|   |-- sharepoint.txt
|   |-- sql_inj.txt
|   |-- sunas.txt
|   |-- tests.txt
|   |-- tomcat.txt
|   |-- vignette.txt
|   |-- weblogic.txt
|   `-- websphere.txt
`-- webservicces
    |-- ws-dirs.txt
    `-- ws-files.txt

They also add three points to the changelog:

• Added hexa-rand payload (Thanks to Alice Kaerast)
• Fixed encoding problems (Thanks to Osama Elnaggar)
• Fixed problems in the headers parsing (Thanks to Osama Elnaggar) 

I just update my tools folder with this new version and now we can keep our version update using svn :) Nice work guys!!

Shorty Authentication Bypass

(This post was posted originally at my personal own blog and also featured in the exploit-db.com website)

Today, reading some stuff at internet I have found an article about 7 PHP scripts to generate shorts URLs. This kind of links are very common today with a lot of controversy about the security risk that they implied. I’m not here (now) to discuss about shorting URL’s services but to talk about a stupid bug that I have found in the first (!!!) software that WebResourcesDepot recommend today.

Shorty is a script very old… From 2006. Why are they recommending it in the first place? Second: Did they try to install it? A lot of errors appears when you try a fresh install and some pain until you can fix it. Buggy from the scratch.

I then decided to read some source code. I have found that in functions.php is some bug that we can use to bypass the login form. Let's go to read some php code:

function authenticate(){
    $cookie = @$_COOKIE['snickerdoodle'];
    if($cookie == "polarbears"){
        //
    } else {
        exit("Not logged in.");
    }
}

function verify(){
    if(@$_COOKIE['snickerdoodle']){
        $cookie = $_COOKIE['snickerdoodle'];
    } else {
        $cookie = '';
    }
    if($cookie == "polarbears"){
        return 1;
    } else {
        return 0;
    }
}

As you can read this code generates a cookie with the name “snickerdoodle” and the value “polarbears” to determine if you are authenticated or not. Its very easy to create a new cookie into your browser with this data with some Firefox extension. If you are using a browser without extensions like Google Chrome you can try to write the next javascript sentence into your URL:

javascript:document.cookie=”snickerdoodle=polerbears”;

If you don’t want to install Shorty (and mess around with all the hacks you have to do use it) you can always use the search intitle:”Shorty (Beta)” to found some places to test it.

Have fun!

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!

Web security news and the "Hack of the Year"

Long time since my last post but I was a bit busy on customer on-site testing. Nice days of application testing but now is time to write here again.

I read long ago a fantastic book about security named "The Art Of Intrusion" wrote by the (in)famous Kevin Mitnick. He told amazing histories about security and intrusions without giving too much technical details about them but the enough to understand the attack and catch the idea behind the security problem the system had. News about security are (sometimes) the same. I said "sometimes" because reporters who wrote about security doesn't really use to know anything about security, but this is something to another post...

Today I want to introduce you two websites about web security / cracking. The first one is a website that intends to collect all these web security incidents around the world. It's called The Web Hacking Incident Database and offers reports of the hacked websites around the world, including, in most of the cases, some technical information. It's worth a lecture to understand how important is the web security nowadays.

The other one is really a clone of the famous milw0rm website (I'm not going to link it because is currently abandoned) called Inj3ctor.They published a few days ago a paper claiming that they had hacked Facebook. Wooohhh... really? Let's go check the report:

• They start doing a port scan of facebook.com
• After that they do some simple Google search queries trying to identify some PHP errors because is well know that Facebook is developed in this language.
• A quick look into the robots.txt file can focus us into specific (and usually privates) web pages.
• After these tests against facebook.com they move to apps.facebook.com and detect some vulnerabilities in third parties applications. These applications are not developed by Facebook and are not hosted in the Facebook servers.

They got a lot of information from MySQL databases using simple SQL Injections and claim that the information they obtained is from Facebook. Ok, sometimes people get really excited too soon. In this case the called it: "Hack of the year!".

If you are going to call something the "Hack of the year" be sure it is... Because:

1. Facebook doesn't use MySQL, they use Cassandra.
2. The path showed in the PHP errors points clearly to another server (http://tomkincaid.dreamhosters.com/)
3. Wordpress? I'm pretty sure that is not any Wordpress installation running in the Facebook servers.
4. Don't say your exploit is the "Hack of the year", wait until the community say it: http://pwnie-awards.org/

That's all for now, more other day with an exciting project I want to release in any point next week :) Cheers!

2010 CWE/SANS Top 25 Most Dangerous Programming Errors

A few weeks ago was released a new version of the "Top 25 Most Dangerous Programming Errors" list about coding bugs that the MITRE and SANS released last year. This new version comes with a better layout to a better understanding about the risks, the remedies and focus into the identification of the problem.

From my point of view is very interesting the table which defines the weakness by language. I miss the presence of ASP.Net in this list but it can be equated to JSP in most of the cases. In my experience as web pentester I have my own "personal ranking" of insecure web applications. From the most common secure applications to the less one are:

1. ASP.Net
2. JSP
3. Perl/Python
4. ASP
5. PHP

This is not a fact! It's only based on my personal experience in my years of web security testing. I'm open to discuss this ranking ;)

I'm also impressed to see how many of these coding bugs are specifically related to web (or mostly associated with web applications). Web applications are becoming more popular everyday (they are already) and with the rising of the cloud computing they are going to become more and more popular even in the Intranet applications.

Documents like this helps developers to build more secure applications and to application tester to identify and document better these bugs that makes our days :) Enjoy reading!

Testing and virtual machines

Sometimes I need to test specific software version or make a custom machines for a specific propose like developing in a particular language. For now I used my personal machine for it, but today I have discovered something that I'm planning  adapt to my day by day.

I was a bit lazy about creating virtual machines because I need to download a whole CD image, install it and later configure it. Today I discover TurnKey Linux website. They have a lot of virtual machines and ISO images of preconfigured Linux machines. They are based on Ubuntu 8.04 Server LTS so I have a platform I'm familiar with and very cool (and secure!) preconfigured options.

Well, maybe I'm being a bit enthusiastic but the LAMP machine looks really good in my initial tests. I'm planning to give in a try to other machines too like the Ruby On Rails machine or the Revision Control one.

These machines give me the ability to create fresh machines from scratch with a lot of dirty work already done. And I love it :)

If you are looking for more complex machines for testing you can found some preconfigured web security testing machines. They allow you to play with some vulnerable web pages and measure your skills without breaking the law.

• The OWASP is hosting a project called "Broken Web Applications Project" who offers a virtual machine to test different vulnerable software. You can check online the list of vulnerable applications included.
• Recently was released the version 1.0 of Web Security Dojo, which includes vulnerable applications and some web security related tools, as Brup proxy or w3af.

And it is all for today, I have some things to test... ;)

Testing Flex applications (III)

Today, after understanding how Flex applications works and how analyse Flex applications to obtain the list of services and methods, we are going to discuss how to pentest Flex apps to try to generate our fake AMF packets.

deblaze

This tool has some good and bad points in the testing of Flex applications. Being a console tool is very easy to generate automatic scripts with it or add some functionality it doesn't have. Otherwise it only sends basic objects types (int, long, string...) and not more complex ActionScript objects. It's going to be a problem when we are testing large and complex applications.

Test the remote gateway using deblaze is easy. Knowing the name of the service and the method we can get the list of all the players with the following parameters:

python deblaze-0.3.py -u http://digitalshowcase.biz/demos/players/zendamf.php -s Players_service -m read_Players

We can also send parameters to the method using the -p modifier. The parameters need to be separate using the | char. (p.e. -p 1|string|3)

This was a limitation we found in a recent test that we need to solve. Some of the methods we were testing are methods that receive a boolean (true or false) value. As we can modify the code we made a little piece of code to make the trick. We send it to the creator of the tool and he promised us to add it to the next version. But, if you want to use it now, you can use this version of the file: http://www.pastebin.com/f6a1321dd It add the support to send true or false values setting as parameter value the string "true" or "false".

Charles Proxy

It's a commercial tool that decrypt the AMF packets and allow us to modify and reply them to the gateway. As we showed in the previous post it generate a list of valid request that the application make while we are using the Flash interface.

The main feature of this program is the ability to tamper the request to server and modify them on fly. It also allow us to modify more complex object data. As you can see in the screenshot below we can modify the PlayerVO object.

 

It is very useful in large apps with a lot of AMF objects. It also allow us to break the responses before they are passed to the Flash object, so we can change, per example, a "false" response for a "true" one and test the application against this kind of privilege escalation vulnerability.

Pinta

We are introducing Pinta today. It is an Adobe AIR application so the AMF protocol and the packet sending is going to be 100% equal to the Flash application. Again, as with the deblaze tool, we need to know previously the gateway, the services and the methods to recreate the request to the server.

After specify the gateway the tool ask us for the services, methods and parameters. We can specify different parameters for each method to test different injections. We can also send complex object data using the JSON language.

 

In this case, the PlayerVO object send was: 

{"country":"ES","jersey":"77","player_name":"Test","pos":"PG","team_name":"Atlanta Hawks"}

As you can see the possibilities to send, alter and try to bypass the security of a Flex applications are a lot and we need to know them all to use the most appropiate in each pentesting. For the next chapter (and probably last one) we will make some SQL injections into the application using the previous tools.

Testing Flex applications (II)

In the previous post we manage to extract some information from the SWF file and understand the structure of the important part in a Flex application. In this chapter we are going to automatize the process of extraction and analysis.

If you are sharp-eyed you probably saw the "deblaze" name in the past post screenshots. This is the name of the first tools we are going to use today and can be found in the deblaze website. You can also found some great examples about the use of the tool.

The first step to analyze with deblaze a SWF application is execute deblaze with the -f parameter, passing the swf URL.

 

Sometimes deblaze is able to determine the gateway technology but in this case it doesn't work. Also deblaze is falling detecting the Service name. Why? Well, we have, in this case, access to the source code and we can determine that the service name is Players_service:

This is because deblaze is extracting the information from the XML that we see in the last post. In this file is referenced the zendamf service, but the real one is Players_service. If we don't have access to the source code we can make a quick search at the swf bytecode:

Also we can see the name of the methods the players_Service is offering to the users. Each method require some parameters that we can also found reading the bytecode.

This parameters can be simple objects like integers, booleans or strings but also can be more complex data as custom objects. In this case the parameter send with the add_Player method is a PlayerVO object. To analyze this object we have the possibility to analyze (again) the swf code to get the data.

This, of course, can be inferred by the possibility to analyse the living app to generate the add_Player action and catch the request using a local proxy tool. Charles Proxy has the ability to show clear text AMF messages between the server and the application.

As you can see Charles Proxy shows us the name of the service, the method and the parameters that the swf file is sending to the gateway. Using this tool and navigating for the web page we can generate a tree of request that will expose mostly all the request that the application has defined.

This way to analyze the application is less painful but we can also miss some important (or administrative) function that is not accessible for a normal user. We recommend do both for a better understanding of the whole application.

Flex gateways can be requested from outside the swf file and in the next post we will cover how to generate fake request to test the server.

WeFeTe

I'm proud to announce the release of WeFeTe. WeFeTe is a very simple tool to test against common configurations in web frameworks. It can be use as a first approach to detect the programming framework without missing any of the default behaviours that frameworks include in their websites.

This first release try to detect the following frameworks:

• CakePHP
• CodeIgniter
• FUSE
• Kohana
• TYPO3
• Zend
• Zope

It's very buggy and all the suggestions are welcome :) Next versions will have more frameworks and maybe an improve UI. Also expect some posts about funny histories about framework default files and (in)security by default ;)

Testing Flex applications (I)

A few weeks ago we were involved into a Flex application pentesting. We are going to explain in a serie of posts how Flex applications works and how we test them.

Flex applications combined two parts: the client side SWF file and the AMF gateway, and both communicated using the AMF protocol. AMF protocol (ActionScript Message Format) is a binary packet which contains serialized data: service, method and objects. This packet is send to the server gateway, which manage the communication or actions requested by the Flash application.

As the Flash object is store in our machine we can extract all the information and use it to generate our custom request to the server without using the proper Flash application and allowing us to modify the parameters to test them against common injections and trying to extract more information from the error messages.

For the extraction of the information from the swf file we use the swfdump. It extract the bytecode of the file and output a more or less readable code. We are going to use for demo propose the app located at http://digitalshowcase.biz/demos/players/Players.swf. This is a demo application from Adobe.

The first step is extract the code from the application. The swfdump command accepts the -D parameter to extract all the information. We are also going to redirect the output to an external file for later analysis:

 

Sometimes we can see warnings but this has not to be a problem. We will be able to analyse the relevant information anyway. The next step is analyse these txt file to find the gateways it is using with a simple grep query:

 

With this XML we know the URL where we have to send our AMF packets and the destinations (services) which the server offers to the application. Now is time to extract the methods of these services:

The string [staticprotected}Object}:: is the key to identify all the methods that the gatewayis expecting. We also have near it the number of parameters that the application is expecting.

This is our first approach to the Flex security but we will discuss in the next chapter how to request these methods and how to test them using semi-automatic tools.