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

Java 7 0-Day vulnerability information and mitigation.

Update Aug.30, 2012

Oracle issued update 7 (7u7), which  fixed the vulnerability

  

img.kids.discovery.com

The cat is out of the bag. There is a 0-day out there currently being used in targeted attacks.  The number of these attacks has been relatively low, but it is likely to increase due to the fact that this is a fast and reliable exploit that can be used in drive-by attacks and all kinds of links in emails. Interestingly, Mark Wuergler mentioned on August 10 that VulnDisco SA CANVAS exploit pack now has a new Java 0-day. It makes you wonder if it is the same exploit that leaked from, or was found in the wild and then added to the CANVAS pack. Or if it is totally unrelated and there are two 0-day exploits now.

The purpose of this post is not to provide the vulnerability analysis or samples, but to offer additional information that may help  prevent infections on some targeted networks.   We all know what kind of damage Java vulnerabilities can cause if used in drive by exploits or in exploit packs. We believe that revealing technical vulnerability details in the form of a detailed  technical analysis before the patch is dangerous, and releasing working exploits before the patch is vain and irresponsible.

The Oracle patch cycle is 4 months (middle of February, June, October) with bugfixes 2 months after the patch. The next patch day is October 16 - almost two months away. Oracle almost never issue out-of-cycle patches but hopefully they will do consider it serious enough to do it this time.

We have been in contact with Michael Schierl,  the Java expert who discovered a number of Java vulnerabilities, including recent the Java Rhino CVE-2011-3544 / ZDI-11-305 and  CVE-2012-1723. We asked him to have a look at this last exploit . Michael sent his detailed analysis, which we will publish in the nearest future and a patch , which we offer on a per request basis today.

 The reason for  limited release is the fact that this patch can be reversed, thus making the job of exploit creation easier, which certainly is not our goal.
Update Aug.29
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.

Atif Mushtaq from FireEye covered the payload part of the exploit, which is helpful and something to look out for if you are protecting your network or your customers. We should note that attackers are not limited to .net addresses and already used other domains and  IP addresses.

The malicious executable name varies and it the future may get replaced by any kind of payload. At this point, it appears to be Poison Ivy RAT variant that is likely to be detected by many antivirus vendors.

More about Poison Ivy
Alienvault Nmap Script to detect Poison Ivy Clients
Will Brown: Detecting Poison Ivy 

Details about the exploited vulnerability, mitigation factors and tips.

1. The javascript in index.html is heavily obfuscated.
2. This vulnerability affects Java 7 (1.7) Update 0 to 6. Does NOT affect Java 6 and below.
3. It works in all common browsers versions of Internet Explorer, Firefox, and Opera. Does NOT work in Chrome. (Update: The original exploit we tested did not affect Chrome. We did not test Metasploit but reports are that their module works for all browsers. Disable java support in your browser)
3. It does not crash browsers (which does NOT mean it does not work!), the landing page looks like a blank page (for the original exploit only. Future variants may be different), sometimes one may see a flash of a rotating Java logo and the word "Loading"

5. The malicious Java applet is downloaded like you see on the picture below. At this point, if your system is not vulnerable or is patched, the attack stops. From the user perspective, it is impossible to tell if the attack was successful or not.
6. If the exploit is successful,  it downloads and executes a malicious binary, which calls to another IP address/domain  hello.icon.pk / 223.25.233.244

img.1

7. Although older Java is not vulnerable to this attack, downgrading is not recommended due to many other vulnerabilities in the  older versions of Java.
8. Disable Java in your browser, apply the patch (see below), or use Chrome.

Malware behavior and indicators
Payload: : hi.exe  Size: 16896
MD5:  4A55BF1448262BF71707EEF7FC168F7D (Virustotal 26/42)

1. Legitimate Portable Media Serial Number Service MsPMSNSv.dll is deleted from C\WINDOWS\system32 (Virustotal 0/42)
2. Malicious mspmsnsv.dll is copied to C\WINDOWS\system32 (Virustotal 21/42)
3.  "Portable Media Serial Number Service"  (WmdmPmSN in the registry)  is running.

Update Aug 30, 2012 
The vulnerability has been patched today. Please see the note on the top of the post.

Patch Readme:

Java 7 Zero Day Buster
by Michael 'mihi' Schierl, <schierlm at gmx.de>, http://schierlm.users.sourceforge.net/
To use, locate the (jre/)lib/security folder in your JDK/JRE (there should be a
file called cacerts in it), create a folder (jre/)lib/endorsed next to it and
place this Jar inside it.

The Java VM will load all Jar files in this folder and replace any of its own runtime classes (from rt.jar) by .class files inside of these Jars. Note that this feature is not officially supported by Sun/Oracle except for updating XML parser libraries, but it seems to work.

Use this Jar only for Java 7 Update 0 to 6, as other versions may have a different version of the patched class and break horribly. The patch seems to properly block the access vector used by the 0-day circulating at the moment, but I take no responsibility that it fixes all ways this bug can be exploited, nor that it will not break any other existing Java programs.

In other words, create a folder under lib in your Java 7 program folder, name it endorsed, copy the patch jar in it and restart the browser(s).

We tested and it works well  - the applet gets downloaded but does not lead to download and execution of the malicious binary. See the pictures below and compare with the download sequence during the successful exploit (img 1.)

 Interim patch results  

Patched Java 7 with Internet Explorer. No malicious exe download.

Patched Java 7 with Firefox. No malicious exe download.

Java permission request on Chrome

 

Win XP sshot. No malicious exe download on Chrome (tested on XP and Windows 7)

Rapid7 / Metasploit indicate that they tested their module on Chrome on Windows XP. In our experience, if Java is allowed to run like you see on the picture above, the malicious binary does not get downloaded. We tested several times with the same results - Java runs but no contact with the second server and binary download. Testing on the same VM with Internet Explorer or Firefox immediately causes infection. Don't know, maybe Rapid 7 'improved' the exploit and you can send them your thanks if you wish,  but the original exploit does not work on Chrome.

Requesting the patch:

This is not an official patch and had limited testing. In general, it is best to disable Java in your browser or use Chrome.
 If you are in the environment where you must have Java with Internet Explorer, Firefox and Opera, email us at admin <at> deependresearch.org  from your company address with a brief explanation of the planned use and we will send you the download link.

If you are in the exploit making business,'whitehat' or not, please do not bother.
If you are a home user and/or do not need  use it to protect users, customers, and networks, please use the workarounds.

Feel free to contact Oracle and ask them about their patch cycles. You can also contact Rapid 7 and ask if they ever heard of  "Social responsibility" .

We want to thank Michael 'mihi' Schierl for his analysis and patch development and anonymous for the sample donation.

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.


Continue to Part II  Java 7 0-Day vulnerability analysis 

Andre' M. DiMino and Mila Parkour

Yara Signature Exchange Google Group

Yara-Exchange Google Group (by invitation only)
https://groups.google.com/d/forum/yaraexchange



Please read the Yara Exchange Group rules below and if you are interested, request an invitation by sending an email from your organization's email account to to Yara at deependresearch.org (currently moderated by Andre' M. DiMino)

Please provide the following information:

• Your First & Last Name (may not be a third party contact)
• Your Organization and Address
• Contact information for verification.
  
  Once your membership is confirmed we will need your
• Gmail Email address in order to join Google group. 
• Github ID (create at Github.com if you don't have) 
• Virustotal.com ID (create at virustotal.com if you don't have) - optional but recommended

You can send this information in the initial application email.

In short, we need name, work and Gmail email addresses, organization, and full contact info (City, Country). The requirement to use your work email for the initial request is mandated by the fact that not all indicators can be publicly shared.

By registration, you agree that your group access will be used only by the person registered. No other distribution or public disclosure of this group's signatures is permitted.  Although signatures shared will not be posted in public, please make sure that all information you send to this group comes from your own research, open sources, or you have permission (from other groups / researchers or your employer) to share it with the group.

We are planning to have both crimeware and APT yara signatures. We can create an upload/malware hosting if necessary.


Read more about Yara here
http://code.google.com/p/yara-project/
and a good explanation is here by Lenny Zeltser 


Yara Exchange Group Rules

1. DeepEnd Research is an all volunteer, non-commercial organization that derives no financial benefit from Yara signatures or anything else developed by the group. Our goal is to build a community of researchers with a mutual interest in developing, improving, and sharing Yara signatures.

2. It's expected and required that everyone will contribute to the list. "Yara Exchange" isn't there to just pull signatures or watch the conversations and not contribute anything back. While some initial silence is understood until our momentum builds, extended lack of participation won't be accepted.
Contributing to the list can come in many forms including new signatures, improvements on existing signatures, tool integration using yara, analysis and classification techniques using yara, etc. If you cannot share any signatures you develop or do not use yara often enough to contribute, please do not apply. 

3. Inactive members, or those that don't tangibly contribute to the signature development or sharing will be pinged to check on their status and removed after 3 months.

4. A group roster will be distributed to group members on a regular basis. We believe that the roster will let us have more trust in each other, and a better understanding of who you are sharing your signatures with. The roster will consist of the list members and their organizations (Google group nick+real name+org/company). No email addresses , titles, or other personal information will be included. DeepEnd Research will never use your information for reasons not specified above.

5
a. Group access is granted only to the person registered. If you have colleagues and friends that you feel will be a good part of this group, have them request their own access.

b. No sharing, distribution, or public disclosure of this group's signatures, analysis, or work product outside of the member's organization or "Yara Exchange" is permitted. Additionally, no signatures, analysis, or work product from "Yara Exchange" can be used commercially, or for other financial benefit, either directly or indirectly.
Usage explanation and examples:
-You can use yara signatures produced by the group for operations at your company / organization  and/or for incident response at your user / client / customer site.
-You may not incorporate signatures shared by group members into any products / appliances / subscriptions / reports you sell or publications you produce.
-You maintain ownership of signatures you create and submit to the group and you can use / sell them in any way  you wish.
If there are any questions or uncertainties about external use of "Yara Exchange" information, please ask!

c. Please ensure that all information you share with "Yara Exchange" comes from your own research, open sources, or with permission.

We hope these rules will prevent group stagnation and taking advantage of a few active participants by many idle members and companies. We look forward to working with you and hope this group develops and thrives.