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
Object Execution Flow
- Object 11 – Definition of 3D data and how it should be formatted
- 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 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
- 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 (firstname.lastname@example.org) /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
This file has a fairly high detection rate according to VirusTotal.
Also, dropped shortly thereafter is a .TMP file which appears to be a DLL..
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:
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.