9b+

Before I went to bed last night I took a look at uploaded files to PDF X-RAY in hopes that Christmas would come early (CVE-2011-2462 in my reports) and was surprised when I came across a file with /U3D references. I snatched the file off the server, opened up my snapshots to the latest 9.4 build of Adobe and ran the file. Reader crashed, and a new document was succesfully opened. That was enough to stay up, so analysis started and can be found below. 

Bug Sample Viewing

https://www.pdfxray.com/interact/517fe6ba9417e6c8b4d0a0b3b9c4c9a9/

Object Execution Flow

1. Object 4 - OpenAction fires reference to JavaScript
2. Object 14 - JavaScript reference to object 15
3. Object 15 - JavaScript code does heap spray and then directs to page "2"
4. Object 11 - Definition of 3D data and how it should be formatted
5. Object 10 - 3D data that is to be rendered (likely the corruption)

Objects of Interest

• Object 10 - References to named dictionaries - /3D, /U3D
• Object 11 - References to named dictionaries - /3DI, /3DD, /3D, /3DA
• Object 15 - Contains JavaScript routine for heap spray and page redirection (triggers render)
• Object 16 - Fails to decode properly, but not referenced (clean file dropped on successful exploitation)

Understanding the U3D Components

Within object 11 is the definition of how the U3D content should be displayed within the PDF. Understanding of the named dictionaries is helpful when trying to isolate the bug being exploited. Below is a listing of named dictionaries used and a short definition:

• U3D - currently the only supported subtype and 3D object
• 3DD - (required) - specifies the stream or dictionary with the 3D data that is to be rendered
• 3DA - (optional) - activation dictionary defining the times of when the 3D data should be shown
• 3DI - (optional) - boolean value that defines the primary use. true defines an interactive use and false defines interaction through JavaScript
• DIS - (optional) - name specifying the state of the 3D data upon deactivation (i is used for instantiated) 
• A - name under which the annotation should be activated
• PO - annotation should activate as soon as page containing the annotation to the 3D data is opened

Details worth pointing out

Within some of the metadata, the following was found:

<< /email (fo@gmail.com) /Author (Fo) /web (fo.googlepages.com) >>

Googlepages appears to since moved to Google Sites, so this page is no longer active. 

Object 10 Hash - 773793a36f0ba12e6e48f8483b845500 and content download

Breaking apart the JavaScript

Like most JavaScript observed in other malicious files, checks are done for the proper version number before the main routines are executed. What is interesting about this document is that it checks for versions that do not exist and makes a point to redirect the user to an infinite loop assuming they are running a version great than 10. 

Assuming the version requirements are correct, the main heap spray function is invoked. The final call to “zzzzzzzzzzzz()” appears to be the main spray routine and setup. After the spray is complete, another spray follows with generic padding and then some Adobe specific calls. What is interesting to note are the calls that follow. 

A call is made to check whether or not the platform is a Windows machine and then Reader is told to move to page 2. I believe this portion of the code is the trigger for the rendering of the 3D data. Page 2 contains references to the annotations and content of object 11 which defines the 3D data to display (object 10). Without this, I am not certain the vulnerability would be triggered and is likely called manually to ensure enough time was given to spray into memory.

Running the PDF

Using Adobe Reader 9.4.6, the PDF was executed resulting in a crash and opening of a new document. This new document is a survey geared towards defense contractor ManTech. 

The first file to be dropped is "ctfmon.exe" which is later "pretty.exe" after several registry changes.

This file has a fairly high detection rate according to VirusTotal.

http://www.virustotal.com/file-scan/report.html?id=b9231471a9af849ccf3690ebc12cdc7ac4d942f6e417ba7261e7a4414bf1e329-1323275615

Also, dropped shortly thereafter is a .TMP file which appears to be a DLL..

http://www.virustotal.com/file-scan/report.html?id=21d58245c495b9ed4234577fa3fb43cd4c703f38a9b5ce83aa490613168a735f-1323275543

Callbacks are not made initially unless certain processes are opened (http://www.securelist.com/en/blog/2335/Sykipot_exploits_an_Adobe_Flash_Zero_Day). I rolled back my snapshot, executed Internet Explorer and then the PDF file. After waiting, code could be seen injecting into Internet Explorer. A PCAP dump of the traffic shows a call out to hXXps://www.prettylikeher.com (note the SSL). Running strings against the running process reveals the following request that would likely be made through the connection:

hXXps://www.prettylikeher.com/asp/kys_allow_get.asp?name=getkys.kys

This file appears to be encrypted in some form, but used within pretty.exe later on. Visiting the site directly shows a automobile site based out of Raliegh, NC. More analysis needs to be done on the dropped binary. These results will be posted soon.