Last weekend, we warned our customers about a Zero-day exploit targeting Adobe Flash and Reader in the wild. The corresponding BID can be seen here. We have updated our antivirus definitions in order to detect this new threat as Trojan.Pidief.J, and we have done an analysis of this new exploit to understand how it works.
At first glance, the PDF document looks suspicious: it contains a Javascript object and a Flash application. The Javascript is clearly malicious, and has the typical form of heap-spraying code:
Image 1: Malicious Javascript code attempting to run heap spraying
Image 2: A suspicious Flash object contained in the PDF document
Opening the PDF document with Adobe Reader causes the application to crash, which confirms our initial suspicion. A document used for an exploit should not crash, it should transfer control to the exploit code and run malicious actions from there. In this case, I am probably using a different version of the software for which the exploit was meant, or maybe the exploit is simply buggy or unreliable. Anyway, the crash occurs at this point in the code:
Image 3: The vulnerable code that is supposed to transfer control to the malicious shellcode
The ECX register contains a pointer that is being dereferenced in order to call some function. In this example, the pointer is invalid and points to an unallocated memory area, causing the software to crash. Normally a working exploit document would be able to abuse a bug like this in order to cause the code to transfer the execution to the sprayed shellcode. In fact, having a look around, we can immediately locate what the exploit was supposed to run:
Image 4: Malicious shellcode to be executed upon successful exploitation
The shellcode is copied at different locations in memory by the Javascript heap-spray code. Notice all the '0c 0c 0c 0c' bytes written to memory, shown in Image 4; these are typically used in heap spraying. I manually ran the shellcode from its supposed entry point, and I found a decryption loop that decrypts part of the remaining shellcode plus some interesting strings, including a URL, shown in the red box in Image 4.
Where does this vulnerability originate from? As we can see, the Javascript code is only running a heap spray, but it’s not trying to exploit anything. So the exploit is likely to be in the Flash application itself. Let’s give it a closer look!
First of all, the Flash application looks like a legitimate application that was slightly modified in order to run the exploit. I started analyzing its ActionScript code, and I found some problems in one of the script modules. The tools I used to disassemble the script objects were giving strange results, like the two snippets of code in the following image:
Image 5: Incorrect code syntax
The syntax of the code is invalid; it seems the decompiler was confused and decompiled invalid bytes, so this is a good indication of where the problem could be. As I kept analyzing the Flash applet, I found several interesting strings inside it. Searching on the Internet brought me to a website that hosts the clean application, including its source code. I quickly downloaded the clean version of the application, and started comparing the bad Flash file with the clean one.
We know that something is wrong in this script and which particular module we have to look for in the binary data of the Flash application. Since I have the clean version, I extracted the ActionScript binary opcode bytes related to the buggy module that we see in Image 5, and I compared them. One single instruction is responsible! The clean Flash application has a valid sequence of opcodes in the code module, seen in Image 5, because such opcodes were the translation from the ActionScript code that was legitimate. The attacker here did not alter the ActionScript code, he modified the compiled opcodes of the Flash virtual machine in order to insert an invalid opcode where it should not be allowed. As a result, the opcode interpreter gets confused when reading these opcodes, leading to an incorrect execution, which ends up as a memory-access violation.
This modification is very subtle, as the opcode is only two bytes long. When I restored it with the clean two bytes, the Flash application becomes legitimate. Both Adobe Reader and Adobe Flash are vulnerable, which means that a malicious Flash application like this can be used both inside a PDF, like in the case of this analysis, or it can simply be embedded in a webpage.
Be sure to update your Adobe software regularly, and avoid opening documents or webpages from any untrusted or unknown source.