November 26, 2013
Holy Java, not holey Java.
Woo-hoo! One more torpedo released by the cyber-delinquents against Microsoft Office has been thwarted by our cunningly tenacious cyber-protection.
Recently a new but fairly common-or-garden attack was discovered: When opening Word documents malicious code was unnoticeably injected into the computer. This wouldn’t have made it into the headlines but for one circumstance: this was a zero-day attack, i.e., one that used a previously unknown vulnerability in MS Office for which there weren’t any remedying patches, and which most antiviruses let slip through their nets. You guessed it – our AV grabbed it with its tightly thatched net in one fell swoop!
What happened was our Automatic Exploit Prevention (AEP) technology detected anomalous behavior and proactively blocked the corresponding attacks. No updates, no waiting, no messing. Zapped immediately.
Zero-days represent a real serious threat these days.
They need to be tackled head on with full force. However, many AVs are fairly useless against the future risk zero-days pose, as they work based mostly on signatures, with ‘protection from future threats’ only ‘provided’ on paper/the box (albeit very pretty paper/a very glossy box:). But of course! After all, genuine – effective! – protection from future threats requires whopping doses of both brain power and development resources. Not every vendor has the former, while even if a vendor has the latter – that doesn’t always clinch it. And this is sooooo not copyable tech we’re talking here…
Unlike what Buddha and new-agers say is a good idea for individuals, we’ve always believed that in IT security you can’t live for today – in the moment. IT Security needs to constantly look to the future and foresee what will be going on in the minds of the cyber-felons – before events occur. A bit like in Minority Report. That’s why ‘proactive’ was on our agenda as far back as the early 90s – back then we cut a dash from the rest of the IT Sec crowd by, among other things, developing heuristics and our emulator. Forward thinking runs in KL blood!
Since then the tech was reinvented, fine-tuned and souped-up, and then around two and a half years ago all the features for protection from exploitation of known and unknown vulnerabilities were all brought together under the umbrella of AEP. And just in time too. For with its help we’ve been able to proactively uncover a whole hodge-podge of targeted attacks, including Red October, MiniDuke and Icefog.
Then came a sudden surge of unhealthy interest in Oracle’s Java, but AEP was ready once again: it did its stuff in combatting all the unhealthiness. Leading AEP into battle was its Java2SW module – specially designed for detecting attacks via Java.
And it’s this module I’ll be telling you about here in the rest of this post.
The software landscape inside a typical computer is a bit like a very old patchwork quilt: loads of patches and as many holes! Vulnerabilities are regularly found in software (and the more popular the product, the more are found and more frequently) and the companies that make the software need to secure them by releasing patches…
…But No. 1: Software developers don’t release patches straight away; some sit on their hands for months!
But No. 2: Most users forget, or simply don’t care, about installing patches, and continue to work with holey software.
However No. 1: The vast majority of computers in the world have antivirus software installed!
So what’s to be done? Simple: Get Java2SW onto the stage. Why? Because it kills two birds with one stone in the Java domain.
Overall, from the standpoint of security Java architecture is rather advanced. Each program is executed in an isolated environment (JVM – Java Virtual Machine), under the supervision of a Security Manager. However, alas, Java became the victim of its own popularity – no matter how well protected the system was, soon enough (in direct proportion to its popularity) vulnerabilities were found. Vulnerabilities are always found sooner or later, and every software vendor needs to be prepared for that, in particular (i) by timely developing protective technologies, (ii) by being real quick in terms of reaction times, and (iii) by informing users how important updating with patches is.
Thing is, with regard to Java, Oracle didn’t make a great job of the just-mentioned prep. In fact they did such shoddy job of it that users en masse started to delete Java from their browsers – no matter how more cumbersome it made opening certain websites.
Judge for yourself: The number of vulnerabilities found in Java in 2010 – 52; in 2011 – 59; in 2012 – 60; in 2013 – 180 (and the year isn’t over yet)! While the number of attacks via vulnerabilities in Java grew in a similarly worrisome way: