Monday, August 27, 2012

Java 7 0-Day vulnerability information and mitigation.

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 /
    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>,
    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>  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.


    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 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 


    1. Great work!

      there's an error from google's daemon-mailer when trying to email you (dmin

      "We're writing to let you know that the group you tried to contact (admin) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:"

      1. It works now, sorry permissions were too restrictive. It will go to Mila and Andre'.

    2. Rapid7 is working with the msf metasploit regarding to the current exploit reproduction using the PoC code and found Google Chrome can be affected.Below is the URL:

      Please kindly confirm it, may thinks for the great report.
      - @unixfreaxjp -

      1. In additional, Eric Romang made video of the current 0day exploit w/msf which can be reproduce at Chrome too, here's the link:

        So the PoC is in msf module now, and if Oracle is not releasing urgent patch on this, no doubt it will be a mass exploitation threat for malware infection, like previous Java zerodays - @unixfreaxjp -

      2. mistype: many *thanks* for the great report

    3. 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.

      1. I see, so the original exploit is not affected to Chrome, thank you for the kindly explain.

    4. Any chance to get some additional info on this? Would love to create a Snort sig that could catch this on the wire.

    5. Hello,

      The Metasploit module uses the standard "loader" chain that all Java exploits in the framework leverage. This provides both java and native payload support through a target setting in the module. This doesn't require a secondary download and indeed works on Chrome. Metasploit has *always* provided working exploits, regardless of patch level, when the vulnerability is already public and being exploited in the wild. This goes back to 2003. Our responsibility is to provide safe security tools for our users to conduct security testing and validate their defenses. You don't have to agree with this, but at least we are consistent.


      1. Yes, there were a few high profile exploits recently that were posted after the patches, I was hoping it is not a coincidence but a new trend. My mistake.

    6. Am I safe if I am running IcedTea Java on Linux/Chrome?

    7. I couldn't agree more with HD Moore. Metasploit community believe in responsible disclosure but when the cat is already out of the bag with no offcial patch security professionals require the tools to reliably test their defences to determine threat and risk level. I personally think that developing a patch and limiting its release is not fitting of the wikipedia definition of social responsibility:
      "Social responsibility is an ethical ideology or theory that an entity, be it an organization or individual, has an obligation to act to benefit society at large.". Did you read that? Limiting patches to only organisatons is actually lacking social responsibility by your own definition.

      1. Metasploit folks produce needed and useful tools. However, we still believe the public exploits should be released after patching not before. We saw in the past what damage 0day exploits can do when they are prepackaged for easy consumption by every criminal scumbag.

        It was a pipe leak, now it is a broken down water dam and we all watch the city flood. We are not moralizing but believe that this could have waited. You can disagree if you wish. We just ask for no flaming wars here, they do their thing, we do ours.

        Regarding the patch:
        We are just being cautious. We are afraid that posting the patch openly - with 3 billion end users will be irresponsible as we are not an authorized java distributor and did not test it on every system out there.
        What if it breaks a million systems? We cannot provide support for end users and hope IT administrators of companies can test in their environment and make educated decisions. That said, if you are an end user and really desperate, you can email and we see.

    8. It would seem like downgrading to JRE 6 (1.6) is a possibility since 6 is still supported and security fixes are still released in 6 and 7.

    9. Is anyone close to getting a Snort sig for this issue developed?

      1. I think need 2 sigs - original and metasploit's as they are somewhat different.

    10. alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET CURRENT_EVENTS JavaScript Obfuscation Using Dadong JSXX Script"; flow:established,to_client; content:"Encrypt By Dadong|27|s JS"; reference:cve,2012-0003; classtype:attempted-user; sid:2014155; rev:4;)

      From the ET group...haven't seen one for metasploits yet.

    11. nuked the fact that there are two spaces between Encrypt and By.

    12. Heh...I get a:

      16-bit MS-DOS Subsystem

      error when I attempt the metasploit exploit...tested on IO 8 Windows XP

    13. Demo video exploiting the vulnerability using Chrome on Windows 7:

    14. Nice work. Stale Java is dangerous, but even fresh Java is dangerous and can produce a nasty scald. Let's hear it for attack surface reduction, although it creates extra work. Surely mass compromises are underway now by Black Hole encounters. :(

    15. Thanks for this knowledge. I think I need to watch its video. Hey, can I run this on my 32 bit windows XP?

    16. Oracle has reacted with an emergency patch found here
      acording to this will fix the bug and close the hole.

      (I Hope it will)

    17. ... but 7u7 still doesn't "officially" fix the issue. Do it?.

    18. I'm afraid your're wrong, Mila.
      Maybe that's why Oracle didn't "officially" fix the issue on 31/8.

      1. I know. - the bottom of the release note claimed it did. Whether it fixed well or not, it is a different topic now.

    19. I see. Many thanks.

    20. thanks for all the information ,it was very helpful i really like that you are providing information on core and advance java ,being enrolled in
      advance and core java
      i was looking for such information on advance and core java and your information helped me a lot. I really like that you are providing such information

    21. Thanks a lot for sharing this amazing knowledge with us. This site is fantastic. I always find great knowledge from it.