Java 7 0-Day vulnerability information and mitigation.

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 CWINDOWSsystem32 (Virustotal 0/42)
    2. Malicious mspmsnsv.dll is copied to CWINDOWSsystem32 (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 JD
    K/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 

    Share this post

    Share on facebook
    Share on linkedin
    Share on print
    Share on email

    Subscribe to our Monthly Cyber Security Digest

    Get monthly content to keep you up to date on the latest news and tips