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:

So what’s so great about Java2SW and how does it prevent attacks on vulnerabilities in Java?

Well, in addition to the default Security Agent, it adds to every Java virtual machine one more element of security. It conducts extra, independent analysis of the Java code and stops it from running in case it discovers any suspicious activity.

This is particularly tricky to pull off because we need to get direct access to the Java platform, and not just ‘envelop’ it. Why? Because from the outside Java is fairly opaque – something happens inside it but it’s not clear why. For example, Java may launch this or that process, but what for is a mystery! But by taking a look inside it’s possible to find out what code is being executed on the Java machine, what permissions it has, what the source is, and so on, and on the basis of what we find we can draw our conclusions.

Thanks to its architecture Java provides good cross-platform coverage (Java applications without modification can work on virtually any operating system). But with such flexibility comes a need for masses of grey cells to be able to develop protection – since you need direct access to the heart of the Java platform, and heart surgery is never straightforward. It goes without saying that by far not in every AV is ‘intelligent heart surgery’ available; meanwhile, our tech is getting the job done already – and is in line for a patent at the mo too.

Another great thing about Java2SW is how it works jointly with other subsystems of protection against vulnerabilities (AEP).

Upon finding suspicious activity the module sends info thereon to System Watcher – the component that collects signals from other antivirus sensors, sees the whole picture, and takes optimal informed (accurate) actions to thwart even the most sophisticated attacks.

Thus, even if Java’s Security Manager is compromised in an attack (and oh, how the cyberscum like attacking Security Manager) – no matter! We can still detect and block the attack.

So, is Java2SW a panacea against unknown Java vulnerabilities?

Here it’s important to remember one thing: Java2SW doesn’t detect zero-days and doesn’t uncover vulnerabilities. That’s not within its remit. Actually, strange as it may seem, its effectiveness only benefits from such a fact. Java2SW exposes exploits – anomalous code behavior; where those exploits strike is of no concern to it. It doesn’t prevent the holes in the above-mentioned ancient patchwork quilt, it just stops attacks via them. Thus, we don’t go after particular vulnerabilities, but instead protect users with a more universal approach.

The result?

First, with a high degree of success we can protect users from unknown attacks via vulnerabilities in Java. In other words, add a margin of safety to the time between the discovery of vulnerabilities and when a patch becomes available.

Second, even if a user belongs to the category of ignorers and doesn’t install patches in good time, we still save him/her from such attacks, regardless.

And on that positive note, I’ll be off. But not for long…