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.

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.