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 says it will release a patch this week.
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.
Looking at the output, we can immediately make out what this exploit would contain. Like many other exploits in the wild, this document uses the techniques of /JavaScript and /OpenAction to launch its malicious JavaScript. The combination of both of these techniques would make this document suspicious to any researcher.
/JS and /JavaScript indicates that this PDF document contains the JavaScript. /OpenAction indicates the action to be performed automatically when the document is viewed. Let’s take the deeper look at the object structure of the PDF and find out what is interesting.
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 14, as seen above, has the stream link to object 15, which contains the actual compressed JavaScript.
This is the malicious JavaScript that is encoded twice, first with ASCIIHexDecode and then with FlateDecode. These stream filters will indicate to Reader how to decode the streams while opening the document. This combination of stream filters is widely used in exploits to compress the code. We’ll take a look at the JS code a little later in this analysis. In the meantime, let’s move further into the object structure analysis of the PDF.
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.
Network Communications
Once the code is injected into any of these open processes, a connection is made to the domain prettylikeher.com (IP: 72.30.2.43, 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:
Cmd
Shell
Run
Getfile
Putfile
Kill
Process
Reboot
Time
Door
McAfee Coverage for Exploit CVE-2011-2462
McAfee Intrusion Prevention (formerly IntruShield) has released coverage for the exploit under the attack ID 0x402b1a00 HTTP: Adobe Reader and Acrobat U3D Memory Corruption Remote Code Execution. McAfee customers with up-to-date installations are protected against this malware.
Acknowledgments
I would like to thank my colleagues Hardik Shah, Swapnil Pathak, and Amit Malik for analyzing this vulnerability and contributing to this blog.