• Analyzing CVE-2011-2462 – Part One

    by  • December 7, 2011 • Uncategorized

    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

    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. 

    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.