What did the Java applet say to the SWF? Don't leave me alone in this Blackholeee!

Last week as we were analyzing the new version of Blackhole with the new Java exploit (CVE-2012-1723), we ran into a SWF file called Flash.swf that we've not analyzed before. This is a refreshing change, as there haven't been too many updates to the SWF part of Blackhole in a long time, and so we thought we'd give it a spin.

So, how did it all start?

A new massive spam campaign tries to coerce users into clicking a malicious link by sending out an email imploring them to pay an unpaid parking ticket. The following domains were seen hosting this so-called ticket:












The page displays a fake invoice and asks the user to wait. While the user waits, the page loads an IFRAME with the Blackhole exploit kit:

PageThe fake invoice page

We wondered how many people actually wait until the page is fully loaded (with the exploits); luckily we managed to take a closer look at the statistics of this attack, which show pretty poor results for the attackers:

BlackholeThe blackhole exploit kit statistics page

Now, let's take a closer look at the aforementioned new SWF file, and a couple of other recent updates of Blackhole:

Adobe Flash Player AVM Verification Logic Array Indexing Code Execution (CVE-2011-2110):

First of all, here is a snippet from the decompiled ActionScript of Flash.swf:

Flash_as_markedThe ActionScript source code of Flash.swf

As you can see marked in the first box the flash file reads a stream passed from the HTML exploit page as a parameter:


The source code of the exploit HTML page

The ActionScript code manipulates the data provided by the info parameter by converting it to a binary stream, XOR'ing it with 122 and then decompressing it using zlib. This process results in the construction of a URL that is then fetched using a standard URLRequest (also marked in the source code), but our journey does not end here. The data fetched from this URL is not the payload one might expect to find, but rather more binary data which then goes through the same process as the previous binary stream, being XOR'd and decompressed using zlib to ultimately result in yet another URL- this time of the payload:


The deobfuscated binary data

We uploaded the file to VirusTotal:

Flash_VT VirusTotal scan results for Flash.swf

As you can see, 9/42 AV scanners detected this file as malicious, but despite some of the reports, this SWF actually exploits CVE-2011-2110:

The Metasploit module for CVE-2011-2110

… Looks familiar?

Oracle Java Applet Field Bytecode Verifier Cache Remote Code Execution (CVE-2012-1723):

The newcomer Java exploit in this version of Blackhole is CVE-2012-1723. There's a great description regarding the actual vulnerability made by Michael Schierl. This vulnerability joins the family of Type Confusion vulnerabilities detected in the JVM and we believe it isn't the last one. Many efforts are put by researchers and malware authors to find such bugs in the JVM, as they usually have high successful exploitation rate. As you can see in the admin panel above, JVM vulnerabilities are responsible for the majority for successful exploitations made by Blackhole.

Despite its high profile in the media and its success rate, a quick visit to VirusTotal revealed that the detection rates for this java exploit are still very low (3/42):

Java_VTVirusTotal scan results for Fiord.jar

It is quite obvious that the exploits included in the Blackhole Exploit Kit for CVE-2012-1723 and CVE-2011-2110 are adopted from the Metasploit framework. The exploit for CVE-2012-1723, though, seem to have evolved and now also contains bytecode obfuscation.

Bytecode obfuscation is a technique which we recently described after it was employed in the RedKit exploit kit, which makes it the most common method for obfuscating Java malware nowadays.

Internet Explorer MSXML Uninitialized Memory Corruption (CVE-2012-1889):

This last one has been mentioned in the context of the Blackhole exploit kit in several places already, but since this vulnerability was released as a 0-day just last month, it's worth noting that it, too, is already part of the new Blackhole exploit lineup, if only to make a point.

It is obvious that the Blackhole authors put a lot of effort into keeping the exploit kit up-to-date both in terms of vulnerabilities and in terms of obfuscation techniques, and we expect to see more such updates in the future.

Trustwave Secure Web Gateway's generic protection against 0-day attacks protects its customers from exploitation attempts of the above vulnerabilities without the need for installing new security updates.

Authored by: Moshe Basanchig, Daniel Chechik and Anat Davidi.

Trustwave reserves the right to review all comments in the discussion below. Please note that for security and other reasons, we may not approve comments containing links.