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.

But what happens if you accidentally commit a password or other sensitive information to a repository? This post explains how to remove this confidential data permanently from the repository by simply overwriting it in old revisions, i.e. without having to remove revisions or create a new repository.

1. Introduction

1.1. Disclaimer

The following actions might lead to data loss. I am not responsible for anything that goes wrong because of my description.

1.2. Requirements

It is absolutely necessary to have root access to the SVN respository. That is not only through the svnadmin command, but full command line access to the files, particularly to the “repos” directory.

If you do not have root access to the repository, you cannot remove any data from the repository! In that case, contact your SVN administrator.

1.3. Example Scenario

For this example, let’s assume you accidentally committed the file config.cfg with a plain text password 123secret a while ago (in revision 12). The repository is currently at revision 25 and you just realized that the password was in there all the time:

# Config file "config.cfg"
username = someone
password = 123secret
...

2. Local machine: Identify the affected revisions in the working copy

2.1. Fix and commit the affected file

The following commands are performed on your local machine within the working copy of the project, i.e. on the client machine.

Before we start tinkering and forging the SVN history and its repository, first fix the affected file and commit a new revision to the repository. In most cases, people are not going to look in old revisions of a config file, so the faster you commit a new version, the less likely it is that someone sees it!

$ cd ~/Dev/yourproject
$ vi config.cfg
# Change password to something else
$ svn commit -m "config update"
...
Transmitting file data .
Committed revision 26.

2.2. Identify the affected file versions locally

In most cases you will probably realize right away that you just committed something confidential to the SVN repository. In this case, you only have to fix one single version of that file and is pretty clear which revision is affected.

In other cases, however, the affected file might be in the repository for many revisions before you realize it. If this is the case, there might be multiple revisions of the file in the repository and each of these versions needs to be fixed. To identify the possibly affected versions of the file, you can peak into the logs:

$ svn log config.cfg
------------------------------------------------------------------------
r22 | someone | 2011-01-25 01:36:12 +0100 (Tue, 25 Jan 2011) | 1 line
 
update xy config
------------------------------------------------------------------------
r12 | someone | 2011-01-05 00:45:19 +0100 (Wed, 05 Jan 2011) | 1 line
 
added connection details to config
------------------------------------------------------------------------
...

In this case, the file has been altered in the two revisions 12 and 22. Both might include the password and are stored in the repository, i.e. both potentially need to be corrected.

2.3. Get MD5 checksums of the affected versions

SVN ensures the integrity of its repository by saving MD5 checksums of all the files and its versions. Since it is now clear which revisions might be affected, you need to get the current checksums of these file versions and calculate checksums for the new corrected (“forged”) versions. In short, you need to do the following for each affected version:

• Retrieve the version and calculate its MD5 checksum
• Make a copy of file, replace the confidential information with “x”s and calculate the MD5 checksum of the new file.
• Remember or copy all the checksums and versions into a file.

In this example, we’ll have to get the checksums for revisions 12 and 22 of the config.cfg-file. The code below only shows what to do for revision 22; revision 12 is analogue:

# Get current checksum of revision 22
$ svn --revision 22 config.cfg
...
At revision 22.
$ md5sum config.cfg
0e28c6c8342649c290400567130f657b  config.cfg
 
# Correct the file and get new checksum
$ cp config.cfg /tmp/config.cfg-22
$ vi /tmp/config.cfg-22
# Overwrite the password with "xxxxxxxxx" (same length as the old password!!)
$ md5sum /tmp/config.cfg-22
459a78e2eae02b28f810f9fdebdc5b52  /tmp/config.cfg-22
 
# Repeat this for revision 12

3. SVN repository: Correct the affected files

In this step, we finally start altering the repository. All the actions are performed on the server machine as root user inside the actual SVN repository directory, so be sure not to confuse it with you local machine.

3.1. Make a repository backup

Creating some sort of backup is crucial, since we are about to change the binary revision files of the Subversion repository. The easiest way to do this is to backup the whole repository folder of your project, e.g. /path/to/svn/repos/yourproject. However, if its total size is too big you can also choose to only backup the files identified in 3.2.

# Make backup of project; Note the "-a" parameter to keep the permissions.
$ mkdir /backups
$ cp -a /path/to/svn/repos/yourproject /backups

3.2. Verify affected versions

After the backup, we need to verify that we really need to change all the versions we identified earlier. To do that, navigate to the “revs” folder inside the repository and grep for the password:

$ cd /path/to/svn/repos/yourproject/db/revs/0
$ grep 123secret *
Binary file 12 matches
Binary file 22 matches

The matching files are the revisions that contain the password, and hence also the files that need to be “corrected”. Note that sometimes not all the versions identified through the “svn log” command appear in this list. That is because when the file is simply moved and not changed or other parts of it were altered, its contents will not be stored in the SVN revision file.

3.3. Replace the password and checksums

Since the SVN revision files are binary, we need a hex editor to edit them. Hence install hexedit, and then simply replace the password and checksums like identified before:

$ apt-get install hexedit
 
$ hexedit 22
# Hex editor opens the file for revision 22
# Replace passwords and checksums
 
# Repeat this for revision 12

Hexedit is not the easiest editor to use. So here is a step-by-step of what you need to do:

• Hit TAB, then CTRL-S to search
• Enter the password 123secret and hit return
• Overwrite the password with xxxxxxxxx (same length!)
• Hit CTRL-S, then “Y” to save
• Repeat 1-4 for each occurance of the password.
• Do the same for the old checksum “0e28c6c8342649c290400567130f657b”, and replace it with the new one “f85abfd8b63fa7ab68abc9364f2d339e”
• Hit CTRL-X to quit
• Repeat this for all affected revisions

That’s the complete magic. If checked out, the revisions 12 and 22 (and of course also their succeeding versions) will show xxxxxxxxx instead of the initially committed password.

4. Test locally

Now test locally if you can switch between revisions and every works without error messages:

$ svn --revision 12 update
...
At revision 12.
$ grep password config.cfg
password = xxxxxxxxx

If you did everything as the tutorial says, you shouldn’t get any errors. If you forgot to replace checksums or you changed something that you weren’t supposed to change in the SVN revision file, you might get an error like below. However, if that happens, you can always go back to your backup and try it again…

$ svn --revision 12 update
svn: Checksum mismatch while reading representation:
   expected:  f85abfd8b63fa7ab68abc9364f2d339e
     actual:  de6f581d115197baebc43c3975b9e396

5. Bash history cleanup

In step 3.2. we typed the plain text password in the bash. As you might know, this leaves traces in the ~/.bash_history file. Delete them by opening the files and then by simply removing the according lines. Make sure that you do not use the search function of VIM, since that has a history on its own. If you do, delete the history of VIM in ~/.viminfo.

$ vi ~/.bash_history
# Remove everything that contains the password
# Do NOT use the search function, but search manually!

As Debian/Ubuntu user, I am spoiled when it comes to update management: apt-get updates most of my software, and apticron notifies me when updates are available. For WordPress however, the packaged versions of Debian/Ubuntu are really old and less adjustable which unfortunately makes a manual installation inevitable. While there are several automated WordPress update mechanisms out there, I couldn’t find a simple notify-on-update tool.

This post introduces the WordPress Update Notifier (WP-UN), a simple script that frequently compares the installed WordPress version with the latest available one. If a new version is available, it sends an e-mail to a given address.

Update

February ’11: I updated the script so that it now uses the WordPress API. If you want, you can still download the old version of WP-UN, but since wordpress.org changed their download mechanisms, it does not work any more.

Requirements

WP-UN is compatible with WordPress 2.5-3.x. It needs a local mail server such as Sendmail or Postfix to deliver the notification e-mail.

Download & Installation

Download the script, save it to your preferred location and make it executable:

$ wget -O /usr/local/bin/wp-un \
          http://blog.philippheckel.com/uploads/2010/01/wp-un
$ chmod +x /usr/local/bin/wp-un

That’s it for the installation. The script can now be called by simply running wp-un.

Download: WP-UN 0.2, February 2011
Old version: WP-UN 0.1, January 2010 (broken!)

Usage

Now you can call the script with the following arguments:

• –test: to test if the notification works, use the –test parameter (optional).
• INSTALL-DIR: the path to your local WordPress installation, for example /var/www/myblog.
• NOTIFY-EMAIL: the e-mail address of the person to notify if a new WordPress version is available.

By default, the script is completely silent so that adding a cronjob doesn’t require output redirections. If, however, the –test option is given, it is more verbose and sends the notification e-mail in any case.

If a new WordPress version is available, the output looks something like this:

$ wp-un --test /var/www/myblog admin@example.com
Checking installed version... WordPress 2.5.1
Checking latest version... WordPress 2.9.1
Update required; Sending notification to admin@example.com... done.

If WordPress is up-to-date, WP-UN would normally not send any notification. If, however, the –test option is enabled, it sends the e-mail no matter what. In this case, the output will look like this:

$ wp-un --test /var/www/myblog admin@example.com
Checking installed version... WordPress 2.9.1
Checking latest version... WordPress 2.9.1
Update not necessary; WordPress is up-to-date.
TEST-flag enabled: sending notfication to admin@example.com... done.

The notification you receive will look like this:

 The WordPress installation on host example.com needs an update:
 
   Installed Version: WordPress 2.5.1
                  at: /var/www/myblog
 
      Latest Version: WordPress 2.9.1
            Download: http://www.wordpress.org/latest.tar.gz

As cronjob

If you want to be notified as soon as a new version comes out, installing a cronjob is a good idea. Simply run crontab -e and add the following line to the file:

0 6 * * * /usr/local/bin/wp-un /var/www/myblog admin@example.com

WP-UN will now run every morning at 6am and notify you if a new WordPress version is out there!

Conclusion

WP-UN is just one of many solutions and it’s only the work of one afternoon. However, it doesn’t need any additional software and keeps it simple. It serves its purpose and keeps my WordPress installation always up-to-date. If you have any suggestions or questions, feel free to comment below.

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