Blocking Java Exploits, Malicious Signed Applets, and 0days
Wednesday, February 27, 2013 at 10:42AM 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:
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.
java