If you haven't yet installed the latest patch apsb10-07 for your Adobe Reader and Acrobat, you should hurry. The exploit is in the wild! In this post I will dissect a PDF document (MD5: 48e0cc8629d492a64a2767949d2ed9bc), indeed found in the wild, that leverages CVE-2010-0188 in order to install a backdoor in your Microsoft Windows system. Fortinet detected this sample as PDF/Adbtiff.A!exploit.CVE20100188. The test environment is Adobe Reader 9.3.0 in Microsoft Windows XP SP3.
The key for cybercriminals to exploit CVE-2010-0188 here is to embed a malicious TIFF image in the PDF document (figure 1.1):
The uncompressed and decoded Tiff image reveals the real attack vector (Figure 1.2): The count value in DotRange.
The vulnerable plugin AcroForm.api (version 9.0.148) use this count value without sufficient sanitization. While the target buffer is a two bytes field on the stack, a memcpy instruction (in purple below) copies the 100 DotRange values (200 bytes) there.
As a matter of course, this effectively smashes the stack and overwrites the return address with the value 0x0C0C0C0C.
This rather nastily obfuscated JS code simply sprays the heap with an encoded shellcode and its matching decoding stub, so that the return value above (0x0C0C0C0C) leads to the stub execution, as shown below:
0C0C0C0C 0C 0C or al, 0C [...] 0C10FB26 90 nop 0C10FB27 EB 1A jmp short 0C10FB43 0C10FB29 5E pop esi 0C10FB2A 56 push esi 0C10FB2B 5B pop ebx 0C10FB2C 8A06 mov al, byte ptr ds:[esi] 0C10FB2E 3C 30 cmp al, 30 0C10FB30 74 16 je short 0C10FB48; jump to decoded shellcode 0C10FB32 C0E0 04 shl al, 4 0C10FB35 46 inc esi 0C10FB36 8A26 mov ah, byte ptr ds:[esi] 0C10FB38 80E4 0F and ah, 0F 0C10FB3B 02C4 add al, ah 0C10FB3D 8803 mov byte ptr ds:[ebx], al 0C10FB3F 43 inc ebx 0C10FB40 46 inc esi 0C10FB41 ^ EB E9 jmp short 0C10FB2C 0C10FB43 E8 E1FFFFFF call 0C10FB29; Decoding following shellcode [...]
Then, the hand is passed to the decoded shellcode, which starts... a decoding loop. This one decrypts a file (simple xor encryption, see figure below) before effectively dropping it as "C:\a.exe" and starting it. The content of a.exe is also stored in the PDF file.
Figure 1.4 shows the code do the decoding, drop and run the "C:\a.exe" (MD5: 779211676c099f81739e4320cbdce983).
Fortinet detects "a.exe" as W32/Emogen.DHLY!tr.dldr.
By the way, the shellcode use a very simple logic to find the PDF file handle (necessary for droping a.exe, which sits encrypted in the PDF file): It considers it is the first file opened in this process and have a size larger than 1000h. This logic may make mistake and lead to a crash.
Finally, "a.exe" does the followingl: 1. Move itself to "C:\Documents and Settings\Current User\Local Settings" and add an entry in the registry under key "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" for running upon reboot. 2.Prepare memory for code injection 3.Start svchost.exe and inject code in the created process
The poisonned "svchost.exe" in turns connect to a fixed IP and receive/execute commands, like a good old backdoor.