This blog was updated on January 14. See the end of the file.
A new Java zero-day vulnerability is spreading malicious files to infect unprotected users. The threat is dangerous: Just browsing a malicious page or clicking a malicious link in spam is enough to cause an infection when combined with a vulnerable Java version.
Because most browsers enable Java by default, this vulnerability can be used by attackers to easily spread malwares using various exploit kits available in the market.
The vulnerability is triggered by abusing restricted package permissions, which makes it possible for untrusted code to get access to classes that are part of restricted packages. Hence this can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.
This vulnerability in Java is very similar in characteristics to Exploit CVE2012-4681, though not completely similar to it.
Generally, the Java Virtual Machine first checks the privilege/permission of the class file or object before allowing it to execute in the Java applet sandbox environment. Any applet that does not have the required credentials will not execute. The goal of attackers is to exploit this vulnerability in order to escalate privileges, which enable the Java applet code to run outside the sandbox.
Figure 1: A typical vulnerability flow for this Java zero-day attack.
As shown in the preceding image, the victim first visits a compromised website link, which in turn loads the malicious Java applet in the vulnerable Java environment and executes the downloaded malicious payload on the compromised user system.
Figure 2: The main exploit code.
The preceding image shows how the attack works. It exploits the vulnerability using “MBeanInstantiator,” which allows the loading of a restricted class by exploiting the “findClass” method of the “com.sun.jmx.mbeanserver.MBeanInstantiator” class. By doing this, we can retrieve the class references of any package.
Steps in exploiting the vulnerability:
- First the call to the vulnerable “com.sun.jmx.mbeanserver.MBeanInstantiator.findClass” is made
- This will then call the “LoadClass” and “Class.forName,” which allow us to load any package in any classes available
- However, the “MBeanInstantiator” constructor is a private member. First, it has to get a reference to an instance of this object so that it can be used to load a class to be used later.
- This is achieved by calling a public static method, which in turn returns the “com.sun.jmx.mbeanserver.JmxMBeanServer” instance.
- The “JmxMBeanServer” class has a public method called “getMBeanInstantiator” [Figure 3], which returns the “MBeanInstantiator” instance. Using this we can find any class that we require using the “findClass” method.
- Then, the attack uses the new reflection API to obtain and call MethodHandle objects [Figure 4].
- This MethodHandle point to methods and constructors of restricted classes that were retrieved earlier, as mentioned above. This is achieved by the “invokeWithArguments” method call of java.lang.invoke.
Figure 3: A JmxMBeanServer code snippet.
Figure 4: The attack uses the new reflection API.
Affected Java Versions
This exploit targets the vulnerability in Java Version 7 Update 10 and earlier.
An initial threat vector may be hosted on a compromised website in the form of an applet that contains code to exploit this vulnerability. The intent of the exploit is to surreptitiously download and execute additional malware on the infected system. An indication of this may be the presence of unusual traffic to unknown domains.
Exploit Kit Seizes the Opportunity
In our analysis, we have seen this vulnerability use various exploit kits, including Blackhole, Red Kit, Cool, Nuclear, and Sakura. These exploit kits appear to push out PWS-Zbot, ransomware, and ZeroAccess as payloads.
McAfee products detect this malware in our latest DATs as Exploit CVE2013-0422.
Because this is a zero-day attack there is no patch yet for the vulnerability. Hence our recommendation is to completely disable Java until the patch for this vulnerability is released.
If you cannot disable Java, you can take any of the following steps:
- In the Java Control panel under the Security tab, set the security level to “Very High.” By doing this, unsigned (sandboxed) apps and local applets will not run.
- Keep your McAfee antimalware definitions updated. We detect this attack as Exploit CVE2013-0422 as well as the payloads it downloads.
Meanwhile, we will continue to monitor this threat closely for new malware payloads and update that information here.
Update, January 14
Oracle has released patch for this vulnerability that is available here. Java users should update their software immediately.
Follow us to stay updated on all things McAfee and on top of the latest consumer and mobile security threats.