This threat is a malicious Java applet that exploits vulnerability CVE-2012-0507 in the Java Runtime Environment (JRE).
The exploit is loaded if you visit a website that has the malicious code and you are using a vulnerable version of Java. It then tries to download and run files, including other malware. A number of legitimate websites could be hacked to unwillingly host a malicious applet through advertising frames which redirect to or host a malicious Java applet.
Threat in context
Java is a general-purpose programming language, but cases of this exploit are targeted against the Java plug-in for web browsers. The intent of the Java plug-in is that Java programs (or "applets") can be offered by websites, and run in a "sandbox" where the Java plug-in enforces rules on what the Java applet can do so that it cannot escape restricted environment.
What is an exploit?
Exploits are written to take advantage of weaknesses (or vulnerabilities) in legitimate software. A project called Common Vulnerabilities and Exposures (CVE) gives each vulnerability a unique number, in this case "CVE-2012-0507". The portion "2012" refers to the year the vulnerability was discovered, and "0507" is a unique ID for this specific vulnerability. You can find more information on the CVE website.
Payload
Installs other malware
We have seen variants of this exploit install TrojanDownloader:Win32/Carberp and Win32/Zbot on Windows-based PCs.
On Mac OSX, the malware was observed to install a threat called Backdoor:MacOS_X/Flashback.F.
If the exploit successfully compromises a PC, it can run a file that might also be distributed with the exploit, or a file from a certain website.
In the wild, we've observed Exploit:Java/CVE-2012-0507 distributing variants of the following malware families:
Additional technical details
CVE-2012-0507 is a vulnerability that appeared in late February 2012. The security problem lies in the AtomicReferenceArray class of JRE. The class member methods like "set" and "lazySet" let untrusted code like the Java applet to do a lower-level byte array operation. By using this vulnerability, the attackers can trigger type-confusion in an array. This will break type safety in JRE and will let the attackers to directly use an applet class loader. Using this unauthorized access to the applet class loader, the attacker can load any class with their own designated permission sets.
The vulnerability lets the JRE sandbox model to be broken, and it can eventually lead to a privilege escalation issue, leting an unsigned Java applet to run arbitrary commands on the affected PCs. The vulnerability itself is not platform-dependent, but we mostly see this attack used against Windows customers. Attacking the security model means that the exploit might be effective on any platform the Java interpreter is on; for example Windows, MacOS, Linux, etc.
Until the end of August 2012, the exploit was mostly used in a standalone form. But since the discovery of a newer Java vulnerability, CVE-2012-4681, CVE-2012-0507 began to be used in combination with CVE-2012-4681. The reason why the newer vulnerability, CVE-2012-4681, couldn't override the old vulnerability is that CVE-2012-0507 is applicable to JRE 6 and JRE 7 environments, whereas CVE-2012-4681 is only applicable to the JRE 7 environment. The malware authors tried to increase their coverage using a single JAR package with multiple exploits inside them. This triggered a trend of using multiple exploits in a single container.
This continues with the vulnerabilities found later for JRE 7. At the end of November 2012, we saw CVE-2012-5076 was being combined with CVE-2012-0507. Later in February 2013, it started being used in combination with CVE-2013-0422. This coverage of JRE 6 and JRE 7 with CVE-2012-0507 made it one of the most popular Java vulnerabilities to be used in exploit kits.
These JAR packages are usually produced by the Blackhole exploit kit - a kit used by attackers to distribute malware.
Below are some examples of files that exploit the vulnerability described in CVE-2012-0507:
- bomnkq0.class
- bomnkq1.class
- bomnkq2.class
- fgeztqkfueeyv0.class
- fgeztqkfueeyv1.class
- fgeztqkfueeyv2.class
- molfke0.class
- molfke1.class
- molfke2.class
- sccgubwmbiywhye0.class
- sccgubwmbiywhye1.class
- sccgubwmbiywhye2.class
- snamlpoicrh0.class
- snamlpoicrh1.class
- snamlpoicrh2.class
Related information / Related references
The articles below outline some of the technical details of the weakness this vulnerability exploits:
Analysis by Jeong Wook (Matt) Oh, Ferdinand Plazo & Patrick Estavillo
