Monday, August 27, 2012

CVE-2012-4681 Java 7 0-Day vulnerability analysis

Update Aug.30, 2012
Oracle issued update 7 (7u7), which  fixed the vulnerability

Update: Aug. 28, 2012.  Rapid 7 / Metasploit released their module  and  we get a lot of  questions related to it from people who wish to compare.  See below the original exploit source, to be run from the command line with a security manager enabled, and it will print the contents of the C:\ root directory.  

ladyilonwick.wordpress.com
Considering that Rapid 7 posted a working exploit and addition to the exploit packs is imminent (Attackers Pounce on Zero-Day Java Exploit by Brian Krebs), plus other analysis articles are being published such as New Java 0day exploited in the wild  -by Alienvault, we decided that witholding details of the exploit will not offer additional protection but only hinder development of protection and signatures.

As we mentioned earlier, we contacted Michael Schierl, the Java expert who discovered a number of Java vulnerabilities and asked him to have a look. He sent back his detailed analysis, exploit source, the interim patch with the source code of the patched class.

Update: Aug. 28, 2012. 
CVE-2012-4681
Oracle Java 7 Update 6, and possibly other versions, allows remote attackers to execute arbitrary code via a crafted applet, as exploited in the wild in August 2012 using Gondzz.class and Gondvv.class.

Patch request:  
At this point the patch is by request is not to preserve the code but limit it to IT administrators and developers who can test and decide if they want to deploy. We do not want to push/offer it to 3 billion end java users, it wasn't tested in all the possible scenarios and systems.
  • Interim patch with the source code of the patched class. See the Readme of the patch in the previous post (thanks to Michael Schierl).  
Email from your company email address to admin <at> deependresearch.org   
Additionally, you can request:
  • Commented and stripped-down version of the exploit source, to be run from the command line with a security manager enabled, and it will print the contents of the C:\ root directory (thanks to Michael Schierl)
  • Original 0-day attack HTML page with javascript, Java applet, downloaded Poison Ivy RAT, and pcap.
Email from your company email address to admin <at> deependresearch.org  and explain the planned use, please.


Analysis 
The Gondvv class decompiles cleanly, and that contained all the
interesting parts.
The real vulnerability seems to be inside the new Java7 class
com.sun.beans.finder.ClassFinder,
http://www.docjar.com/docs/api/com/sun/beans/finder/ClassFinder.html
which seems to make it possible for untrusted code to get access to
classes in restricted packages (i. e. packages that are part of the
security implementation itself and where usually untrusted code cannot
get either access or call it).
At the beginning, the exploit uses that ClassFinder class to get a
reference to the sun.awt.SunToolkit class (sun.* is a restricted package).
http://www.docjar.com/docs/api/sun/awt/SunToolkit.html

The rest of the exploit is "only" using that reference to call the
GetField method, which can be used to get access to private fields
(which should not be a problem as the class is in a restricted package),
to get access to a field that stores the permissions for running a
java.beans.Statement.
http://www.docjar.com/html/api/sun/awt/SunToolkit.java.html#301

A Statement is created that disables the security manager (by default
with permissions of the untrusted code). But before calling the
statement, the permissions stored in that field we just got access to
are overwritten with permissions that allow running all code, and the
statement can be called now and disable the security manager for us. At
this point, no security manager is left, and the applet can do anything
Java can.
This method of abusing restricted package permissions is new to me (it
does not work in Java 6 either as GetField was private there); but it is
not unique - there are several ways you can use to get out of the
sandbox if you have access to restricted packages - usually they need a
bit more code though.
What makes the code a bit more complex is the fact, that the bytecode
verifier also tries to verify if you are accessing restricted packages,
therefore all access to restricted packages has to be done indirectly
(that is also good for obfuscation, but here needed to make the exploit
work, too).  ~ Michael Schierl
Update: Aug 28, 2012
Download it 

by Michael Schierl


Read Part I  Java 7 0-Day vulnerability information and mitigation.

More details :
Aug. 28 More detailed analysis > "Immunity. Java 0day analysis (CVE-2012-4681) by Esteban"
Aug. 28 Java 0-Day Using Latest Dadong’s JS Obfuscator by Kahu Security
Aug. 28 US CERT: We are currently unaware of a practical solution to this problem. Disable Java in your browser

CLICK HERE TO SEE IF YOU ARE VULNERABLE (Zscaler) 

The Zscaler tool checks the version of Java used by your browser. If it is below 1.7_7, you need to update it from Java.com. If it is 1.7_ 7 already, you are safe (for now). As of Aug 31, 2012, the Zscaler checker prints "vulnerable for 0-day" for a ALL versions above 1.6, they just need to update the tool. In reality, if you have the latest version of Java, you are not vulnerable to this exploit.
In general, you don't need Java plug-ins in browser, best to keep it turned off. You can still use Java desktop apps.


Andre' M. DiMino and Mila Parkour

12 comments:

  1. The original 'index.html', applet.jar, and exe files are still on the server.

    ReplyDelete
  2. Is this exploit effective against Icedtea, and other Linux platforms?

    ReplyDelete
  3. error: package com.sun.beans.finder does not exist
    import com.sun.beans.finder.ClassFinder;
    ^
    Java7ZeroDay.java:16: error: cannot find symbol
    Class sun_awt_SunToolkit = ClassFinder.findClass("sun.awt.SunToolkit");

    ReplyDelete
    Replies
    1. Use this code instead: http://pastie.org/4594319

      Delete
  4. Demo video exploiting the vulnerability using Chrome on Windows 7: http://youtu.be/HO4yO7_5sEc?hd=1

    ReplyDelete
  5. I think, the OpenJDK6 (update 25) is vulnerable too, because it contains the ClassFinder (backported from JDK7)...

    ReplyDelete
  6. There's no info anywhere whether this works with limited user accounts (not UAC but LUA). If the exploit can not get elevated access, it can not drop anything to system folders. I would have but could not test this, because my employers firewall blocked metasploit. I'll dl it at home and give it a go...

    ReplyDelete
  7. IcedTea version 2.3.1 has been released. The changelog claims CVE-2012-4681 to be patched!
    See http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-August/020083.html

    ReplyDelete
  8. According to the tester, version 1.7_07 is also affected.
    Installed it on a test client i got, and ran the test, and got that it's still affected, just a little typo in the tester, or is the 07 also vulnerable?

    ReplyDelete
  9. How do we use these tests?
    How do we compile them?

    I keep getting
    Error: Main method not found in class cve2012xxxx.Gondvv
    when I try to run it with java.exe

    ReplyDelete
  10. The problem wasn't really that there was a way of getting a reference to sun.awt.SunToolkit.class. After all, you can get a reference anyway, just by doing

    Toolkit.getDefaultToolkit().getClass().getSuperclass();

    The real problem was the existence of a public static method getField that creates privileged Field accessor objects and releases them into the wild. Whoever perpetrated that was being incredibly naive. It appears that the method no longer exists.

    ReplyDelete
  11. Really trustworthy blog entry I have ever found.. Its also informative information. I will definitely bookmark this site for future reference. keep up the good work!
    http://www.surveytool.com/business-market-research/

    ReplyDelete