Today, one of my colleagues requested that I provide additional details about a web page that we had blocked for a customer. The blocked URL was ‘hxxp://www.39sys39.cn/htm/ie.html’. He wanted details about the threat present on the page. I downloaded the page and found out that it contained obfuscated JavaScript with heap spray code. I also found that the exploit contained an tag with a source file called “xp.swf”. At first glance, it was clear that the page is trying to exploit a Flash vulnerability. The exploit code is shown below:
The above exploit employed simple obfuscation to evade signature engines. If we decode the above script, we find the following:
It is also spraying the heap on an address of “0x08080808”. Shortly, we will learn why this address is needed to exploit the vulnerability. I downloaded both the “ie.html” and “xp.swf” files for further analysis. I also uploaded the “xp.swf” file to Virustotal to see if it was a known exploit or perhaps zero day content. Only 9 out of 41 antivirus engines detected the file as a virus. Those that did, identified the file as an exploit attacking CVE-2009-1862. This is a recent vulnerability, for which exploit code is currently in the wild, affecting Adobe Reader and Adobe Flash player. To check if the exploit was working properly, I replaced the shellcode in the exploit with simple shellcode that will execute “calc.exe”. I opened this file with both Firefox and Internet Explorer and here is what happened,
The JavaScript code successfully exploited the known vulnerability in Flash and executed our replacement shellcode to open “calc.exe”. This demonstrates just how dangerous the vulnerability is as it requires a victim to simply visit a malicious page containing the Flash exploit. No further user intervention is required. In this case, I had replaced the original shellcode for testing and the exploit opened calculator successfully. Next, I wanted to determine the purpose of the original shellcode, so I then modified the original exploit code to force a crash in order to debug further. I ran the file again, this time with Internet Explorer and received the following popup message:
The referenced memory address in the above figure is “0x08214408. The program is unable to read data from an invalid address, which led to a crash. Now if you remember, the original exploit in the first image of the blog uses the “0x08080808” memory address to spray the heap with shellcode. Bingo! This means the program is crashing may be due to memory corruption. That is why the exploit must spray the heap with an address of “0x08080808”. I then clicked on cancel button to debug further. I wanted to find which instruction actually reads the data and calls the shellcode. Here is the first state of the OllyDbg debugger:
Look at the above instructions. The register EDX is trying to read a value from ESI which points to invalid address 08214408. Let’s analyze the instructions that follow.
MOV EDX,DWORD PTR DS:[ESI]
MOV EAX,DWORD PTR DS:[EDX+44]
PUSH EBP
MOV ECX,ESI
CALL EAX
TEST AL,AL
Let’s assume [ESI] contains some value which is moved to EDX. Then EAX will contain the value [EDX+44]. Then the program will push EBP on the stack, move the ESI address to ECX and look at the next instruction “CALL EAX”. This is where a call has been made to execute the shellcode. We can conclude that if we spray the heap with 08080808 and shellcode, [ESI] will contain 08080808, which will be moved to EDX. EAX will also contain 08080808 which will be called after the “MOV ECX, ESI” command. Then this call will jump to heap memory at an address of 0x08080808 and execute the shellcode. Let’s see if that holds true.
This time I reopened the original exploit in the Firefox, put a breakpoint at the above-mentioned instructions and sure enough, we were right. EAX now points to 08080808 and the heap is sprayed with 08 bytes and shellcode. If I press “F9” to continue, it will jump onto the heap area and will execute the instruction found. The instruction 0808 is effectively a NOP sled. It is simply “OR BYTE PTR DS:[EAX],CL” which will do nothing as CL contains 08. It will reach the shellcode by executing 0808 instructions and ultimately execute the malicious code.
This means some field/value from the malicious Flash file is causing memory corruption. Here is the how original shellcode is loaded into memory,
This is just overview of how this exploit works. In the next part we will see what original shellcode does. Specifically, we will identify the additional content downloaded to the victim’s machine.
This exploit proves that flash exploits can be very dangerous. Such exploits do not require user intervention. Simply by visiting a malicious web page, the victim will be exploited.
That’s for part 1 now. Do come back for part 2 of this blog.
Umesh
