Analysis of a CVE-2013-3906 Exploit

Based on this data, we can assume that the exploit is used to control register EAX and hijack the function OGL!GdipCreatePath (the comments in the Metasploit module more-or-less confirm this).

According to Microsoft, Office 2010 on Windows XP SP3 is vulnerable to this security issue, so we can use that configuration for our analysis environment to trigger the exploit, and we can make changes along the way if we find that the exploit requires a different configuration for the payload to run. Running the Exploit To investigate the exploit’s execution, we run Microsoft Word 2010 in a debugger on Windows XP SP3 and set a breakpoint on the CALL DWORD PTR DS: line in the OGL!GdipCreatePath function that was shown in the crash snippet above. Once the breakpoint is set, we open the malicious document in the running Word process and we see that our breakpoint gets hit:

However, we can see in OllyDbg’s hint pane that points to OGL.44024C6E, an address in Microsoft Office’s OGL.DLL module. This surely isn’t the result of a hijacked EAX value, and if we have the debugger continue execution of the process, we see that the breakpoint gets hit again with the same value for EAX(0x440583A8); this will actually be the value of EAX for many breakpoint hits at this address. We’re only interested in the case where EAX is hijacked by the exploit to point somewhere interesting, so we can replace our current breakpoint with a conditional breakpoint:

With our conditional breakpoint now set, we can continue execution of the process, during which we’ll break at the following point:

We can see above that now points to an address in msvcrt.dll. Below, we can see that the instruction at that address in msvcrt.dll acts as a stack pivot, setting the stack pointer to the value of EAX (0x200F06B0).

The result of the stack pivot can be seen in OllyDbg’s stack pane below, with the RETN instruction returning to 0x77C34FBF (the address on the top of the stack):

As can be seen below, the instruction at 0x77C34FBF POPs the stack value after 0x77C34FBF

into ESP, causing the stack pointer to point to 0x52537A6E, which is an invalid (unmapped) address:

If we were to continue execution, the Word process would crash, leaving the rest of the payload unexecuted. Based on these results, it is apparent that either the exploit is broken, or it is meant for a different environment than our test environment. In either case, we’d still like to know the intent of the payload, so we need to take a closer look at the memory region containing the pivoted stack:

As can be seen above, this heap memory region contains a 0x700-byte “header”, followed by a spray of 0x400 bytes (highlighted in gray), repeating 512 times. We can actually see this heap spray (of size 0x00081000 bytes) repeated throughout several heap memory regions:

This heap spray is a result of all of the activeX*.bin files embedded in the Word document, each of which contains the 512 occurrences of the 0x400-byte ROP-chain block highlighted above:

The stack pivot that occurred during our testing above resulted in a new stack pointer of 0x200F06B0. However, this value is 0x3B0 bytes into one of the repeated ROP-chain blocks (0x50 bytes before the beginning of the next ROP-chain block). Common sense would suggest that the ROP-chain execution was meant to begin at the beginning of the ROP-chain block, not 0x3B0 bytes into it.

We can test this hypothesis by running the exploit back through OllyDbg, and this time changing the value of ESP before executing the RETN instruction after the stack pivot to point to the beginning of the next ROP-chain block:

Note that we use 0x200F0704 instead of 0x200F0700, since 0x200F0700 points to the stack pivot instruction that was just executed.

Now when we step through the ROP-chain, we see the following instructions executed:

The hard-coded addresses in the ROP-chain target msvcrt.dll version 7.0.2600.5512 (specific to Windows XP SP3), and while the ROP-chain is similar to public ROP-chains, it contains a few different ROP-gadgets, perhaps to subvert security software that would otherwise detect the publicly documented ROP-chains.

The shellcode at 0x200F0768 begins with a loop to XOR the obfuscated shellcode, followed by a Metasploit-based payload:

The shellcode above runs the program “rundll32” as a suspended process, injects code into that process, and creates a new thread in that process to run the injected code. The injected code is as follows, based on the reverse_tcp module and the shell module from Metasploit:

This injected code creates a reverse shell to a hard-coded remote IP address ( above) on TCP port 443. Summary The adversary appears to have used three Metasploit modules to piece together this malicious Word document. We discussed problems with typical antivirus software, in particular the limited information that such software provides to the user regarding detected threats. We described different approaches that can be used to analyze the payload of a file containing an exploit. And we did a deep dive on the dynamic analysis approach, during which we manually fixed the exploit so that we could decode and analyze the payload’s functionality.

With the adversary’s IP address discovered, CrowdStrike was able to notify our customers to help them better defend their networks. We were able to provide them with actionable intelligence that would not have been available to them with traditional security software.