Encrypted Flash Exploit that Bypasses Mitigations Found In the Wild

One of our favorite things to do is to reproduce exploits in our research labs. We do this for two main reasons: first, because we are naturally curious, and second, to constantly ensure that our solution prevents these exploits natively (spoiler: it does ;).

A recent exploit caught our attention due to its unusual delivery method, one that is extremely challenging to reproduce. We took the time to simulate it in our lab – technical details about how we did it are below – and got an unexpected bonus; it turns out that when decrypted, the exploit takes advantage of a bypass to Flash version 18.0.0.209 that was supposedly already mitigated according to Google’s Project Zero. Yet, here we had in our lab a variant, from an “in the wild” sample, that could still bypass the mitigations.

Unusual Obfuscation in Exploit Delivery

Let’s take a step backward for a minute. First of all, what is this unusual delivery method? It typically starts by a user visiting a popular site which has an exploit placed on it through malvertising or other means, aka a “watering hole attack.” The exploit, which is encrypted, automatically slips into the user’s computer via the Web browser.

Besides being encrypted – which already makes it hard to detect – the exploit uses another obfuscation technique: in order to be activated, the exploit needs access to a server side component. This means that the exploit typically runs just once, making this “disposable” exploit nearly impossible to reproduce.

Who Cares About Reproducing the Exploit?

I mean if it already ran on your computer, it’s a lost cause, right? Well, AV vendors would love to reproduce it, since this is a key way to reverse engineer it and create signatures. But gaining access to this server-side component – which can be changed whenever the hackers feel like it – is a big challenge. We were able to recreate the server-side based on instructions from our colleagues over at Kaspersky (see below for details).

Luckily Morphisec is not signature-based, so reproducing the exploit is just to help us and our customers feel secure that indeed our solution blocks it.

How Morphisec Blocks the Exploit

If you were to get hit with this type of “watering hole” exploit in the real world, your browser would typically decrypt the file, and the exploit would immediately try to run while inside the browser. Morphisec catches the exploit as it is attempting to execute (in its first steps). Note that we never needed to reverse engineer the exploit or even to reproduce it (we just did that for fun) in order to protect against it. Morphisec delivers automatic forensic categorization of the exploit on its first execution attempt and prevents the exploit from compromising the end-point.

If you’re hungry for more details, keep going… all the juicy stuff is below.

The Technical Details

Our journey started with the effort to reproduce the Flash exploit CVE-2015-5560 delivered by Nuclear exploit kit and learn about its nature post decryption.

Source: http://malware.dontneedcoffee.com/2015/08/cve-2015-flash-player-up-to-1800209-and.html

First, we found the secret key used for encryption thanks to Kaspersky’s algorithm. Here is the Java Algorithm for finding the secret key:

Once we found the secret key (0x31c53c1580f2cd03f44379225393c9df) we wrote a PHP server side script to reproduce the server response:

Contact us to get a sample of the server side code.

Then we let the exploit run using our simulated environment where we used Morphisec protection to block and analyze the exploit. To our big surprise, we found out that the exploit itself (after decryption) was employing vector exploitation on Flash version 18.0.0.209 even though it had been declared that vector corruption exploitation is mitigated starting in this version. The following screenshot shows the exploit blocked by Morphisec during exploitation:

Here we can clearly see that there was a corruption of the vector size to 40000000 (0x40000000 ^ 0x89a18bd4 -> cookie):

This in-the-wild exploit residing in a Nuclear exploit kit bypasses the recent Flash mitigation for vector corruption, and thanks to Morphisec’s just-in-time capture of exploitations we instantly identified the non-encrypted version of the exploit and its path into memory.

--