Spilling the beans

Increasingly sophisticated hackers going for Java’s native layer

Lucy Carey
java-1

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
t
his year alone. Uptake of these patches isn’t
necessarily immediate however, leaving clients open to a
gr
owing 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.”

Author
Comments
comments powered by Disqus