PDF analysis of Nuclear Pack EK and CVE-2010-0188/CVE-2010-2883

On Malwarebytes’ blog it’s recently been published a description about Nuclear Pack exploit kit, though there isn’t a description of the PDF exploit used, so we’ve decided to proceed with a more in-depth analysis.

PDF analysis

There are two objects that appear to be suspicious: so let’s start with… object 1:

Object 1 contains an AcroForm (the document’s interactive form dictionary) which points to object 3 having the key XFA, which might indicate a stream, or array, containing an XFA (Adobe XML Forms Architecture) resource.

We have started to debug the pdfwith the embeddedjavascriptdebugger found inAcrobat, we can see that theoeevariable, which is an array of characters, contains [object XFAObject] string:

The javascript code into XFA, that in turn calls the eval(), generates another js code in which there are a function to decode base64 encrypted stream (base64_decode(d)) and another eval() function. To check the output we can simply put the js code into an HTML page and debug it with Firebug:

After executing this layer we finally have the exploit code: this code is exploit CVE-2010-0188 and is the same found by Malware Must Die .

The only thing MalwareMustDie guys didn’t say was that the “ret” value is written in a XFA fieldelement : “A field element is the workhorse of a template and represents a data-entry region” having imageEdittag: “imageEdit widget that allows images (editable) to be supplied as URIs” , through var_1_ var which is the name of this field.

Shellcode analysis

So the exploit works on Adobe Reader 8.0 until Adobe Reader 9.3 version, and it has two shellcode versions: one for 8.0.0 =< version < 8.2.01 and other for version >= 8.2.01. Let’s start withthe first.

The execution flow should be this:

Heap Spray the shellcode

Exploit LibTiff bug

Execute ShellCode

For the second point foot js variable is important, we have created a simple python script to inspect its code:

The code seems to be a ROP (Return Oriented Programming) attack: in fact debugging on Adobe Reader 8 we can see that 0x4a80eba3 is an address of icucnv34.dll, while at 0x4a822038 there’s a pointer to the CreateFileMapping API.

After searching the web for previous analyses, we came up with this post on contagio blog: it’s CVE-2010-2883, for more info about how the shellcode joke in libtiff check the link.

In this way ESP, the stack pointer register, points to a region of memory which starts with f602020 address. In this region there is the content of sc_hex var, that is the shellcode. After that MapViewOfFile API is called to maps in memory the shellcode to be used and executed by memcpy. Now EIP point to EP of shellcode which begin with 0xb083 bytes.