Archive for the ‘CVE-2011-0611’ Category

Analysis of the CVE-2011-0611 Adobe Flash Player vulnerability exploitation

April 13th, 2011 Comments off

About a month ago, we blogged about an Adobe Flash Player vulnerability (CVE-2011-0609) that was actively exploited in the wild. That exploit was hidden inside a Microsoft Excel document. Over the weekend, a new Adobe Flash Player 0-day (CVE-2011-0611) was reported by Adobe in a recent advisory (APSA11-02).

It all started with spam emails enticing users to open its attachment, typically a Microsoft Word document (or a zip file of a Microsoft Word document), which contained the malicious Flash exploit inside.  Most of the files we have captured with our signature are named:

  • Fukushima .doc
  • evaluation about Fukushima Nuclear
  • 首場政見會後最新民調略升-蔡英文粉絲團~聲援 .doc
  • 日志分析.doc

Inside the .doc file a malformed Adobe Flash file is embedded. Once a user opens the document, Flash Player will load the malicious file and exploitation will occur. Unlike the previous vulnerability, a bug in the ActionScript Virtual Machine version 1 is now used in the exploitation process. Another difference is that this is not a result of fuzzing clean files. We won’t disclose any detail on what triggers the vulnerability, for security reasons, obviously.

In order to exploit this vulnerability the attackers packaged the AVM1 code inside an AVM2 based Flash file. The latter is embedded inside the Word document and assigned with setting up the exploitation environment.

Initially the AVM2 code constructs a heap-spray buffer made of a NOP-sled (image below):

Image 1 – NOP-sled

The AVM2 code constructs a Win32 shellcode(constructed in highlighted  ByteArray  “s”):

Image 2 – shellcode

It then loads the attack code inside the Flash Player. The AVM1 code that triggers this vulnerability is loaded as a separate SWF file, converted from a hex-encoded embedded string and executed as in the screen dump below:


Image 3 – CVE-2011-0611 attack code

Shellcode details

The shellcode is injected starting at address 0x11111111 and is a fairly standard one.

Its task is to launch the payload while trying to hide the signs of an infection. It does that by dropping a clean Word document which will replace the original, malicious one.

Let’s see, in detail, what the shellcode does once it gets executed:

  • Resolves needed APIS’s :
    • LoadLibraryA
    • GetFileSize
    • GetTempPathA
    • TerminateProcess
    • CreateFileA
    • WideCharToMultiByte
    • SetFilePointer
    • ReadFile
    • WriteFile
    • WinExec
    • CloseHandle
    • GetCommandlineA
    • GetModuleFileNameA
    • CreateFileMappingA
    • MapViewOfFile
    • GetLogicalDriveStringsA
    • QueryDosDeviceA
    • ZwQueryVirtualMemory
  • Brute-forces its way to the Word document’s file handle by knowing that
    • File size must be > 0x7000
    • It must contain the marker 0x7010 at offset 0x7000
  • Retrieves the file path of the Word document file using ZwQueryVirtualMemory and GetLogicalDriveStringsA
  • Decrypts a binary from the document, dumps it as %temp%\scvhost.exe (SHA1 adbf24228f0544a90979a9816569e8c7415efbac – detected as Backdoor:Win32/Poison.M) and finally executes it.


Image 4 – Win32 Shellcode fragment

  • Decrypts an embedded doc file and saves it as ‘%temp%\AAAA’. This file is the clean Word document we mentioned earlier.
  • The freshly dumped doc file is then used to overwrite the initial Word document.
  • The new document is launched to hide symptoms of infection.
  • Using the utility “taskkill.exe”, it terminates all processes with the name ‘hwp.exe’.

The current WinWord (Microsoft Word) instance is terminated.

We currently detect the malicious Word document and the embedded attack Adobe Flash file as Exploit:SWF/CVE-2011-0611.A. We urge you to read the advisory from Adobe for mitigation details about this vulnerability.As always, we advise you not to open emails from untrusted sources or emails that seem suspicious to you, even if they apparently come from people you know.

Marian Radu, Daniel Radu & Jaime Wong

PS: We’d like to thank our colleague Bruce Dang for his contribution to this blog post.