Hacking in Flash. Part one

A lot of software companies develop Flash based applications w/ serious security issues.

This part will review hacking methods for server-side scripts, while the second will delve into socket methods.

Tools you need:
1. Data transfer sniffer.
This will help you discover the protocol used by communication. Browser sniffer (IE, FF), network sniffer, whatever works. I recommend to search one that will describe data structures used. Usually for GET and simple POST transfers you can manage w/o, but for AMF, it's better you have one.
2. Decompiler
This will allow you to see the AS code used by the original Flash component of the application. This will also help you get the protocol. In the course of hacking, you will replace the original Flash with your own or you can use them both side by side.

Hack 1: Get an account in the system
Vulnerability: Weak security model on the server.
Method: apply brute force to discover passwords. This can be used to simple HTML forms too (PHP, ASP, Perl, it doesn't matter).

You'll need some dictionary files for this and possibly a names file. This files usually store one value per line. Just search for some on the Internet. Then you need to find the data structure. For HTML forms, just read the HTML source code, use the decompiler for SWF files. Make an algorithm to cycle through names and passwords. Check the auth failure response and implement a test that will take notice of successful attempts. Show the right values in a textfield or use some other method to store them.
If you have a lot of time, make an algorithm that will compose passwords from ground up. 1, 2, 3, 4 letter combinations will run pretty quick, depending on your connection. For 5, 6 letters and more, expect to wait serveral hours, days, and so on :) Basic optimisation: first make only lower letters combinations. Then capital. Then numbers. Then lower and capital. Then lower and numbers. You get the idea.

Protection against hack: Simple. Just block the account for that IP, class or everything for 10 minutes after detection of 3 auth failures. This will make even 3 letter passwords very hard to catch. If you detect more than 3 auth in 3 seconds or more than 60 per hour, then block that IP for 1 month. Good job, mr. Programmer :)


Hack 2: Access data beyond your rightful area in apps where you already have an account. Trick timed tests. Forge scores in games.
Vulnerability: Weak security model on the server.
Method: determine the Flash part to deliver false data.
Step1. Because you need to be authenticated when you're making calls to the server, just authenticate w/ the original app and open a new tab in browser. Auth sessions are browser based and not tab/window based, therefore you can run operations from another tab and the server will see you as authenticated.
Step2. Send the fake data. For GET and simple POST you don't even need Flash. Now you can take 15 minutes tests in any time period you want, you can send scores to your liking. If the server delivers information by id, just use other ids than the ones offered to your account until you find what you need.

Protection against hack: Don't believe everything the client (Flash) says. If it's about time, make your own verifications. If it requests a resource, verify the client's right to that one.


I know systems where the client is requested to deliver user id, company id and such at each call. How stupid is that?

There are other methods of breaking into Flash apps, but those are not involving Flash directly so I won't go into them. Next we'll discuss hacking on Flash using sockets.