{"id":21230,"date":"2013-01-14T12:47:11","date_gmt":"2013-01-14T20:47:11","guid":{"rendered":"http:\/\/blogs.mcafee.com\/?p=21230"},"modified":"2025-06-02T03:07:46","modified_gmt":"2025-06-02T10:07:46","slug":"java-zero-day-vulnerability-pushes-out-crimeware","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/java-zero-day-vulnerability-pushes-out-crimeware\/","title":{"rendered":"Java Zero-Day Vulnerability Pushes Out Crimeware"},"content":{"rendered":"

This blog was updated on January 14. See the end of the file.<\/strong><\/p>\n

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.<\/p>\n

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.<\/p>\n

Exploit Analysis<\/strong><\/h2>\n

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.<\/p>\n

This vulnerability in Java is very similar in characteristics to Exploit CVE2012-4681,<\/a> though not completely similar to it.<\/p>\n

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.<\/p>\n

\"\"<\/a>Figure 1: A typical vulnerability flow for this Java zero-day attack.<\/p>\n

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.<\/p>\n

 <\/p>\n

\"\"<\/a>Figure 2: The main exploit code.<\/p>\n

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 \u201cfindClass\u201d method of the \u201ccom.sun.jmx.mbeanserver.MBeanInstantiator\u201d class. By doing this, we can retrieve the class references of any package.<\/p>\n

Steps in exploiting the vulnerability:<\/b><\/h2>\n
    \n
  1. First the call to the vulnerable \u201ccom.sun.jmx.mbeanserver.MBeanInstantiator.findClass\u201d is made<\/li>\n
  2. This will then call the \u201cLoadClass\u201d and \u201cClass.forName,\u201d which allow us to load any package in any classes available<\/li>\n
  3. However, the \u201cMBeanInstantiator\u201d 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.<\/li>\n
  4. This is achieved by calling a public static method, which in turn returns the \u201ccom.sun.jmx.mbeanserver.JmxMBeanServer\u201d instance.<\/li>\n
  5. The \u201cJmxMBeanServer\u201d class has a public method called \u201cgetMBeanInstantiator\u201d [Figure 3], which returns the \u201cMBeanInstantiator\u201d instance. Using this we can find any class that we require using the \u201cfindClass\u201d method.<\/li>\n
  6. Then, the attack uses the new reflection API to obtain and call MethodHandle objects [Figure 4].<\/li>\n
  7. This MethodHandle point to methods and constructors of restricted classes that were retrieved earlier, as mentioned above. This is achieved by the \u201cinvokeWithArguments\u201d method call of java.lang.invoke.<\/li>\n<\/ol>\n

    \"\"<\/a><\/p>\n

    Figure 3: A JmxMBeanServer code snippet.<\/p>\n

    \"\"<\/a><\/p>\n

    Figure 4:\u00a0 The attack uses the new reflection API.<\/p>\n

    Affected Java Versions<\/b><\/h2>\n

    This exploit targets the vulnerability in Java Version 7 Update 10 and earlier.<\/p>\n

    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.<\/p>\n

    Exploit Kit Seizes the Opportunity<\/b><\/h2>\n

    In our analysis, we have seen this vulnerability use various exploit kits, including Blackhole, Red Kit<\/a>, Cool, Nuclear, and Sakura. These exploit kits appear to push out PWS-Zbot, ransomware, and ZeroAccess as payloads.<\/p>\n

    McAfee products detect this malware in our latest DATs as Exploit CVE2013-0422<\/a>.<\/p>\n

    Mitigation<\/b><\/h2>\n

    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.<\/p>\n

    If you cannot disable Java, you can take any of the following steps:<\/p>\n