SpiderLabs Anterior

Java is So Confusing...

It's been a short while, but we find ourselves again with a Java vulnerability in our hands, this time via a PoC provided by IKVM.NET.

This particular vulnerability is somewhat different than most java vulnerabilities we run into, but feels like a natural progression from the last Java 0day we discussed in our blog (CVE-2013-1493).  Both these vulnerabilities allow direct memory manipulation, something which is quite uncommon in Java.
The vulnerability itself has to do with type confusion between an int and a double, causing 8 bytes to be copied instead of 4, thus overwriting a pointer and allowing us to reach otherwise inaccessible area in the memory.

Ransomware Author <3's Farm Animals

As security researchers, our virtual journey in revealing new threats on the web is never-ending. Every once in a while we come across a curious and interesting web attack. Today’s blog post will tell the story of one such case we’ve encountered recently. 

During last week, we ran into what looked like a hacked adult website that redirected browser requests to a web page which served two malicious Java applets. The landing page and the Java applets were recognized as Sweet Orange Exploit kit (thanks to Kafeine):

Fresh Coffee Served by CoolEK

As you may already know, the past few months have been problematic to Oracle when it comes to security issues discovered in the popular and notorious Java browser plugin. The latest vulnerability that has been spotted to be exploited in the wild is CVE-2013-1493.

It has already been published that CoolEK became the first exploit kit to add an exploit to CVE-2013-1493, so I won’t bother you with the details of that. What’s probably more interesting is the nature of this exploit. Most Java exploits from the past year or two used missing security checks in the Java source code in order to bypass SecurityManager – the part in Java which is responsible to make sure that unsafe code (unsigned code written by 3^rd parties) won’t be able to perform certain operations which require elevated privileges. Other exploits used some type confusions or tricked the optimizer into doing the same thing. Yet, in our current case, a memory corruption bug was found which allows the attacker to entirely nullify the SecurityManager.

This is the kind of exploits which are usually found in browsers and other non-sandboxed applications, so it was a little bit of a surprise to see such techniques in Java code.

Q&A w/ SpiderLabs Research: Java 0day CVE-2013-0422

Q: What’s going on? People are talking about some Java 0day which threatens the whole world… Bring me up to speed, now!

A: About a week ago, an independent researcher has reported a previously unknown (0day) Java vulnerability being used in order to infect innocent users with malware. When a 0day vulnerability is discovered it is usually reported to the affected vendor and that vendor will issue a patch that fixes the software bug, hence closing the security hole. However in this case the vulnerability was discovered by someone who chose not to do the responsible thing (reporting to the vendor), and instead took advantage of this finding for personal profit. A 0day vulnerability gives the attacker an imperative advantage over the victim for two main reasons:

1. The victim has no prior knowledge of the risk.
2. The victim has no effective means of protecting himself, since no patch is available.

In such cases being aware of the attack and its specifics is of highest importance, thus we have analyzed this vulnerability and posted our findings on the very same day it was discovered and verified out-of-box protections in Trustwave's Secure Web Gateway product.

First Java 0day For The Year 2013

Today @Kafeine was the first to announce the new Java 0day. This 0day allows an attacker to execute malicious code on any desktop with Java 1.7 u10 (or prior) installed – which is the latest version from Oracle.

After some preliminary analysis it seems this 0day is using a similar tactic to CVE-2012-5088, which was patched by Oracle last October. On top of using java.lang.invoke.MethodHandle.InvokeWithArguments() from CVE-2012-5088, the attacker smartly takes advantage of MBeanInstantiator in order to get a reference to a restricted class from a trusted caller (MBeanInstantiator is trusted). This is accomplished via the findClass method, which in turn will call the inner loadClass method.

The “heart” of the exploit:
We are glad to announce that all our customers using Trustwave's Secure Web Gateway are protected against this 0day attack. There’s no need for any additional updates to be applied. A good continuation of last year’s streak of 4 out of 4 Java 0days blocked out of the box.

We will continue monitoring this threat and provide protection to our customers.