This blog discusses our analysis of the recent Adobe Flash zero-day vulnerability. Trend Micro received a sample Shockwave Flash (.SWF) file that exploited this 0-day vulnerability. Since the original blog post was posted, we have been analyzing this sample to determine how the exploit works.
Let’s call the sample .SWF file exploit.swf. Quick analysis reveals that it contains ActionScript 3.0 tags. (ActionScript is a scripting language developed by Adobe, which is used in .SWF files.) This exploit will use ActionScript commands to spray shellcode into memory and load another .SWF file using the LoadBytes function of ActionScript 3.0.
Let’s dump this second .SWF file and save it as exploit2.swf. By opening it with Internet Explorer (with the Flash Player plug-in installed), we get a crash in flash10h.ocx, a file associated with Flash Player.
The value in the address of ecx (which, in turn, is passed to eax) is overwritten with a invalid value. If the attacker can spray enough shellcode into memory and cover the address 0e02fd9d (the value of edx), he/she will be able to exploit the vulnerability.
Searching for the Original File
We can spend hours or even days tracing the execution of the program. There’s a significant risk, however, of getting lost in the junk of assembly code. However, we can be more clever and see whether we can find any more evidence from the sample file itself.
While analyzing exploit2.swf, we found that it displays a waterfall animation. Now, what does this beautiful waterfall mean? Why did the attacker need to display a waterfall while exploiting the vulnerability?
Based on my experience, vulnerability hunters always use fuzzing to discover new vulnerabilities. In fuzzing, attackers collect large amounts of normal files from the Internet and make some changes to these to see if the application will crash.
I have seen malicious files generated by modifying a normal file before. Is it possible that exploit2.swf has an original template somewhere on the Internet? Let’s check Google.
After searching the Internet for a few minutes, I found this page.
This is exactly what we are looking for. The image can be found in a site that provides a tutorial for Flash users. The particular page focuses on creating a site using ActionScript 3.0. Among the materials available for download was a file named waterfall.swf.
Spot the Differences
Now, we need to prove our assumption that this waterfall.swf is the file from which exploit2.swf was derived. We extracted the tag information (offset, ID, length) from both .SWF files and did a simple comparison. More than 90 percent of the tags are identical. Waterfall.swf has some more font-related tags than exploit2.swf and their DoABC tags (the tag for ActionScript 3.0) had some differences.
I guessed that the DoABC tag was somehow related to this vulnerability so I did another experiment. I replaced the DoABC tag in exploit2.swf with the one from waterfall.swf. Exploit2.swf no longer crashed. I then repeated the experiment using the tag from exploit2.swf for waterfall.swf. As expected, waterfall.swf crashed!
As the DoABC tag was the cause of the crash, the vulnerability must lie in ActionScript Virtual Machine 2 (AVM2), which is responsible for executing ActionScript code. We compared the two DoABC tags and found a suspicious difference.
This piece of code is part of a member function of an ActionScript 3.0 library. There is no reason for any difference here. It must be the result of mutated base fuzzing, which, in this case, only changed 1B in the code. Using a debugger to trace the execution, we found that the overwrite of the memory mentioned earlier immediately happens after the execution of the modified function.
As our last step, let’s reproduce the modification that the attacker did to the original file. We decompressed waterfall.swf, opened it in an hex editor, and modified the corresponding place in the code. An identical crash to that exhibited by the malicious file was seen.