Blocking Java Exploits, Malicious Signed Applets, and 0days

The following has been a concept for me for a long time and recently I tweeted the idea which really put me under the fire to prove it. (re: justanidea hashtag)

 And a few people came up with some very valid points:

1) Doesn't work so well with HTTPS sites

He's right, but that forces the attack to use SSL, and doing so can yield the defender more information about the attacker, and offer other avenues of defense.

2) Cant an attack just spoof the user-agent?

and a response:

But in actuality that setting is applied inside the Java code, which needs to be requested by Java first. Using it's User-Agent string. There are probably ways to get this done with Java script or other methods of loading the Java classes/jars but I haven't been able to find any.

and finally 3) Whitelisting is a myth!

Which goes along with phoobar's responses as well:

Yes, there will definitely be challenge when implementing blocking java user agents, and one of the biggest pit falls is that there is no clear indicators to a user that that's the reason for the block. There are ways to make it more evident with custom proxy error pages, but it is a thorn in this solution.

On to the walking of the walk. Oddly enough there is little to no documentation on blocking or even detecting outbound user-agent strings. But I did happen across an excellent post about how to use Squid to block IE (which I'm all for! ;-):

http://gaugusch.at/squid.shtml

The following is just my testing of his walk-through converted to be used to block java:

I used pfSense for my testing since it's very easy to set up and already has Squid as a package:

You get the point.

We set up the latest Java 0day in Metasploit:

Get the user to go to our malicious web site:

And the user doesn't see anything. This can be modified in the module. You also see that I was using "Intranet" IP space so some IE settings were lower, but nothing that would effect this exploit.

And shell! I want to pull your attention to that YWpdDan.jar request though. That request actually is done by Java with the following user-agent:

"Mozilla/4.0 (Windows XP 5.1) Java/1.7.0_09"

Alright, so the exploit works, but how about the solution? In pfSense you have the ability to slam "Custom Options" into the bottom of pfSense's Squid config page. Like so:

There is probably a better regex for selecting only Java user-agents, but this worked for now, and I don't think any browsers actually use "Java" in their user-agents. (UPDATE: Searching for "site:useragentstring.com java" on google only yielded Java, and YACYBOT, which is built on java as using the string "Java" in their agents)

You can also notice that I've whitelisted webex.com and java.com sites and subdomains so that my "users" won't get blocked using the tools on those sites. This could be pretty hefty with (as phoobar said) a Java dev group. But after the initial push and getting a semi "required" list of external approved sites this list shouldn't need much upgrading, even for large organizations.

Save the config and let's see how this works out:

Ok, but did the attacker still get a shell?

Nope! Win!

Just to prove that HTTPS isn't fixed here lets set those options up in Metasploit and kick the same exploit:

And after an error about a self-signed cert (notice the SSLCert option in Metasploit that has the ability to solve that as well) we get the expected result:

And subsequent shell without any indication in Squid's proxy logs of a Java user-agent:

That's it, sort of a long post but hopefully something that people can use. Thanks!

UPDATE: I'm not exactly certain how this affects Java "Web Start" weblet exploits if at all.

EXE::Custom in Metasploit's Java Exploits

Let me say first off that this isn't the most elegant of ways to accomplish it. It is in the "it works for me" stage.

A quick primer on EXE::Custom: This is a setting just like RHOST in Metasploit wherever an EXE is built for Windows payloads. Such as PSEXEC, BypassUAC, etc. It tells Metasploit to ignore all of your payload settings and just use the EXE you have specified. Now this does come at a bit of a cost. If you don't have a handler set up to catch whatever is in your EXE and you have bogus information in your payload settings for your module, Metasploit won't be able to magically determine what you want it to do. So make sure that you either have the payload settings correct (even though it won't use them for the exploit) or set the option "DisablePayloadHandler" to true and start your own handler somewhere else.

With that said, the Java Signed Applet attack is one of the most widely used, one problem in the Metasploit module version is that you have no external control (such as EXE::Custom) for the binary that is dropped if you are using a Windows native payload. (I do highly recommend trying out Java Meterpreter, but that it for another post)

Here is the hack that gets me by until a more elegant solution is thought up by smarter people than I:

We are going to use the Java Rhino exploit, and this story starts with an undetectable.exe sitting in /tmp/ - How you bypass the AV you are up against is up to you. The first thing we need to do is make a core library change. Yes, this is as scary as it sounds and you should document any time you do so you can revert as needed.

In your MSF directory open up lib/msf/util/exe.rb - should look something like this:

Scroll down or search for "self.to_jar" - should look something like this:

Now add "exe = File.read('/path/to/your/evil.exe') as demonstrated below:

Cool. We've made our change, now we have to pull down a jar generated with our evil bin, and the Rhino exploit. We can do that by spinning up Metasploit with our newly editing core library. Load up the Rhino exploit via "use exploit/multi/browser/java_rhino".

One trip up that I messed up even just creating this blog post (and a constant headache in the #Metasploit channel on Freenode) is forgetting to set the TARGET variable in Java exploits. The default payload type being Java. Since we are using a native windows binary we need to specify Windows by setting TARGET 1.

Run the exploit with any settings, since we'll be just pulling out what we need. Then pull down the exploit JAR file with wget:

(Most java exploits are set to answer ANY .jar extension request with the payload.)

The HTML to load the JAR is pretty straight forward, but if you've never seen it before here it is:

Thats it. A very blank page with an exploit in it. We can do better than that:

Obviously you can do whatever you want with the HTML, mirror a site or what have you. Notice that I've also changed the name of the JAR. (You can't change the class unless you start making changes to the exploit directly and I wanted to keep this as generically applicable as possible)

Move the Applet.jar to SuperMario.jar and start up a Web server (for demo using Python's awesome SimpleHTTPServer, but apache will serve as well)

Don't forget to start up a handler for our now-external exploit:

Victim views the site:

And WA-LA! we haz shell:

Yay… Game over..