Client-side exploitation continues to be a popular attack vector. Another zero-day attack has targeted Adobe Acrobat Reader to infiltrate customer networks. The currently unpatched exploit opens the door to code execution when a victim simply reads a malicious PDF document.
This JavaScript code is viewable only if the stream had been unpacked, as can be seen in this FileInsight screenshot:

Although the content of the compressed stream may look like random data, when unpacked the JavaScript code will fill a certain memory area with malicious x86 assembly code and cause the exploited Adobe software to execute this shellcode–commonly know as a heap spray.
To determine the final intent of the shellcode, we have to remove another obfuscation layer that attempts to evade automated detection. The machine code is embedded as a “malformed” and “escaped” sequence of hex bytes. Any occurrence of the substring “XX” is replaced with “%u” before JavaScript can convert the string back into binary, executable code.

After loading it into a disassembler, we can see that the unescaped executable code is stage one of a two-stage attack. The intent of stage one is to identify the open file handle of the malicious PDF to find a particular signature (which is called an egg by exploit writers). This signature (0x0A666F65 in this example) is immediately followed by stage two of the shellcode and is then branched into.

The screenshot below shows the presence of the PDF’s embedded egg, followed by x86 machine code, part of stage 2. The code contains another obfuscation layer, namely a routine that XOR decodes the remaining code and–surprise, surprise–unveils an embedded executable!

The hidden executable, which is visible only in a hex editor after having applied the same XOR decoding, is written to disk and executed by the shellcode–thus highlighting the steps the attacker has taken to evade detection.

McAfee Gateway Anti-Malware detected and blocked this threat proactively (“BehavesLike.PDF.Suspicious” and the embedded executable as “BehavesLike.Win32.Rootkit.H”). McAfee Artemis and the 5766 DATs block it, as well.
<<<<<<<<<< Update Late October, 13, 2009 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Adobe has released a patch that remediates the above issue. Full details available here.
FYI, I’ve updated my PDFiD tool to detect this 0day: http://blog.didierstevens.com/2009/10/13/update-pdfid-version-0-0-9-to-detect-another-adobe-0day/
Can you guys point out how you guys are actually going about decoding this to make it viewable using your tool fileinsight?
Thanks and love the blog very informational!!
Q: what would be the effect of DEP set to ‘optOut’ or ‘alwaysOn’ on the heap spray attempt? (winXP+)
“The hidden executable …is written to disk and executed …”
Q: written where, executed by whom?
If the attacked user is a “normal” user as opposed to an admin is the attack successful?
What happens if a “normal” user is protected by a “line of business” Software Restriction Policy? Write+Execute should result in a security fault, preventing the attack. Is there a privilege escalation step?
DEP, “normal” user and SRP are readily available mitigations/defenses against “drive by” attacks. Testing consistently against them and reporting the results would help to aquaint the non-specialist public with their use. Hopefully some will be encouraged to investigate and apply these measures, making themselves and the rest of the internet just that little bit safer.
Submit your own comments / message for this post