Researchers Identify Second New Java Bug

Author: Dennis Fisher
minute read

Researchers who have dug into the exploit for the new Java CVE-1012-4681 vulnerability found that there are actually two previously unknown security bugs in Java 7 and that the exploit, which has been tied to attackers in China, is using both of them to get full control of vulnerable machines.

JavaResearchers who have dug into the exploit for the new Java CVE-1012-4681 vulnerability found that there are actually two previously unknown security bugs in Java 7 and that the exploit, which has been tied to attackers in China, is using both of them to get full control of vulnerable machines.

The Java vulnerability was first disclosed publicly on Sunday and researchers have spent the last couple of days looking at the bug as well as the exploit code that’s been used in some of the attacks. What they found is that there are in fact two distinct zero day vulnerabilities in the latest version of Java and that the known exploit uses them both.

“The first bug was used to get a reference to sun.awt.SunToolkit class that is restricted to applets while the second bug invokes the getField public static method on SunToolkit using reflection with a trusted immediate caller bypassing a security check,” Esteban Guillardoy of Immunity Inc., wrote in an analysis of the vulnerabilities.

“The beauty of this bug class is that it provides 100% reliability and is multiplatform. Hence this will shortly become the penetration test Swiss knife for the next couple of years.
 
“There are 2 different zero-day vulnerabilities used in this exploit: one is used to obtain a reference to the sun.awt.SunToolkitclass and the other is used to invoke the public getField method on that class. The exploit is making use of the java.beans.Expression which is a java.beans.Statement subclass. There are 2 Expression instances that are used to trigger these 2 different bugs.”
 
Oracle has not released any security advisories or acknowledged the new vulnerabilities yet and there is no official patch available for them either. The team at DeepEnd Research has a third-party unofficial patch available that was developed by Michael Schierl, but it is only available by request.
 
The worse news is that an exploit for the new bugs has already made its way into the BlackHole exploit kit. That kit is one of the more popular exploit packs in use by attackers right now and is easily available on the underground. The best advice for users right now is to disable Java entirely as soon as possible. Instructions for disabling Java in popular browsers can be found here. 
 
Guillardoy said that while exploiting these Java vulnerabilities is not difficult at this point, finding and developing the original exploit was a different story.
 
“At this moment exploiting this vulnerabilities is not hard, in fact the PoC that was released is almost a fully working exploit and with a just few changes setting a different payload instead of popping up a calculator you have everything you need. However finding these vulnerabilities and use them in a useful way is a much harder task that requires a wide knowledge of the Java JDK/JRE codebase and deep understanding of the Java security architecture,” he said via email.
 
“The interesting thing here is that most people thought that this was just one vulnerability but there are two different bugs cleverly used together to exploit the target. These 2 bugs alone are not enough to exploit a target and this is where the sun.awt.SunToolkit class comes in place together with the Statement class. The attackers chained the 2 bugs to be able to work with the sun.awt.SunToolkit class that is restricted to applets in order to be able to access and set private fields on any class and figured out that they could use this to change the Statement AccessControlContext and get full privileges,” Guillardoy said.
 

Suggested articles

Discussion

  • Anonymous on

    Dennis,

    I've been watching this for a couple of day now and I can't find a definitive answer on the scope of the privilege elevation this exploit is running. Based on the early analysis, it looks as though the exploit is trying to drop and run a dll in the windows/system32 path. On a hardened workstation this should fail under the user profile. What I can't determine is if the privilege escalation is to escape the v.7 "sandbox" granting the users permissions, or does it allow system privilege?

  • Anonymous on

    Dennis,

    I've been watching this for a couple of day now and I can't find a definitive answer on the scope of the privilege elevation this exploit is running. Based on the early analysis, it looks as though the exploit is trying to drop and run a dll in the windows/system32 path. On a hardened workstation this should fail under the user profile. What I can't determine is if the privilege escalation is to escape the v.7 "sandbox" granting the users permissions, or does it allow system privilege?

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.

Subscribe now

Topics

Show all

Authors

Threatpost

InfoSec Insider

Infosec Insider Post

Infosec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Content

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.