Recently a critical vulnerability has been identified in Adobe Reader X and Adobe Acrobat X Versions 10.1.1 and earlier for Windows and Mac OS, Reader 9.4.6 and Reader 9.x Versions for Unix. This zero-day vulnerability (CVE-2011-2462) could allow an attacker to execute arbitrary code and silently take the control of a victim’s machine. This flaw is currently being exploited in the wild. Adobe released a patch on December 12.
McAfee researchers analyzed the exploit (the sample circulating in the wild) and figured out how the vulnerability is exploited and identified the malicious binary, which allows an attacker to take the control of the system.
Using the MD5 algorithm we found a hash value of b025b06549caae5a7c1d23ac1d014892. The technique used in this exploit has been known to researchers for ages.
Here’s what we found as output when we ran the PDFiD tool against this exploit.
Object Analysis of the PDF document
Object 1 contains the author, email, and the web–a kind of meta information.
Object 4 has an /OpenAction reference to object 14, which seems particularly interesting. Let’s take a look at what is in the referenced object.
Object 11 contains the stream link to Object 10, as seen below. This stream link contains the Flate-encoded 3D Annotations data that is to be Flate decoded and displayed while the Reader document is rendered.
According to the Adobe 3D Annotations documentations available here, 3DD entry of the Annotations data specifies the Flate-encoded data stream containing the U3D data. That’s exactly what we see in Object 10, as shown below.
This U3D data is likely to cause memory corruption and trigger the vulnerability. Object 16 is of special interest to us. Let’s see how this object looks.
This object does not have any references and contains the stream that is supposed to be Flate encoded. This stream contains the malicious XORed executable that is dropped after successful exploitation. Let’s see if we can figure out the XOR key.
The executable is XORed by 0×12. Looks like this stream wasn’t Flate encoded but rather simply XORed to embed the malicious file within. This technique is normally used in exploits to hide the malicious code and bypass AV detections.
Let’s take a look at the decoded JS code from Object 15 to understand what it does.
This code checks for supposedly nonexistent versions of Reader and apparently enters an infinite loop if the version comes out to be greater than 10.0. The code appears to use a heap-spray technique to exploit this vulnerability and execute the shellcode. The end of this code checks for the Windows platform and sets the document to page 2 if it is running on Windows and will render the 3D data specified by the U3D file–causing the corruption.
The heap-spray function in the JS code looks like this:
The last function call in the preceding figure allocates the memory and fills up the heap as seen below:
Launching this exploit on Windows with Reader 9.4.6 installed will crash and open the new document “2012 Federal Employee Pay Calender.pdf.”
It spawns the new process pretty.exe and finally injects WSE4EF1.TMP into the iexplore.exe process, which connects to the control server.
Looking at pretty.exe, we see that it looks for outlook.exe, iexplore.exe, and firefox.exe. It then injects the code into whichever process it finds open on the victim’s machine.
Once the code is injected into any of these open processes, a connection is made to the domain prettylikeher.com (IP: 18.104.22.168, which was resolved at execution) on port 443. Assuming that it must be using SSL for control, we hooked the WinInet.SecureSend and WinInet.SecureReceive APIs to check what was sent as the encrypted request. We found the following clear-text decrypted traffic:
The server responded with HTTP 301. The location header had the HTTP link.
Next the HTTP GET request initiated as shown below. The URI query string contains the hostname of the victim’s machine appended with the IP address. The SSL and HTTP requests turned out to be the same.
Analysis of the Injected DLL WSE4EF1.TMP
Looking at the injected DLL, the following code forms the HTTP GET request along with the URI query parameters:
This DLL also seems be virtual-machine aware. While analyzing the code, we came across the VM check that is performed via the SIDT instruction.
SIDT FWORD PTR SS:[EBP-8]
EAX, DWORD PTR SS:[EBP-6]
CMP EAX, 8003F400
JBE SHORT WSE4EF1.10001C88
CMP EAX, 80047400
JNB SHORT WSE4EF1.10001C88
Further analysis of the control code of the DLL reveals that the following commands can be run on the victim’s system:
McAfee Coverage for Exploit CVE-2011-2462
McAfee Intrusion Prevention (formerly IntruShield) has released coverage for the exploit under the attack ID 0?402b3800–BOT: Backdoor EMN Detected. McAfee customers with up-to-date installations are protected against this malware.
I would like to thank my colleagues Hardik Shah, Swapnil Pathak, and Amit Malik for analyzing this vulnerability and contributing to this blog.
Leave a reply