Patched your Java yet?

Published: 2012-11-01
Last Updated: 2012-11-01 00:22:55 UTC
by Daniel Wesemann (Version: 1)
21 comment(s)

Yes, there's some irony to this diary entry. In the past, I have been suggesting repeatedly that organizations who do not have an all-out requirement to keep a Java JRE runtime installed, should get rid of it. Yet, here I was, a couple of days ago, reviewing some SIEM events at a Community College where I help out with IT Security, when something caught my eye  (URLs defanged to keep you from clicking):

src='' media-type='application/x-jar' url='GET hxxp://outdrygodo.mine. nu/finance/etzko5.jar'
src='' media-type='-' url='GET hxxp://outdrygodo.mine. nu/finance/qkefaw.php'
src='' media-type='application/octet-stream' url='GET hxxp://outdrygodo.mine. nu/finance/e32ezw.php?category=/&news_id=314214&date=1012&gen=j&lam=true'

Basically, a user here is getting an unsolicited Java Applet. A little while later, the same workstation gets an "octet stream" (think: executable). This can't be good. But why isn't anti-virus alerting on it?  [Yes, this is a purely rhetorical question :)]

Turns out, the workstation in fact has been infected. The JAR contained an exploit for CVE-2012-4681. And there is a "skype.dll" sitting in C:\ProgramData, and, even "better", it apparently happily talks to some server in the Ukraine:

src='' media-type='-' url='POST hxxp://195.191.56. 242/posting.php?mode=reply&f=72&sid5=0ef2884d693eadc605e9bf726c1b9881'

Checking through the logs in detail now, we determined that the PC was talking to this server in the Ukraine whenever the user was logging into some web page. User goes to GMail? PC talks to the Ukraine. User goes to Amazon? PC talks to the Ukraine. User goes to online bank? Yup: you get the drift.  In between, the spyware kept mum. But whenever the user happened to enter some password, the spyware merrily ratted him out.

Looking through the logs even further back, we were able to determine that the original infection had happened when the user visited a - perfectly benign - newspaper web site, which at the time apparently was featuring a poisoned advertisement banner somewhere within the page content.  The entire attack happened compeletely stealthily, there is nothing the user could have seen or done  (maybe with the exception of Java popping up in the tray, but who pays attention to that?)

In short, if your Java JRE is unpatched, you will get hacked. Silently and stealthily. The bad guys will grab all your passwords for a week or so. And then, they will move in, and change your life.

In the case at hand, it was an e-banking application, of all things, that did not yet work with Java JRE 7, and had kept the user from upgrading his Java JRE.  From other users, I hear that some releases of enterprise software from large vendors like SAP, Oracle, etc, are also not fully compatible with the latest Java JRE, and thus force their users to remain exposed to attacks like the one described above.

Bottom line:
If you don't need Java JRE on your PC, get rid of it.
If you need it, patch it.
If you can't patch it because some silly application is not compatible with the patch, kick the [beep] of whoever supplies that application.

In case you are in the latter situation, feel free to share in the comments box below. Maybe there are other ISC readers similarly affected, and if you join forces, the vendor might be more inclined to listen.


Keywords: java malware
21 comment(s)


Sadly it seems like the Oracle and SAP monolithic ERP systems are platforms that don't get upgraded frequently either, causing a catch-22 trap with old Java version requirements. More than a few companies I have worked for are 'trapped' on Oracle 10 databases and elderly ERP versions due to the effort and expense of updating, which in turn traps them on old JREs so the ERP client apps will continue to work.
Beyond keeping things fully patches, I assume AdBlock Plus can be a further tool of prevention in this arena, since it blocks the infected ad in the first place, right?
Oracle HR and E-Business are the ones that keep breaking when we try to run the current JRE. And we are running current versions of those applications. Even worse, we deal with a lot of local government websites and they always have outdated applets with expired code-signing certificates and break when we update the JRE. We actually have one application used to manage our payment cards and the bank that supplies it embeds JRE 1.3 (not a typo) in the current version. We virtualized it but it had problems so we had to publish it as a Citrix application where the Citrix server can't get to anything on the Internet except that bank's site. What a waste of our time.
I have no need for java on websites, but I have a requirement to run a JDE as part of a scripted software testing setup. Texas Instruments supplies their Code Composer (Code Composter!) variation of the eclipse IDE together with a jar file that interfaces to their hardware JTAG debug pod. I need the JDE to interface extensions, such as the National Instruments Data Acquisition devices, or DAQs, and some of our own interface libraries, all written in C/C++. I use SWIG to do this, but I still need to keep the JDE around to make this possible. Is there some way I can prevent that JDE from "poisioning" my browser? I am forced by client standards to run win7 and Internet Explorer, and the test stuff runs on the same machine.
If only I had a dime each time I heard a vendor saying "You need to have this _old JRE version_ if you want to call for our support" :-(
Is there any benefit to using multiple browsers - one associated with the old JRE that is only used for the craptastic legacy app, and one associated with the current (or preferably no) JRE?

I seem to recall reading a few years back that Java applets can actually request to use older JREs if they are installed, but can't remember the details or if this was fixed.

Appreciate any insight.
This looks like the g01pack exploit kit.

The DNS entries are very short-lived, and the exploit and payload URIs are one-time and restricted to a single IP. The landing page is usually full of random junk words and includes the Java exploit and some encrypted payload URLs (the encryption varies once or twice a day).

The payloads include a random extra byte at the beginning which is used to XOR the rest (hence no AV - though I think an AV could check for this!).

Other favourite domains at the moment are * and *

BTW - CVE 2012-4681 is the 0-day from August AFAIK. I haven't seen an exploit for the vulnerabilities in Java 1.6.0_35 and 1.7.0_07 yet, though I expect we'll see some very soon :-(
Our organization was losing so much time to testing patches against an increasing number of third party solutions and rebuilding infected machines (quarantine or deleted, we pull the drive and rebuild the PC.) We recently locked down Internet access to a handful of sites critical for business use -- even in the IT department. Users have to have sites approved by their manager, be able to prove that it is a site they access daily, and that it meets a critical business need.

For all other Internet access, we set up a separate, isolated wireless network with dedicated stations used for all other browsing and its own dedicated Internet connection. It's a serious pain, but for once BYOD is being a big help (users can use smartphones and tablets to browse the Internet), we've seen a significant drop in infected PCs, and our business-needs Internet connection runs much quicker for everyone. Even better, the dedicated browsing PCs are much easier to keep up to date since there's far fewer restrictions on specific versions that need to be installed for specific in-house systems.
Another solution is to use Firefox Portable and JPortable as a standalone Java-web client and keep the global plugin off other browsers. I use this for apps that use Java and my other browser (without Java) for everything else. One can even have separate copies of it with different Java versions.
And yet SANS vLive still requires Java.

Java Delenda Est!!!

Diary Archives