Friday, September 18, 2009

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.


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://”. 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 (“”) 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,





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,


Thursday, September 10, 2009

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://’. 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.







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.


Wednesday, September 9, 2009

Watered Down Phishing Protection in iPhone OS 3.X?

[Update: 09-13-09 @ 5:43pm EST - Looks like we may have finally resolved this. Apple has apparently issued a statement indicating the the anti-phishing filter doesn't take affect until the blacklist is downloaded which only occurs while the phone is charging. According to the statement, users should "launch Safari, connect to a Wi-Fi network and charge their iPhone with the screen off". Certainly a bit odd, but at least the functionality seems to be working after all.]

[Update: 09-11-09 @ 4:27pm EST - It would appear that the wrinkles have largely been ironed out. In a random sample of 50 pages blocked by Safari for OS X, only one was not blocked by Safari for iPhone OS 3.1. So what happened?
1.) Sites not blocked on 09-09-09, were blocked 24 hours later
2.) People have been seeing inconsistent results, whereby the same pages would be blocked by one phone and not another
Based on what we've seen, it seems likely that the issue was not with the blocking feature itself within iPhone OS 3.1, but rather the updates being pushed to iPhones. At the time of the iPhone OS 3.1 deployment, some phones were not receiving updates while others were.]

[Update: 09-10-09 @ 2:39pm EST - Today, we're seeing inconsistent results. Sites that were yesterday confirmed not to be blocked by Mobile Safari (iPhone OS 3.1), despite being block by Safari in OS X, are now being blocked yet others are not. For example, is now being blocked (wasn't yesterday) and is still not being blocked on the iPhone, despite being blocked by Safari for OS X. We'll need to hear from Apple to know for sure but I suspect that the failed blocking is related to phishing updates not being delivered to the iPhone as opposed to as issue with the functionality itself.]

I've complained in the past that mobile browser vendors have not learned from past mistakes. Despite the fact that functionality such as phishing and malicious URL black lists are now common place in mobile web browsers, their mobile counterparts have virtually no security controls whatsoever. I was encouraged when Apple announced anti-phishing protection with the release of iPhone OS 3.0.

iPhone OS 3.0 was released on June 17, 2009 - three months ago. Despite that fact, I don't recall ever having received a phishing block message on the iPhone. Today, Apple released iPhone OS 3.1 and once again specifically called out phishing protection. In fact, within the Safari settings, there is now a Security section with a Fraud Warning option. By selecting this option, which is on by default, you will be "warn[ed] when visiting fraudulent websites". Sounds great. The problem? It doesn't work.

Apple's Safari web browser, leverages Google's SafeBrowsing initiative to block both malicious URLs and phishing sites. Not so for mobile Safari on the iPhone. Apple has only chosen to only target phishing sites on the iPhone. While Apple would likely argue that malicious content on web sites target browser specific vulnerabilities, that's not much of an argument. Attacks that I refer to as naked browser attacks such as cross-site scripting (XSS), cross-site request forgery (CSRF) and Clickjacking don't discriminate - they impact all browsers equally. Moreover, past Apple vulnerabilities suggest that there is no shortage of code sharing between the iPhone OS and OS X. After all, the initial iPhone jailbreaks leveraged a known vulnerable TIFF rendering library.

Beyond this, the phishing protection on the iPhone is ineffective. I've tested a variety of online/validated phishing sites from PhishTank. They were generally blocked by Safari, but none were blocked by Safari Mobile. In fact, I have yet to identify a single phishing page blocked on the iPhone. What's clear here is that the functionality for the iPhone is not equivalent to what is being employed by OS X. Why? Apple touts Mobile Safari as the killer app that finally makes surfing the web on a mobile device a realistic proposition and the numbers back up that claim. Surely I can be phished on the iPhone just as I can fall victim browsing the web on my laptop.

If you identify phishing sites blocked by the iPhone OS 3.1 software, please post the link to the blog comments. If you work for Apple, please comment on why you went with watered down phishing protection on the iPhone.

- michael