Flash Exploit Goes Wild

As predicted recently, a Flash exploit discovered by Mark Dowd (IBM X-Force) did not keep us waiting for too long until it started popping up in numerous "in-the-wild" web page infections. As per initial SecurityFocus/Symantec assessment, there are from 20,000 to 250,000 web pages currently affected with this exploit.

Let's have a look into the binary contents of an SWF file pulled from one of the infected web sites.

The output provided by swfdump tool (which is part of a toolset SWFTools) suggests that the file has 2 streams in the DefineSceneAndFrameLabelData tags.

The tag DefineSceneAndFrameLabelData is defined by Adobe specification as a record header (type 86) followed by the number of scenes (N), followed with a frame offset and a scene name for all N scenes.

The binary contents of DefineSceneAndFrameLabelData tags is:

[056]        40 SCENEDESCRIPTION
a6 e1 8a a0 08 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 43

[056]        12 SCENEDESCRIPTION
01 00 e5 9c ba e6 99 af 20 31 00 00

where [056] is the tag ID of DefineSceneAndFrameLabelData (86 in decimal), and 40 and 12 are respective sizes of the streams.

According to IBM X-Force research paper, a vulnerable function in Adobe Flash DLL checks the "scene number" value in a "greater than zero" conditional jump. Such comparison assumes that the checked value is signed, thus, a negative "scene number" value will always pass the check for zero.

In order to be "negative", the "scene number" value should have its left-most bit set to 1. Thus, any integer 0x80000000 or greater would pass the check since the value is less than zero.

The "scene number" value is stored by Adobe in EncodedU32 format. SWF file format specification discloses an algorithm of "unpacking" the EncodedU32 value.

By building a tool with the same algorithm, we can check the actual unsigned integer values of "scene numbers" specified in the vulnerable SWF file:

unsigned char buf1[]= "\x01\x00\xe5\x9c\xba\xe6\x99\xaf\x20\x31\x00\x00";
unsigned char buf2[]= "\xa6\xe1\x8a\xa0\x08\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x43";

int iResult1 = GetEncodedU32(buf1);
int iResult2 = GetEncodedU32(buf2);

where GetEncodedU32() function is identical to the one specified by Adobe.

The code above will return iResult=1, and iResult2=0x8402b0a6, thus making iResult2 a "negative" value (with the left-most bit set to 1) that will always bypass "greater than zero" conditional jump regardless of the positive amount of data remaining in the buffer.

This will lead to a failure of a subsequent memory allocation function.

The malformed DefineSceneAndFrameLabelData tag with the negative "scene number" is also accompanied with the malformed DefineBits tag (0x06).

Swfdump tool displays the binary contents of DefineBits stream as shown below:

[006]       336 DEFINEBITS

aa 02 34 d1 f5 25 13 90 00 90 90 90 90 90 20 cc cc cc cc cc cc cc cc cc cc cc cc 90 90 90 90 60 (etc.)

where [006] is the tag ID DefineBits, and 336 is its length.

This tag contains the actual ShellCode that provides the payload for this exploit.

In order to analyse the ShellCode, the entire DefineBits stream (336 bytes) needs to be loaded into the disassembler. For start, it obtains the image base of kernel32.dll:

Then, it parses the export tables of kernel32.dll and urlmon.dll and retrieves RVAs of the exports that match the hard-coded hash values:

As the analysis of the shellcode was static, there was an assumption made that the code would need to dynamically retrieve RVAs for the following APIs: kernel32.dll->LoadLibrary(), kernel32.dll->WinExec(), urlmon.dll->URLDownloadToFile() with the following purpose:

• download an executable from the URL: http://user1.[blocked].net/bak.css
• save it as C:\6123t.exe
• execute it and (optionally) terminate the host process

When run, the downloaded file drops a text file into the newly created directory %Windir%\Nt_File_Temp\

The text file contains a list of URLs that the downloader will again download and execute.

By cross-referencing this behaviour with other threats reported by ThreatExpert automation, and analysing the contents of the downloaded files, it was established that such behaviour is common for the password stealing trojan OnlineGames/GamPass/LegMir, trojan Trojan.Drondog, and a rootkit Rootkit.Order.

In conclusion, here is some food for thought:

According to these, these and these stats, in US alone, among 212,080,135 of its active Internet users, 207,838,532 users have Flash Player installed (98%); among which 187,054,679 users run Microsoft Windows (90%), among which 102,880,073 (55%) users do not run the latest Flash Player.