• LaTeX Malicious PDF Generation

    by  • October 7, 2011 • Uncategorized

    A couple weeks ago I came across a PDF file used in a targeted attack. I didn’t have too much background information, but it appeared to have came from China and was using CVE2011-0611 to do its dirty work. The first thing that caught my eye about this document was how the attackers did a half way decent job of generating it. There was the normal obfuscation one would find in any other file, but there was also the presence of /ObjStm sprinkled throughout the document. Normally this isn’t a big deal, but I know creating valid /ObjStm by hand can be a pain in the ass, so I wanted to know how they did it. 

    Digging around led me to this little beauty. PDFWP showed up a few times in the document and appeared to be the generator used. After visiting the site it seemed to fit the profile – China being the first language with the support of English as second and the use of LaTeX which produces clean documents. What was interesting about this library was that attackers could be potentially using it or modifying it to fit their needs. I thought there is no better way to check something out then to rip it apart, find the underlying technology and build a little working copy to generate my own documents.

    Some notes before diving in - PDFWP uses LaTeX to generate the documents. On the Google Code site I see no mention of “movie15″, the library to embed movies into a document nor do I see any mention of “pdfobjcompresslevel” which is used to define compression on streams (so easy it makes me sick), so whoever generated the document may be using something slightly different, or they just took my approach and spent a few hours reading about LaTeX to produce the file. In any case, LaTeX makes life pretty easy to generate any sort of PDF document and it is scary how well it works. 

    Define .TEX Templates

    My first stab at this generation was to use the conventional JavaScript exploits, but I had some issues with that. LaTeX uses the “” for commands, so when you attempt to throw in some “x90″ or other shellcode bits, it takes a dump on itself. I didn’t bother trying to work around this, but I know it is possible to do so. Below is the template to generate a PDF file with an OpenAction JavaScript action where all objects are compressed:

    documentclass{article} usepackage[pdftex]{insdljs} pdfminorversion=5 pdfobjcompresslevel=3 OpenAction{JS{% app.alert("9b"); }} begin{document} core content in here end{document}

    I tend to get bored quickly so when that didn’t work or became a pain I decided to go back to the root of this whole project, flash exploits. For that I needed some CVE2011-0611 SWF files which were kindly given to me by the exploit Gods. I Googled around online and found a nice little write-up on how to include flash into a PDF using LaTeX. A quick copy, some edits and documentation reading helped me to produce this:

    documentclass[12pt,landscape]{article} usepackage{geometry} pdfminorversion=5 pdfobjcompresslevel=3 geometry{verbose,letterpaper} usepackage{movie15} usepackage{hyperref} begin{document} begin{figure}[h!] includemovie[ autoplay=true ]{550pt}{400pt}{c.swf} end{figure} end{document}

    What you are looking at here is a LaTeX template very similar to the one above, but with the addition of “includemovie” and some parameters that follow. These parameters essentially tell reader to auto play the SWF file labeled “c.swf” (this file is in the current directory when the generation is done). Again, also notice that objects are compressed at the highest level resulting in little top level objects.  

    Blending Time

    In the spoiled blog entry I had talked about existing documents and how I could pack exploits into them using PHP. Unlike the PHP library, LaTeX generated documents using that framed template you see above with a .TEX extension. This made me a bit sad because it was unlikely that I was going to modify any existing PDFs and then I thought of Google and their powerful indexing. Doing a quick search for file type of “.tex” led me to over 500,000 files that could be downloaded and then modified to include the information mentioned above.

    To go one step further, I remembered the hack job of a downloader I wrote called BigHands and that it could automate pulling down files at random based on a passed in file extension. The download method is far from pretty, but hey, it works. What should be used is urlib2 instead of hitting the system to call wget, but in its current state, that is all I need. 

    Testing and Wrap-up

    Both of these files seemed to do what they were supposed to do. The JavaScript ran, but it was nothing complex and far from some sort of working exploit. Like I said, I got bored with the errors and didn’t want to spend too much time working with the JavaScript stuff anyway. The SWF file on the other hand did appear to embed nicely in the document and crashed my reader when running in a sandbox. To get this to a fully working state you would likely need to combine the two templates to have JavaScript handle the heapspray and the flash exploit to trigger the crash. I’ll leave this for someone else to do, but both LaTeX should scare you and this is why:

    Not encrypted CVE2011-0611:

    http://www.virustotal.com/file-scan/report.html?id=50a0678cdc30b872473925e6e2a6e95977a5e8736ffa28cb2069f2cb4ece3372-1318004587

    Encrypted (using peepdf) CVE2011-0611:

    http://www.virustotal.com/file-scan/report.html?id=321244fb27843a53914140ebb4e10304d6b1eb253f0bde850b08484f992c8197-1318005714

    I will let those results speak for themselves, but keep in mind the following:

    • little was done to add any extra obfuscation
    • existing TEX files could easily be modified to include the 2-4 lines of code to create an evil file
    • this was a known flash exploit and has been around for a bit

    About