Sophos Cloud Optix
Irrepressible cybercrime investigator and reporter Brian Krebs has written about yet another Java zero-day exploit.
This one, it seems, targets an exploitable vulnerability even in Oracle’s most recent release, Version 7 Update 11, also known as 7u11.
Details of the exploit are sketchy, because the underworld is playing this one very close to its chest.
According to the Krebmeister, the broker who had the exploit up for sale planned to sell it to just two different buyers, rather than leasing it or offering it up widely:
The idea of limiting distribution is obvious: the fewer exploit-delivery sites that actually serve up the exploit, the longer it will take to become widely known, and the longer it is likely to last before being acquired, dissected and patched.
The disadvantage to the criminal who’s brokering the sale, of course, is that he’s limiting his market, though by trusting two fellow-crooks he runs double the risk that his prized possession will get sold on anyway.
It looks as though a second buyer came out of the woodwork, because Krebs reports that the sales pitch subsequently vanished from the underground forum on which it was originally published.
The value the seller is placing on this exploit sounds a bit low to me: he’s expecting total earnings of just $10,000 for a reliable, working and current Java zero-day. (I don’t mean to sound as though I think cybercriminality is glib and workaday. I’d simply have thought that he could have asked and got more.)
There are many possible reasons for that value, not least that I’m ill-informed about competitive pricing in the underground, and two interesting ones spring to mind:
- There isn’t a new exploit. Or it’s not a very good one. It’s just a wind-up.
- The widespread news coverage recommending that you turn off Java is pushing down the price.
Let’s hope that the reason is the latter.
In his excellent new technical paper on the Blackhole Exploit Kit, SophosLabs researcher Gabor Szappanos published an exploit success report from a live Blackhole server:
Szappi wondered if there was some factor in the exploit kit itself that favoured Java as a vector.
Perhaps, for example, on a PC vulnerable to multiple exploits, the Java one might trigger fastest, and thus be over-represented in the reports?
Perhaps a bias in the exploit pack code meant that other exploits were tried less often, thus giving Java an unfairly large bite at the cherry?
But that was not the case. To quote Szappi himself:
After evaluating the code it turned out that [there was no bias]. The Blackhole exploit kit is fair with the individual exploit functions and doesn't favour any single one of them... So I was left with the only remaining explanation: Java security fixes are not being installed. Users don't consider Java a direct threat, and don't rush into updating their systems.
And that is the number one security challenge regarding web threats: making users aware that Java is right now the weakest spot. And it is heavily under attack.
The silver lining is that he wrote those words back in December 2012, before the latest outbreak of “turn Java off advice.
Let’s hope that advice pays off.
By all means install Java. (I have it for Android research and development, for instance.) But keep it up-to-date, like any other software package.
By all means turn on Java in your browser, if that is your informed choice. (I have it locked out of my browsers as I simply don’t use any sites that require it.) But don’t enable it unless you actually need it.
I’m not picking on Oracle or on Java here.
This advice holds for any software or browser plugin you don’t need.
Getting rid of functionality you are not using has the trendy name of “reducing your attack surface area”, and it really works.
I have quoted Mr Miagi, from the movie The Karate Kid, before, and I have no doubt I’ll quote him again: “Best way to avoid punch – no be there.”
The various contributors to this blog are alienating a significant proportion of their readership with these endless & tedious pleas to 'remove or disable Java unless you really need it'. Perhaps you're simply trying to get the word out to home & small business users. However, I bet a good number of your readers support and try to secure enterprise environments…and these hackneyed pleas are just not helpful.
I suspect like many enterprise environments, as much as we'd like to, we cannot just get rid of Java or disable it. Our enterprise-wide training platform used by every employee at some point simply will not work without a java-enabled browser. In addition, numerous employees use multiple banking sites all of which require java.
What this readership needs is practical and effective suggestions to mitigate these endless java vulnerabilities….not bland recommendations to 'just remove or disable it'
Come on guys…give us some help here!
I hear you. I sympathise.
But we're not instructing everyone to cut Java dead. We're saying (quite explicitly in this article 🙂 that you shouldn't have it in your browser _unless you know you need it_, and if you do have it, you need to be zealous about keeping it up to date. It shouldn't be in your second tier of update importance. It should be up there with the OS and your browser. (See the Blackhole stats for why!)
And if you need Java internally only, surely there's another way to cut the cake?
What about packaging your training app as an application that your users install rather than run in their browser? What about a pre-packaged browser-plus-Java bundle that is preconfigured just for the training? What about letting applets load from inside but not outside the network (our Web Appliance can do this at a click, for example)? What about a Citrix/NX type solution? What about modernising the training to use JavaScript and HTML5? What about using an endpoint firewall to regulate where applets come from and can connect to? All of these can be centrally managed and deployed.
(As for banking apps…I don't know of any that still use Java, as it's a needless complexity for them, but if they exist, perhaps you could allowlist the banking sites at your gateway and block the rest? Again, products like our Web Appliance can do this.)
I think there are two sides to this story, and two sides to the problem.
Perhaps we are being a bit gung-ho in saying, "Just turn off Java" and expecting organisations to find it easy to do so.
But this whole "legacy trend" in the corporate world – the inertia that gave IE 6 years more life than it should have had; the conservatism that leaves patches for weeks or even months in the modern era – is just the same problem from the other end of the spectrum.
Problem is, the gung-ho approach _in this case at least_ improves security, the "we need to be careful about change" actually reduces it.
I'm all for resisting change when it isn't needed. (I have a server at home that is more than a decade old, and it was surplus to company requirements when I acquired it. It is patched, though 🙂
But I think we need to ensure we are willing and able to move forward when staying put is causing problems.
Apologies that this doesn't solve your issue.
But if you really need Java and you have updated it and you have other layers of security protection, you can probably stand down from blue alert. Just so long as you don't have Java in your browsers without even realising it…
I also work for a Fortune 100 company.. I turned Java off. Three hours later I was due to host a web conference using a well-known industrial-strength, secure screen/app sharing product–which wouldn't run. Fortunately I had signed in early and had time to re-enable Java plug-ins. During the day I also encountered a corporate-wide traiining module (business conduct certification) that 100% of employees must complete, also requiring a Java plugin.
Paul, you are pointing your finger in the wrong direction. Java was sold as being "inherently safe." Everything "runs in a sandbox." Well, we were sold a bill of goods. Somehow the design drifted from that model to a model which grants access to vulnerable spaces fue to feature creep. Why don't you help start a movement to get Oracle to chop added function that permits these intrusions instead of suggesting the users cower in fear?
Hi Tim,
If you only need Java for websites that are hosted internally, as Paul suggested, blocking .jar & .class files on your perimeter proxies could be a quick mitigation. For this to be effective you'll probably want to consider what you're doing with https traffic – it's obviously harder to filter. For a quick win, even if you are just filtering http traffic you are still mitigating the risk somewhat as most attacks are (currently) delivered over plain http.
Likewise Paul's suggestion regarding client firewall control definitely has mileage – blocking java.exe & javaw.exe from speaking to untrusted hosts will thwart many attacks.
You might also have some luck with Internet Explorer "zones". Annoyingly I've yet to discover a way to disable Java entirely in the Internet Zone but allow it in the intranet Zone, although there are a few java-related options that will at least reduce your attack surface.
But vendor pressure is the only long-term option. Java in the browser is clearly dead IMO and vendors need to keep up.
Lastly, my article on threat response @ http://nakedsecurity.sophos.com/2012/10/09/it-dep… , although a bit more general might also be of interest.
-ross
Thanks for the responses guys…
I did not mention that we have no internal application dependencies on Java – only external vendors who provide these e-learning & banking services. We have asked these vendors and none have any plans to migrate from Java in the forseeable future
I will give some thought to whitelisting jar & class files on our proxies together with the other suggestions…
cheers!
For some people java is falsely saying it's up to date.
jupdate.exe checked and said I have latest installed, then when downloaded java update on chrome I got new version, but only when I downloaded standalone package my c:program filesjavajre7 folder was updated (it was dated to somewhere in 2011 before)
What I'm saying is that Javas update tells people they are secure, even if they aren't.
I've found this too. Manual update from java.com was the only sure way of being at the current version. Sadly needed it for a remote work connection.
Maybe the low end distribution of this exploit is in part to the U.S. governments involvement with the latest Java vulnerability or the large media coverage it was given. This brings up another question. Why was this Java exploit so high on the U.S. threat spectrum? The only reason the media grabbed hold and ran with the story was because CERT and DHS basically said don't use Java. Meanwhile Microsoft had an IE vulnerability that required an out of band patch this month, but there was no government warning or media coverage of this. I commend Sophos and other security firms for their commitment to fight cybercrime but maybe governments should be more involved in alerting and recommending actions when any vulnerability is found if this in fact the result.
Two days ago, Rob Vandenbrink posted an excellent blog to the SANS Internet Storm Center here:
https://isc.sans.edu/diary/When+Disabling+IE6+%28or+Java%2C+or+whatever%29+is+not+an+Option…/14947
I also find many people suggesting EMET (Microsoft’s Enhanced Mitigation Experience Toolkit) as being very useful in reducing risk from a variety of malware techniques. I heartily agree.
But unfortunately there’s no silver bullet for any of this, though a good balance of technical defense-in-depth and the fostering of a responsible culture via well-written policies, user-training and willingness to act on transgressions of acceptable computer use will go a long way. Finally you need a level of monitoring and a mitigation plan for when there is a data breach. There are no simple check boxes for any of that; Security-as-a-process (is that a Bruce Schneierism?) is the only road for getting there.
I would recommend starting off with a basic risk assessment though. Do you know what are you trying to protect? Probably data, not the computers or programs themselves. Do you have Personally Identifiable Information you need to protect? Is it critical that your proprietary data is not leaked or stolen, or are you more worried about general malware using your computers nefariously and messing with productivity? Where is your critical data? How does it move around (and in and out of) your environment? What risky behaviors are going on?
Then pick solutions that mitigate the worst threats at a cost that makes sense for the business. It’s a no-brainer that spending more money on a fix than the initial risk was ever likely to cost is probably a bad business decision, but us technologists do need to remind ourselves of that from time to time!