Java 0day Mass Exploit Distribution

Just a quick note, it’s only the second week of January, but early 2013 brings with it the first Java 0day mass exploit distribution of the year.

There appears to be multiple ad networks redirecting to Blackhole sites, amplifying the mass exploitation problem. We have seen ads from legitimate sites, especially in the UK, Brazil, and Russia, redirecting to domains hosting the current Blackhole implementation delivering the Java 0day. These sites include weather sites, news sites, and of course, adult sites. A few obfuscated files are being delivered to victim systems with names like Stretch.jar, Edit.jar, UTTER-OFFEND.JAR, and more. The first appearance of the exploit’s prevention in our KSN community seemed to be January 6th. But as we dig back further, we find related samples from mid-December. So, we have been preventing this 0day in particular for quite some time. At this point, it seems that the first instance of the particular 0day jar file contents ITW is 7550ce423b2981ad5d3aaa5691832aa6. Filenames for the class files remain the same until recently. It would be interesting to see an earlier instance.

As for Kaspersky users, our automatic exploit prevention (AEP) is generically preventing the 0day. Surprisingly, while there doesn’t appear to be a high level of server-side polymorphic obfuscation in the class files themselves, the hosted exploit files are being updated and changing since yesterday. Instead, the Blackhole developers and operators put a lot of effort behind shifting domain names.

Update (2012.01.10 3:30 p.m. MT) – Metasploit developers have added an exploit module targeting this vulnerability CVE-2013-0422.
Well, the cat is out of the bag. Not only was the 0day circulating in the more prevalent exploit kits like Blackhole, Nuclear, and Red Kit, but now everyone is armed with the metaploit version. On that note, here is a bit more data…The filenames of the exploit as it was originally released and subsequently prevented by our AEP on December 17th (Moscow time) included ewjvaiwebvhtuai124a.class, hw.class, and test.class. This is interesting because previous Java exploits in Blackhole simply distributed mac.class, hw.class and test.class in their jar archives. So it was a simple switch, perhaps intended to fly under the radar. Perhaps it is interesting that the first known victim system executing the exploit retrieved the malcode with a Firefox browser, demonstrating the robustness of Java exploits. Also, in December 2012, the 0day was used to distributed TDSS and ZeroAccess malware.

Here is a chart of our Java 0day detections from late December through early Jan 2013. Notice the spike on January 9th. It’s great to see our technology working effectively:

For those of you that want to see detections on virustotal before you believe “AV” prevents a threat, you may also see HEUR:Exploit.Java.CVE-2013-0422.gen, Exploit.Java.Agent.ic, Exploit.Java.Agent.id, Exploit.Java.Agent.ie, Exploit.Java.Agent.if and others for file scanning purposes. An updated heat map of the HEUR:Exploit.Java.CVE-2013-0422.gen detections shows a more widespread distribution of the exploit in the thousands, the time range here is January 6th – January 11th:

One of the best statements that I have seen in regards to the fairly impractical “just uninstall it” approach was presented by one of the handlers at the ISC Storm Center in today’s issue of SANS NewsBites: “Editor’s Note ([Mat] Honan): It seems each time a zero day exploit is found in software, be that Java or otherwise, the industry pundits recommend that people stop using that software. New vulnerabilities will always be discovered in the software we use. If our best defence to a threat is to cause a denial-of-service on ourselves then this in the long term is a no-win strategy for us as an industry. We need to look at better ways to defend our systems and data, one good place to start is the 20 Critical Security Controls. Cheers to that.