Spilling the beans

Increasingly sophisticated hackers going for Java

Lucy Carey

Why are exploits in Java becoming more common, even as layer permeability decreases?

Java Applets’ porous security is an openly acknowledged issue – and as hackers continue to upgrade their skills from common garden variety hacking to criminal mastermind level, the issue is only getting more complex. Up until recently, the ratio of Java layer vulnerabilities to Java native level vulnerabilities was three-to-one – but as of 2013, this is no longer the case. The recent disclosure by security researchers of two Java native level exploits (CVE-2013-2465 and CVE-2013-2471) only serves to underline this growing threat.

Trend Micro also highlighted the troubling issue, blogging that criminal groups have been targeting Java native layer vulnerabilities to infiltrate businesses and government systems, compounding the issue with increasingly complex attacks.

According to Threats Analyst Jack Tang, the move is a potent indicator of the growing sophistication of the cyber criminal fraternity. As Java’s permeability has become more widely publicised, the number of attacks has also increased, forcing Oracle to release several out of cycle security updates this year alone. Uptake of these patches isn’t necessarily immediate however, leaving clients open to a growing cartel of nefarious coders.

And it’s not just the increasing frequency of Java native layer attacks that is becoming an issue. The nature of this exploit means that, once a system has been accessed, the attacker then has a considerable array of options available for tinkering.

According to Tang, once the native layer is infiltrated, an attacker can then, “use the array object to get or set the following buffer precisely. They can tamper with the following JavaBeans. Statement object’s acc field, which points to a AccessControlContext object. In general, the acc field will be tampered to point to a full permission AccessControlContext object. This will let arbitrary code be run on the affected system.”

Native level hacks are similar to Java layer attacks, which exploit vulnerabilities in the Java layer runtime, bypassing the Security Manager and call high privilege functions. However, to infiltrate the native layer, an attacker also needs to circumvent OS-level protections like ASLR and DEP – something that calls for a great deal of skill, and some exceptional coding nous.

So what’s behind this new generation of apparently super genius hackers? A large part of the blame can be apportioned to the Java native layer itself, which proved exceptionally open to tampering. In the June 2013 Java SE Critical Patch Update Advisory, approximately half of all the vulnerabilities fixed were in the Java native layer code- a considerable shift from previous years.

Hackers have also evolved, and whilst there has always been some degree of vulnerability in the Java native layer, this is the first time that there has been a real cartel of malicious coders with the capacity to exploit it. That’s not to say that the threat to the native layer didn’t exist before- but this is the first time anyone has managed to really crack it, and now that knowledge is out there, it hasn’t taken long for those in the know to work out ways to exploit it. The particularly structurally weak native layer in Java 7 has only served to create a perfect storm for hackers.

To ensure the best possible protection, Java users have been urged to upgrade to the latest incarnations of the program as a matter of urgency- though this is easier said than done when using another system that comes bundled with older versions of the software. Other analysts are recommending uninstalling Java Aplets altogether- a simple solution for many people, although less helpful for companies with legacy applications. For businesses using ageing systems with enterprise-critical applications, updating may not even feasible.  Although there are ways around this, ultimately, as Wolfgang Kandek, CTO of security firm Qualys, writes, such companies essentially that have no choice but to, “accept the risk of outdated Java in order to be able to continue to do business.”

Inline Feedbacks
View all comments