FireEye Malware Intelligence Lab

Who is Exploiting the Java 0-day?

Update: Oracle released an emergency patch recently to fix this major flaw. See details in the bottom.

-------------

The recent discovery of a 0-day design flaw in the 'Java Web Start' module has opened new avenues for malware drive by attacks.  This flaw was exposed by Tavis Ormandy a few days back and it did not take a long time for bad guys to start using the proof of concept code for real exploitation.  I have been reading about the exploit details for the last few days, but very few details were available on the active use of this exploit.  Who are the guys using this exploit and for spreading what?  This article is all about this, with emphasis on the post infection stuff.

Users who are interested in the inner workings of this 0-day flaw itself, can read the full disclosure here.

It all started like this... yesterday afternoon my colleague Stuart Staniford pointed me to a malicious domain hxxp://zikkuat.com (dead at the moment) which he believed seemed to be exploiting this 0-day flaw.  After a little analysis, I found it to be true indeed.  Here are the details of my findings after a detailed analysis.

On the new Explorer XML zero day

See update below!

Shadowserver is reporting  on websites serving up a new zero day Internet Explorer exploit involving XML (see also SecurityFocus and an initial so-far-sketchy Microsoft advisory).  For the sake of our customers (and potential customers!) I wanted to tentatively report that a) indeed this appears to be a real factor in the wild by now, and b) the FireEye product does appear to be correctly detecting it in at least one case.  I checked around a few boxes I have access to and found a VM verified web infection event which was initiated from the web server 94.102.50.131.   (That IP address should be assumed to be armed and dangerous).  Our statistical anomaly algorithms picked up on the following piece of javascript (this is a screenshot so should be harmless unless you retype it:)

I haven't seen this <object id=xmltarget classid="CLSID:88d969c5-f192-11d4-a65f-0040963251e5"> in malicious Javascript recently enough that I can recall it off the top of my head - and some grepping on the boxes I checked found only this one event like this in the last month.  "88d969c5-f192-11d4-a65f-0040963251e5" turns out to be the class ID for the ActiveX control that implements XMLHTTP within Microsoft XML Core Services so it seems likely that this is an instance of the new exploit (though I haven't verified that yet) .  There was a vulnerability in this component back in 2006 (eg see the Securiteam advisory from that time).  If so, it's at least possible that the instructions at that link for disabling that component would also be protective here.  That would be less impactful than not browsing with IE 7.  (Again, I stress that I haven't confirmed that speculation - I'm throwing out the possibility in case it's helpful to others in the community).

More tomorrow hopefully.

Update:

It turned out when we investigated this in detail that it's not related to the XML zero-day vulnerability.  We've now seen four of these events at various customers with the same starting <object> tag with the same classid.  We haven't seen that particular form before, and Google does not find other discussions of it.  The obfuscated body is polymorphic but when deobfuscated reveals a bunch of older browser/plugin exploits.  One of the incidents succeeded in infecting the client, and on investigation, that turned out to be this fresh packing of the Grum bot.  The destination IP of the exploit server was the same in all cases, and it's a known RBN IP address.  The campaign appears to be driven by malicious ads.  Thanks to Julia, Atif, and Alex for help in investigating, and apologies for any confusion: it appears to be a new obfuscation idiom and a new packing that was not recognized by almost any AV, but not a new exploit - just coincidence that the XMLHTTP classid was used on the same day that the new XML exploit was out.