The exploit

Used environment: Windows XP SP3 with Adobe Acrobat 9.4.6

This U3D memory corruption vulnerability (CVE-2011-2462) could cause an application crash and potentially allow an attacker to take control of the affected system. After the malicious PDF file is opened, new process pretty.exe (this file is changed all the times.) is created. We can see this information from the process explorer:

 

 

After setting a breakpoint at function “CreateProcessA” in our favorite debugger, we break into the shell code. Below we can see the CreateProcessA function stack:

 

 

From the screenshot above we found the stack pointer is changed to the address after the heap spray attack execution. This call is not located at the heap spray attack generated dump area, so we can conclude this code segment must be copied from some place around 0x0c0c0c0c. So it will not work properly when we set break point onto the shell code directly. Here is the evidence:

 

 

After heap spray attack is run, we set a memory access breakpoint at 0x0c060000 and then we will break into the memory in drvdx9.dll:

 

 

The value of ESI is 0x0c0c0c0c. After a few steps, the code will be executed to this point:

 

 

The value of EAX seems to be a member of certain structure of Adobe U3D engine; the offset is 0×34. At this moment EAX value is equal to a part of the malicious shell code, so it seems this structure is the target of the attack. Let’s have a look at memory of this structure:

 

 

Our guess is that this memory is supposed to be filled by the Adobe’s U3D parse engine, the source of the memory content must be from U3D object, but now it is filled with shell code. Tracing the code Adobe takes us here, calling the function “icucnv36.4A806CEF”.

 

 

When we trace back a bit we can found the following call flow:

rt3d.2650F1EE (render) ->rt3d.2651373A->rt3d.26512AEE->rt3d.265136B0->drvdx9.26d0d020

When the render function is called, exploit is triggered. The value of EAX is 0x0c0c0c0c as mentioned above; the first instruction is exchanged with the value of ESP afterwards.

 

 

It seems that the shell code authors used the constructed stack to jump anywhere they want and call any function they want. Also they used the ret instruction to locate the Adobe’s execution code, so it seems the attacker may have a strong knowledge of Adobe Acrobat code.

At the screenshot below there is a simple example: A ret instruction is used to find a pop instruction at the end of function in Adobe code. From the screenshot above, we know some stack address is filled with the address of 0x4A806F29. After a bit of tracing we can see the code at this address:

 

 

The following steps are used to implement shell code function calls (for example “CreateFileMapping” API function here):

  1. Hardcode the address of the pointer of function “CreateFileMapping” to the stack
  2. Use ret to jump to the code:  “pop eax,ret”
  3. Jump to the code: “jmp     dword ptr [eax]”

The parameters are already pushed at the stack. Shell code authors used “CreateFileMappingA“ and “MapViewOfFile” API functions to allocate a memory space, and then used “memcpy” API to copy the shell code to the destination memory and execute it. These three steps show the real progress. In the next part we will have a look at the real payload of the shell code.

Step1:

 

 

Step2:

 

 

Step3:

 

 

Shell code execution

The following screenshot shows the initial code segments of the shell code.  They are used to check the top of the stack whether is above 0x0c0c0000.

 

 

EAX register is used to calculate the address of the shell code decoder. As we can see it is decrypted using simple XOR method with the 0×97 key:

 

 

Next the shell code is executed (jmp eax). The interesting thing here is how the handle of malicious PDF is obtained. The file handle value is increased from 0 by 4, and then the value is passed to the function “getfilesize” function to check if the file has the same size of the malicious PDF.

 

 

Then the shell code locates the malicious file embedded in PDF using “setfilepointer” function – offset 2153 in our case – it corresponds to a stream of the Object 16 in our malicious PDF document.

 

 

Next part of the shell code is XOR-decoded using the key 0×12:

 

 

These two parts of the payload are decoded and combined from two different areas of the PDF document. Finally the file ctfmon.exe is dropped to the Windows TEMP folder and executed.

This exploit variant is detected by the latest AVG virus base as Script/PDF Exploit variants.

The malicious payload is detected as Trojan horse BackDoor.Outbreak variants.

 

Frank Zheng & Jiri Kropac