Blog

Introduction

In this issue of "Malcode of the Week," I'm going to analyze an exploit from the recently patched MS06-067 "Direct Animation" vulnerability. I'll demonstrate one tool that I've found extremely useful in turning Unicode-encoded shellcode into bytes, and I’ll step through the analysis of what the exploit is doing and how it's doing it.

The exploit analyzed here has already been posted publicly, so I won’t be revealing any details that have not already been published. The purpose of this post is to give our readers insight on how to analyze this general type of exploit; thus, the information is not necessarily specific to this one vulnerability.

This is the payload of the exploit in %u Unicode-encoded format:

%u9090 = 0x90 0x90 instructions (NOPs)

Unicode encoding is commonly used, but the bytes may be encoded with hexadecimal escape characters as well. %90%90 hex encoding would be equivalent to %u9090.

Because we already have the payload in Unicode-encoded instruction format, our next step is to remove the encoding format (%u), and then turn the shellcode bytes into assembly instructions, so that we can understand the effect of this exploit.

Converting Unicode-Encoded Shellcode to linear byte order

One publicly available tool I like to use is a tool that Dave Zimmer from IDefense wrote called Shellcode 2 EXE

This tool will take as input a number of various byte sequence formats such as Unicode-encoded shellcode, \x style c strings, and raw hex strings.

Once you insert your byte sequence into the text box, you have two choices:

1. Download an exe (don't check the "Bytes Only").  This will place the bytes inside an exe stub.
2. Download a "Bytes Only" file.

This whole process works very well, unless the exploit is dependent on hard-coded addresses inside the exploited vulnerable process.

In this example use of "Shellcode 2 EXE" we will be inserting Unicode-encoded shellcode.

Remember that Unicode-encoded exploits represent the byte codes in little endian format so to translate them back to standard linear byte buffers we have to byteswap the byte pairs such as:

%u54EB = EB 54 jmp = short FIND_KERNEL32_DLL

Which is the instruction found right after the sequence of %9090 (NOP) instructions.

This process is essentially what Shellcode 2 EXE does when it converts the shellcode to bytes.

The next step is to select the option "Bytes Only", this will download a file containing a standard linear byte buffer file representative of the shellcode.

Analysis

After I receive the file, I open up it up in IDA Pro 5 (Note: I open up the file as a binary file):

Manual Conversion of ASCII and code bytes

The first step is to go through the binary file and decide which bytes are ASCII strings and which are code. As I scan through the bytes, when I come across bytes that look like ASCII characters, I select them and press "A" (ASCII), and IDA converts the bytes to look more representative of ASCII form. I do the same for code bytes by selecting the bytes and pressing the key "C" (code). If I make any mistakes, I can always press "U" (Undefine), while the bytes are selected, to convert those bytes back to their original format.

After you manually convert code bytes to code and ASCII bytes to ASCII, the screen should look something like this:

During analysis I constantly rename variables and labels, so that navigation of the payload is easier. I will now begin analysis of the 215byte DirectAnimation exploit.

Find Kernel32 base address and look up exported functions

The payload starts with a NOP sled. A NOP sled is a series of no-operation instructions. The slide finally lands us in code that will calculate the base address of kernel32.

fs:[30h] always points to the PEB structure in memory. Inside this structure is a pointer to the loader data structure, which contains a few different lists of loaded modules. One of the lists is the initialization order module list. Kernel32.dll is always the second module in this list. You'll also notice code to retrieve the base of kernel32 if the OS is Windows 9x.

One method for finding kernel32 exported functions is a method that was written about publicly by a group known as the "Last Stage Delirium" (LSD) in their paper, "Win32 Assembly Components." It was a method that VXers used before exploit writers, but the method gained mass attention when the LSD paper was published.

I urge you to read the paper to get a thorough understanding.

To summarize the hash algorithm: Each function name that is required is pre-calculated by a hashing algorithm. The result is generally a set-byte-size hash representation of the function name. In the payload, when a function is needed, the dll is loaded and its exports are hashed out by name one-by-one until the desired function is matched. This has proven to be the most size-efficient method of retrieving exported functions.

The code below is using a known hashing algorithm that was most likely ripped from the Metasploit framework. The hash algorithm works this way: It takes a function name (string) such as LoadLibraryA, and using a 32-bit accumulator, starting at 0 and increasing by one for each character of the string to be hashed, it RORs the accumulator by 13 bits, then ADDs that value to the character as a 32-bit number. This continues for each character that is to be hashed. The final hash value is the resulting accumulator.

In the screen-shot below, the pre-calculated hash value of LoadLibraryA (0x0XC0E4E8E) is passed to the look-up function by a hash function that will return the exported function.

URLmon.dll is also loaded using the same technique. It's interesting to see the method that is used to calculate the offset for the string "urlmon.dll" inside the payload (more detailed comments on that are included below).

The parameters to URLDownloadToFileA are pushed to the stack. A trick is employed to use the current offset to calculate the offset to the file name (C:\U.exe).

The call instruction is leveraged to push the URL to the stack for the subsequent call to URLDownloadToFile.

Download and execute file

URLDownloadToFile is called, and then WinExec is called to execute that file.

The current process is terminated.

Conclusion

As I stated in my introduction, the point of this post was to show how to explore and analyze a web exploit. Once we convert the Unicode-encode shellcode and insert it into a disassembler, it's easy to follow the instructions.

Although we saw a few tricks to calculate the offsets, the same tricks are used over and over in different exploits, so, they are easy to recognize once you become familiar with them.

Researcher: Stephan Chenette, Websense Security Labs