Sophisticated, targeted malicious PDF documents exploiting CVE-2009-4324
Last Updated: 2010-01-04 06:29:59 UTC
by Bojan Zdrnja (Version: 1)
Couple of days ago one of our readers, Ric, submitted a suspicious PDF document to us. As you know, malicious PDF documents are not rare these days, especially when the exploit for a yet unpatched vulnerability is wide spread.
The exploit for this vulnerability is similar to most other exploits: it uses heap spraying in order to redirect the execution to shellcode. The NOP sled in this case actually consists of SBB AL,0x1C and SBB AL,0x0C instructions which do nothing (SBB is Subtract with borrow, from the register AL, so it keeps subtracting two values until it reaches the shellcode). The 38 bytes shellcode can be seen below:
Now comes the interesting part. This is an egg-hunting shellcode: it starts at the memory address ((0x02020200 OR 0xFF) + 0x01) = 0x02020300) and compares content of every 4 bytes with 0x58905090. You can see that initially the attacker moves 0x5890508F into the EAX register, which then gets increased by one – this was probably done to evade detection.
This pattern (0x58905090) corresponds to instructions POP EAX, NOP, PUSH EAX, NOP. Now, once this pattern has been identified in memory, the egg-hunting shellcode passes execution to this, second stage shellcode.
What is interesting about this approach is that the second stage shellcode is included as a different object in the PDF document. While the object is marked as a color object and its contents are inflated, it looks as if it is corrupted: it does not contain any inflated streams. You can see the object and the deflation error printed by pdf-parser, an excellent tool by Didier Stevens whom I wish to thank for useful discussion while I was analyzing this malicious PDF document:
$ pdf-parser.py --object 3 --raw --filter Requset.pdf
obj 3 0
<</BitsPerComponent 8/ColorSpace/DeviceRGB/Filter/FlateDecode/Height 90/Length 13136/Subtype/Image/Width 60>>
FlateDecode decompress failed
The fact that the decompression fails does not matter – Adobe Reader will open the whole document (mmap it) into memory, including this "corrupted" object so the first stage shellcode will be able to find it and pass execution to it!
The second stage shellcode does something interesting as well. It parses the document name from the command line arguments and opens the PDF document directly. The reason for this is that the PDF document carries two embedded binaries! The first binary (SUCHOST.EXE, b0eeca383a7477ee689ec807b775ebbb) contains a PoisonIvy client which tries to connect to the host cecon.flower-show.org which was down when I analyzed the document. Luckily, this binary has a bit better (but still not good, some major AV vendors missing it!) detection on VT (here). This binary is embedded in the PDF document – we can see it at offset 0x0e65c:
$ hexdump -C -v ../Requset.pdf |less
00000000 25 50 44 46 2d 31 2e 36 0d 25 e2 e3 cf d3 0d 0a |%PDF-1.6.%......|
00000010 32 34 20 30 20 6f 62 6a 0d 3c 3c 2f 4c 69 6e 65 |24 0 obj.<</Line|
00000020 61 72 69 7a 65 64 20 31 2f 4c 20 39 34 37 32 33 |arized 1/L 94723|
00000030 32 2f 4f 20 32 36 2f 45 20 31 37 38 31 2f 4e 20 |2/O 26/E 1781/N |
0000e650 b4 b4 b3 88 8f a0 a0 c0 ca c3 88 8f c8 df 00 00 |................|
0000e660 84 00 00 00 87 00 00 00 7a 7a 00 00 c5 00 00 00 |........zz......|
0000e670 00 00 00 00 c5 00 00 00 00 84 00 00 8b 9a 31 8c |..............1.|
The binary is XORed with value of 0x85 so the first two highlighted bytes are actually MZ, which is where the executable starts.
The second binary (temp.exe, 980e40cacbc9f898bc08cb453fa2d6bb) was even more surprising. This binary drops a benign PDF document on the machine, called baby.pdf. This PDF document is then opened with Adobe Reader – it just shows a table and, according to the metadata in the document, has been built from an Excel document. This was done by the attackers to make the victim believe as if nothing happened, because the original exploit will crash Adobe Reader and this might make the victim suspicious about what happened.
Additionally, the PDF document contains everything it needs to fully exploit the victim's machine – it does not have to download anything off the net.
Not only was this a very interesting example of a malicious PDF document carrying a sophisticated "war head", but it also showed the length attackers are willing to go to in order to make their malware as hard to detect as possible, not only for the AV vendors, but also for victims.
If we are to judge the new year by sophistication the attackers started using, it does not look too good.
Jan 5th 2010
1 decade ago
Patrick W. Barnes
Jan 5th 2010
1 decade ago