~ Password Busting ~
         to basic   

v0.02 published at searchlores in March 2003

(¯`·.¸ Password Busting: SWF Protections ¸.·´¯)
- Getting access in a flash -

by Cinix

With contibutions by madhaha, jeff, Mordred, Nemo, and others gathered @ ~S~ Seeker's messageboard


 Contents

 Introduction

In his essay "The Joylock Case" loki suggested to me to write a small essay about the Flash component of the CoffeeCup Password Wizard solution, well here it is. Altough I used CoffeeCup as a Case Study I've tried to make this essay as general as possible. After all we are here to learn some basic password busting skills and not work target specific.

Macromedia Flash movies are graphics and animation for Web sites. They consist primarily of vector graphics, but they can also contain imported bitmap graphics and sounds. Flash movies can incorporate interactivity to permit input from viewers using Flash's scripting language Actionscript. For example, you can write a script that tells Flash to load different Web pages depending on the information provided by a user. e.g. password protection ;)

Of some importance is that the flash format has been revised several times, it has 6 versions (though they don't call the last Flash 6, but Flash MX). An easy way to tell which version is your target is to look at the first four bytes: They should be "FWSx" or "CWSx", where x is the version number (binary, not ascii), and C marks a zlib-compressed SWF (available from Flash 6). In reality, you can meet only versions 4-6 on the wild. Note that because of compression you may not be able to use regular text-scanning utilities.

In conjunction with the decompilers listed below, there are other kinds of tools you may or may not need. SWFs can be embedded in EXE files, or zlib-compressed, or "protected" from import, and tools to deal with these things are widely accessible on the web.

There are plenty of Flash obfuscators out there that will screw, crash Action Script Viewer or Sothink SWFDecompiler with control flow tricks. Since Flasm has a different approach in analysing the SWF file it wont be fooled and will help you in time of destress. This is why you are advised to use flasm along with the decompiler of your choice.


 SWF Password Busting Toolbox

Screwdrivers and multitools - For the regular students

SWF File Format Specifications and other tech info - For those who really want to get into SWF reversing.

Related fora - For those who really want to get the people which already got into SWF reversing.


 HTML Source Analysis

Each SWF file that is embedded in HTML must identify itself as an Flash file in order for a browser to correctly display its content. In theory there are constants involved we can use to try and fish them out, but in reality we will see that it's not that easy. - At least I couldn't get my theory to work but maybe others have better results, don't hesitate to share -

But first the analysis, note that this is the format currently produced by Flash MX and deviations, and other mutant forms exist on the web.

<!-- URL's used in the movie-->
   // We might find here something like a backdoor url,
   // but only if the implementation is really stupid
   // so I wouldn't get my hopes up.
   
<!-- text used in the movie-->
   // Maybe some strings like password, username, ...
   
<OBJECT 
   CLASSID="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"   // Identification -> flash movie
   CODEBASE="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0"   // Flash version
   WIDTH=100% 
   HEIGHT=100%
   >
 
   <PARAM NAME=movie VALUE="password.dud">   // Flash filename can be anything but often ending on .swf 
   <PARAM NAME=menu VALUE=false>
   <PARAM NAME=quality VALUE=medium>
   <PARAM NAME=bgcolor VALUE=#000000>
 
   <EMBED 
      SRC="password.dud"  // Same value as <PARAM NAME=movie> 
      MENU=false          // Same value as <PARAM NAME=menu>
      QUALITY=medium      // Same value as <PARAM NAME=quality>
      BGCOLOR=#000000     // Same value as <PARAM NAME=bgcolor>
      WIDTH=100% 
      HEIGHT=100% 
      TYPE="application/x-shockwave-flash"   // Identification -> flash movie 
      PLUGINSPAGE="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"
      >
      
   </EMBED>
   
</OBJECT>

As we see many - if not all - constants worth looking fore are embedded within the HTML tags and not actually visible, thus for the most part ignored by the SE spiders, bots, indexers... and the results returned for our query will be mostly useless. - by all means, correct me if I'm wrong -

A custom SWF password finder bot/spider could of course take these findings into account and present us a nice database of closed SWF doors.


 Fishing Flash Protected Sites

Nomomen | Guessing Approach: Using selective dynamite Who still uses worms? ;)

Searching for file names is a good starting approach, but one must consider that everything up to ".swf" is possible, even the ".swf" part isn't a constant given as we have seen in the analysis so that is where the guessing part comes in.

In theory, the human mind has no limits on it's imagination but it is often the case that only a handfull individuals will travel and explore the imaginations boundaries. Most people follow the same path when giving names to files: "content - name relation". Most of the times this is a good thing but when it comes to protection you might want to deviate from it,... except if you want to be fished out.

Examples: pass.swf, login2.swf, pwd1.swf, member.swf, members.swf,...

Object Approach

Because an SWF file is an object embedded in a htm/l file - See analysis -, you can specify that all returned results must include this type of object in their page. This is of course only possible on search engines who's features support this type of searches.

Combining it all

As you might have noticed: best results come from combining both techniques. Only searching for filenames like pass.swf will even fish out this page altough there isn't a SWF based login in sight.

Language: Pool:
Bait: Approach:
Variation:


 General Flash Reversing

The technique is actually pretty straight forward and the same for all Flash based protections: analyse the Action Script of the Flash animation ;) It is basically the same as with JavaScript based password protections, but the actual code is hidden inside the Flash animation.

In 97% of the cases a simple text-scan will give you the unencrypted password, username or a backdoor url (actually you only need the backdoors and shouldn't care about all the rest) since most protections have them hardcoded inside the Flash.

In some cases the Flash protections use external files to store their data. If you see something like this in the Action Script tab:

var UserData = this.loadVariables("Users.txt", 0);

All you need to do now is to download the "Users.txt" file and you'll have access:

UserData=user_0,password_0,your.backdoor.url_0
user_1,password_1,your.backdoor.url_1
user_2,password_2,your.backdoor.url_2
user_3,password_3,your.backdoor.url_3
user_4,password_4,your.backdoor.url_4

Since Flash 5 it is actually possible to load an xml file (with user data) in the animation, so keep an eye out for the following commands:

doc = new XML("Users.xml");

or

UserData = new XML();
UserData.load("Users.xml");

Now guess what "Users.xml" contains.

A small remark I received from a guy named Bertrand

Using a "loadMovie", there can be several files around a flash "protection scheme", so it's also wise to watch wich SWF's are requested through -say- privoxy while trying the SWF.


 Case Study
 Flash component of the CoffeeCup Password Wizard solution.

download the Flash file at http://www.coffeecup.com/java-password/samples/sample.swf and open it with the Action Script Viewer. In the Action Script tab you'll get a list of all ActionScripts in the current Flash animation. The one we are looking for is:

on (press) {
    V = new String ("0");
    z = new String ("");
    z = userBox + passBox;    // Add the two strings together.
    if (z == "sampletest") {  // Compare to hardcoded data.
        V = "1";
        getURL ("http://www.coffeecup.com/");
    }
    
    /*
    * New users are added by the CoffeeCup Password Wizard like this:
    * 
    * if (z == "user_0password_0") {
    *     V = "1";
    *     getURL ("http://your.backdoor.url_0", "_top");
    * }
    * 
    * if (z == "user_1password_1") {
    *     V = "1";
    *     getURL ("http://your.backdoor.url_1", "_top");
    * }
    */

    if (V == "0") {
        gotoAndStop (2);
    }
    userBox = "";
    passBox = "";
}

The username is "sample" and password is "test". The backdoor is "http://www.coffeecup.com/".

Due to bad programming we could also use one of the following combinations:

 / sampletest
s / ampletest
sa / mpletest
sam / pletest
samp / letest
sampl / etest
sample / test   // This is the only one that should be allowed.
samplet / est
samplete / st
sampletes / t
sampletest /

 How To Protect Better

Are SWF files usable as a protection method? The real question you should ask yourself is shouldn't my content be shared with everyone instead of hoarding all the knowledge for monitary gain.

SWF is as good (or bad) as every other client side protection method like Javascript, Java Applets, ActiveX plugins to name a few. Each of them are reversable but when you take this fact into account when you design your sites protection scheme you can give a possible seeker for knowledge a hard time.

This way you are forcing a "Brute Force" technique onto everyone attempting to break your protection. Now it 's pretty straight forward to make a Brute force attempt fail miserably.

If you really want a good SWF password protection, You certainly shouldn't pay 30$ for that lame crap.


Cinix
lord_cinix(a7)hotmail(p0in7)com


Petit image

(c) III Millennium: [fravia+], all rights reserved, reversed, reviled and revealed