So what’s the problem with that, you think? The problem is that almost all Flash applications can be hacked very easily and most developers are not aware of that.

As a reminder of how vulnerable Flash applications are, this post aims to raise awareness for these issues. In a case study, it shows how a Flash-based game and its server side high score can be tricked within a few minutes using free tools only.

Disclaimer

This post is meant to raise awareness for the vulnerabilities of Flash-based applications. It is not a hacking tutorial or how-to. For that reason, I will not describe all steps in great detail, but only sketch the basic steps.

1. Introduction

1.1. The problem with Flash applications

Flash applications are similar to normal Windows/Linux executables: Like normal programs, their source code is compiled to a binary format and later executed on the client machine. The major difference to .exe or Linux binaries is that decompiling is a lot easier: while a C or C++ compiler translates the source code into machine code, i.e. CPU instructions, SWF files contain the ActionScript code in plain text. That is with the right tools, extracting the complete code is a no-brainer!

Combining this with the fact that sniffing into the client-server communication is also not the most difficult task, one can easily simulate the Flash client with own code snippets and scripts, and thereby send forged requests to the server.

1.2. Checksums as a solution?

Most application developers at least know that the client-server communication can be sniffed into. As an attempt to make it more difficult for people to send forged requests to the server, applications mostly use a message authentication code (MAC) or some other checksum-based mechanism. So instead of sending a plain text update query to the server (1), the application creates a hash by concatenating the user input with (to the user unknown) other data (2):

This mechanism is completely based on the fact that the user does not know how the checksum is created. While this approach is very effective in regular applications, it completely fails in Flash programs: disassembling a Windows or Linux binary is very difficult and requires know how in assembler. Decompiling SWF files, however, is fairly easy and can be done in under a minute. That is retrieving the code that generates the checksum is only a matter of seconds.

1.3. Tools and basic approach

The following steps present a generic approach on how any Flash application can be exploited like described above.

Required Tools:

• Firebug: Firefox plugin for basic communication sniffing
• Sothink Flash Decompiler: required to extract ActionScript code (trial version is sufficient)
• Wireshark: required for detailed communication sniffing (byte-for-byte)

Generic Approach:

1. Enable Firebug and start sniffing with Wireshark.
2. Go to the target web site and play the game or use the application.
3. Look at the communication of the Flash application with the server. If there are any parts of the requests that cannot be recreated without the source code, e.g. checksums, download the important SWF files and decompile them.
4. Analyze the ActionScript code and find the part which creates the checksum.
5. Make a script that generates the same request with arbitrary input data, e.g. any score or name. For this script, the checksum algorithm from the ActionScript code can be used (or recreated).

2. Case study: a car parking game (with high score)

Our local newspaper Mannheimer Morgen recently hosted a competition in which users had to park a (virtual) car into different parking spots without damaging the car and with minimal fuel usage. Prizes were a safety training and concert tickets. While in this case the score of the participants did not decide who won (winners were drawn by lot), the winner in other competitions might be the one with the best score. Please note that I did not take part in this competition and I did under no circumstances try to win the prizes.

Parking Game: The target application in this case is a game called “Parking”.

2.1. Capture the client-server communication

Following the instructions from above, the first step is to capture the communication between the Flash client and the server. In this case, we are particularly interested in how to add our name with an arbitrary score to the high score list.

Firebug:
Using Firebug, we can see three interesting requests:

• savescore.swf is the part of the client that is responsible for sending the score to the server.
• serverdate-read.php is called by savescore.swf for no obvious reason – very suspicious. We will later see that the result is used in the checksum generation.
• highscore-write.php is also called by savescore.swf and actually writes the user’s score to the database on the server.

Firebug identifies the interesting files and requests.
In this case, three requests are relevant for the high score forgery.

What is particularly important is the two parameters __ctrl and controlvalue. Both are obviously generated by some checksum function in the savescore.swf-file. So the next step is to decompile the SWF file and look for the checksum-generating function.

Wireshark:
If we additionally enable Wireshark, we can get a plain text (or hex) representation of the HTTP request-response cycle. That is particularly important if one wants to forge a request in a way that it cannot be detected by the server.

2.2. Decompile the SWF file and find the checksum algorithm

Using the SWF Decompiler software (trial version is sufficient), the savescore.swf can be examined very closely. Most of the applications are not very complex and the relevant code pieces are found very easily.

When analyzing savescore.swf, the two parts in which the checksums are created are found at different positions in the file. The __ctrl parameter is generated by taking a MD5 hash over the two concatenated values of score and email. The controlvalue parameter is created in a similar fashion and involves the previously queried serverdate.

The __ctrl parameter is a hash value over two of the variable input parameters.
The controlvalue parameter is created similarly.

2.3. Write a script

Once it is clear how the checksums are generated, the puzzle is solved. The only thing left is to write a script that allows entering arbitrary input values, and using the previously determined checksum-mechanisms to generate a MAC.

Here is a short excerpt of how this could look like (using PHP):

$score = "999.999";
$email = "nobody@example.com";
 
$data = array(
	"__ctrl" => md5($score.$email), 
	...
	"score" => $score,
	"controlvalue" => md5(...), 
	...
);
 
foreach($data as $k=>$v) 
	$data_enc[] = urlencode($k)."=".urlencode($v);
 
$req = "POST /parking/highscore-write.php HTTP/1.1\r\n"
     . "Host: www.morgenweb.de\r\n"
     ...
     . join("&",$data_enc);
 
$fp = fsockopen("www.morgenweb.de", 80);
fwrite($fp, $req);
while ($line = fgets($fp)) { }	
fclose($fp);

3. Conclusion

This blog post introduced a common way to outsmart Flash applications and games. It demonstrated that by sniffing into client-server communication and decompiling SWF files, many Flash applications can be misused. Using the example of a Flash game, the post showed that SWF cannot be compared to Windows/Linux binaries, but must rather be seen as JavaScript-like client code.

Even though this post only demonstrated this using a rather harmless game, more serious misuse is also possible. Flash-based music streaming sites such as Simfy, Spotify Grooveshark are affected as well. They all use a similar mechanism for their Flash-based music player. Using the approach presented above combined with tools like rtmpdump can potentially harm their services significantly.

Flash once was a great way for bringing a little dynamic in the Web 1.0, but is no outdated. With various JavaScript frameworks and HTML5 on the way, Flash is going to retire soon. Developers and companies must be aware of the flaws of Flash and adjust their services accordingly to make sure that they cannot be misused.

This is where a password manager comes in handy: Open the password vault by typing in the master password, put in all you secrets and crucial information, save it and be happy. As if!

Almost every password manager I found on the Web was crowded out by details so that it took minutes to add a single account. What I wanted was something like a text-file with password — and that’s what I made: A simple command-line password safe.

How it works

Simsafe is nothing else but a simple Perl script wrapped around the symmetric encryption functions of GPG. Every box with GPG and Perl installed can hence use the script (= every linux box!). And even if the simsafe-script is not installed on the system, a simple gpg –decrypt FILE shows the plain text contents. That is, Simsafe files are nothing more but text-files with password!

Usage

It’s simple and really easy to use.
Syntax:

$ simsafe FILE

Create a new password safe file

$ simsafe mySafe
simsafe: Creating a new password safe 'mySafe'
simsafe: Please enter the new password: (type in your password)
simsafe: Please confirm the password: (confirm your password)
simsafe: Executing editor vi ...
  // VI or your favourite editor opens
  // and you can edit the plain text file
simsafe: Encrypting with GPG ...

Adding/Removing entries to the password vault

$ simsafe mySafe
simsafe: Please enter the safe password: (type in your password)
simsafe: Decrypting with GPG ...
simsafe: Executing editor vi ...
  // VI or your favourite editor opens
  // and you can edit the plain text file
simsafe: Safe unchanged.

Get it!

It’s a reeeaallly small script and this post is possible longer than the perl-file itself, but here it is. Simply download it, make it executable and put it somewhere in your PATH.

Download: Simsafe v0.1, Apr. 2009

The Kademlia Protocol

Kademlia is based on four simple remote procedure calls (RPCs) and guarantees a very fast and lightweight exchange of information by using the connection-less UDP instead of TCP. Every node as well as every entry of the DHT is tagged with an identifier, called node ID or key. By XORing identifiers, one can calculate the distance between them and is hence able to walk through the network knowing whether one is near or far to a specific node. This so called XOR metric makes it possible to group the entries of the DHT around the K closest nodes to the entry’s key. An entry with the key 10, for instance, will be stored at the nodes with a node ID close to 10.

Kademlia + PKI = KadS: The Secure Extension

In my Bachelor thesis, I am going to extend Kademlia from a simple peer-to-peer protocol to a trusted and secure network. The proposed KadS network is almost identical to the Kademlia network, i.e. it consists of the described RPCs and implements the same XOR metric. The major extension to the protocol is that every node is equipped with a public/private key-pair signed by a trusted CA. This extends the normal Kademlia network to a public key infrastructure (PKI) in which every communication is encrypted, every node can be trusted and only verified nodes can participate in the network.

Every connection is synchronously encrypted with a session key which is created and exchanged in a handshake procedure when two nodes first meet. That is, a node has a different session key for the connection with each node it knows in the network. The handshake is similar to the one used in other software except for the fact that both clients exchange their public key and need to verify each others identity. After a successful handshake, two nodes are able to exchange lightweight encrypted messages using the session key and the basic protocol applies

An application: The distributed URL blacklisting service

As an application to the proposed KadS network, I chose a distributed URL blacklisting service. Please read more in my Bachelor thesis exposé, or simply download the whole thesis:

Blacklisting Malicious Web Sites using a Secure Version of the DHT Protocol Kademlia.