today I'm going to analyze an infected PDF which allows Acrobat exploitation :)
The file target is called soreheadprattler.pdf
At moment when I'm writing, referring to Virustotal, PDF is detected by 29.27% of AV ( 12/41 ), to be honest, very low rate to the potential of the exploit in question. This PDF, using the Sophos nomenclatur, is identified as Troj/PDFJs-LJ
Let's go to analyze the PDF.
First of all I take this opportunity to thank my friend Daniel for giving me the opportunity to act as tester, being still under development. Thx =)
The tool in question is PDF Insider, for more info visit ntcore.com.
Opening the PDF file in PDF Insider we immediately notice a malformation.
We warned of an unresolved xref. The xref keyword ( Cross-reference ) in PDF format are used to search the objects, in fact for this problem we have no object apparently, but this is not a problem because PDF Insider provides us special functions for finding objects to solve these mishaps ;).
In fact clicking on Detect Object we get 4 objects: 1.0, 2.0, 3.0 and 4.0.
Here a screenshot:
Each object may contain the JS code and / or compressed Stream. Of course in our case being merely 4 would not be a problem to go through each object and check for interesting content, but if it was a pdf with many object was a real suicide, unless you are masochistic :P.
But let's go to see what's interesting inside it:
We note immediately between the Info, interesting Filters:
- LZWDecode: This indicats that data are compressed, as I said before. LZW ( Lempel-Ziv-Welsh ) is more used as a data compression algorithm in PDF;
- ASCII85Decode: Other encryption algorithm, also known as Base85 encoding used for communication protocols;
- ASCIIHexDecode: Decodes data encoded in an ASCII hexadecimal
representation, reproducing the original binary data;
- RLE: The RLE ( Run Length Decode ) decompresses data encoded using a byte-oriented run-length encoding algorithm, reproducing the original text or binary data.
Now that we have this info we can also do proper analysis of 4.0 Object. PDF Insider supports LZW algorithm and thus is able to decompress it easily to show the contents of the Stream:
What is immediately evident is the declaration of a variable, specifically named B0b. Skip to the eye because it contains a very long string. But scrolldown to see how this variable is used!
As I thought! It is used in a function that operates a character replacement. It's easy to see that there are many "@" and indeed this character will be replaced by another. Better explain the whole, below the rest of the code:
First are declared some variables. At z variable is assigned the value app.doc which is then chained to complete the function with syncAnnotScan().
Immediatly below B0b varaible is worked. BOb.replace (/ @ / g, String.fromCharCode (32-1 +6) makes a global research (-> /g) throughout the data block to find "@" char and then replace it by the function String.fromCharCode () with the symbol related to hex code 37 (32-1 +6 == 37) that corresponds to the symbol "%". Well, we obtein a new data block:
Before I mentioned app.doc and syncAnnotScan so now I report the explanation from Adobe documentation:
- app: The app object is a static object that represents the Acrobat application itself. It offers a
number of Acrobat-specific functions in addition to a variety of utility routines and
- doc: The doc object is the primary interface to the PDF document, and it can be used to access
and manipulate its content. The doc object provides the interfaces between a PDF
- syncAnnotScan: The syncAnnotScan method guarantees that all annotations in the documents are scanned.
Once we've done all, we find the classic eval () function and inside the unescape() function.
Bye, see you in the next post. =)