In the wild Flash exploit analysis – part 2

In the first blog, we talked about how a recent Flash exploit works using heap spraying. In this blog, we will see how the shellcode functions and how it downloads malicious binaries to an infected system. If you remember, malicious shellcode was loaded on heap by the exploit. So let’s try to see if we can identify strings or URLs in the loaded shellcode. If you look closely, the shellcode is not in a readable format and appears to be encoded. Here is the how shellcode looks:

There is no single identifiable string in the shellcode. Let’s debug this shellcode further to understand if it is encoded or not. When we left off in the last blog, we were at a “CALL EAX” instruction with EAX pointing to 08080808. If we press F9, we will land on the heap and start executing every NOP instruction until ultimately reaching the malicious shellcode. We will reach the first instruction of the shellcode by putting a hardware breakpoint in the shellcode. Here is another screenshot of the debugger:

The shellcode contains some unused instructions and it will be difficult to understand it simply using static analysis. Let’s start debugging step by step. The first few instructions are the same and will POP EAX from stack. Then there is short jump call to 08089C42, which will call the address 08089C32. At which point it will XOR the ECX value and push a value of 3B8 (decimal 952) into CX. Then there is small loop, which is very interesting.

08089C3A 80340B BD XOR BYTE PTR DS:[EBX+ECX],0BD

08089C3E ^E2 FA LOOPD SHORT 08089C3A

The first instruction is XORing every byte with 0BD from the last byte i.e. starting from value (EBX+ECX) until the current EBX value as ECX will start decrementing. This is the method used to encode the original shellcode. After exiting from the loop, we land into decoded shellcode which can now be reviewed. Here is the XOR’ed version of original shellcode:

Gr8! Every instruction is now readable and easy to understand. We can now attempt to identify strings. I went into a memory dump of the heap and converted instructions into Hex/ASCII format. Here, I was able to find some known strings and one URL at the end. Here is the ASCII dump:

Now, this looks pretty straightforward. The above decoded shellcode is going to download “css.exe” to the infected system. At this point, I downloaded the malicious file. Let’s open it in OllyDbg and try to find some additional strings and to see what that executable is doing. I quickly looked at the disassembly and was able to quickly realize what the file is doing. I found an additional URL request in the code:

This executable downloads additional malware by visiting “hxxp://www.ffxiname.com”. Then it will add some registry values and run library “C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\300056251037don.dll,Set1” using "C:\WINNT\System32\rundll32.exe”. The TEMP directory will be full of additional malicious executables and DLL’s. The website in question (“ffxiname.com”) appears to be a drop zone, containing numerous additional exploits. The site will deliver different exploits based on the browser issuing the request. Here are some wireshark packet captures from the website:

The site is exploiting browser specific vulnerabilities to push additional malware. This is not the end of this process. It also downloads,

hxxp://www.40sys40.cn/txt/a1.exe

hxxp://www.40sys40.cn/txt/a2.exe

hxxp://www.40sys40.cn/txt/a3.exe

hxxp://www.40sys40.cn/txt/a4.exe

Additionally, two DLL’s are downloaded into the temp folder. The names of the files are “231053kou.dll” and “231054eve.dll”. Based on strings identified in the DLLs, it appears that they are used to sniff passwords for various web domains as can be seen in the following screen capture:

As can be seen, the initial infection due to the Flash vulnerability is only the start of the process. Successful exploitation leads to additional malicious binaries being downloaded to the infected system. The exploit also led to the installation of malicious DLL’s, which steal valuable information such as login credentials when you visit popular web sites.

That’s it for this series. Remember, this chain of infection was triggered when a victim with a vulnerable Flash Player simply viewed a single malicious page – no user intervention was required. This also shows that how active Flash exploits are in the wild. Keep your systems/AV up to date and install latest Flash Player from Adobe.

Be Safe,

Umesh

In the wild Flash exploit analysis – part 1

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

Watered Down Phishing Protection in iPhone OS 3.X?

This summary is not available. Please click here to view the post.