Unwanted Presents

Published: 2011-12-10
Last Updated: 2011-12-10 17:42:46 UTC
by Daniel Wesemann (Version: 1)
8 comment(s)

 

Fellow ISC Handler Tom Liston already covered the emergence of hacked DNS zones ("What's In A Name")  a couple weeks ago. Back then, the majority of the sites that we found affected by the problem were used to peddle porn and enhancement pills. Not so anymore - the current round of hacked zone files now leads to malware. [Yes, malware. So if you go investigating any of the hostile sites mentioned here on your own .. don't blame us for what happens to your computer]

The problem is only slowly starting to surface in the Google search results, but it is plenty evident in passive DNS loggers like RUS-CERT's: http://www.bfk.de/bfk_dnslogger.html?query=91.196.216.50#result

The domains affected have been abused for the past several days to push copies of the BlackHole Exploit Kit. The IP range used changes about every three, four days:

188.247.135.37 in use until Dec 2, AS34714, Opticnet, Romania
146.185.245.72 in use until Dec 5, AS43215, Monyson Group, Russia
91.196.216.50 in use since Dec 6, AS43239, Spetsenergo, Russia

One of the many exploits launched by these sites is for the Java Vulnerability CVE2011-3544 (RhinoScript Engine)

Note how the exploit code politely checks which version of Java is present, and only launches the exploit on Java installations that are not running the very latest update. Unfortunately, this seems to be the case for the majority of Java deployments out there. Today, almost two weeks after this latest wave of exploits started, the exploit code for CVE2011-3544 is still only detected by roughly half the anti-virus companies on VirusTotal .

Also note the encoded parameter passed to the Java applet (param name='p' value='e00..'). This passes the URL of the next stage executable to the applet, and specifies which EXE the applet should download and run once the exploit is successful. The URL is encoded with a mechanism that uses a lookup table to map between encoded and cleartext characters, but can be reversed by looking at the (heavily obfuscated) source code of v1.class.

The file names "v1.jar" and "v1.class" have been used by this exploit kit for a couple days now. In case you are wondering about infections in your company and you have a decent proxy log, searching for downloads of v1.jar, followed by a later download of an executable .. well, will tell you that you've been had. (Not finding anything is though no guarantee of course that you have NOT been had .. there are several other file names in use by the exploit).

While the Java exploit for CVE2011-3544 isn't the only one in the kit, it is likely by far the most successful for the bad guys at the moment. Considering the malware mess that Java vulnerabilities have caused for PC users in the past several months, any continued advice to "patch it" seems cynical at best. If you have to keep it installed, by all means, patch it. But if you can get away with it, the better option is to throw Java off your computer completely. Chances are high you won't miss it.

 

Keywords: java malware
8 comment(s)

Comments

We got one infection that pulled a v1.jar from gm21wv.com which resolved to 178.18.243.189 at the time of infection ... it currently resolves to 67.215.66.132.
You do realize that when I do a view source on your site you in fact use javascript on this very site? So before you go tell the world that Java and Javascript should be ripped off the face of the planet you might want to talk to you own webmaster and find out the value they see in the product(s).

Why don't we rip windows off the face of the planet as well while were at it - if you uninstalled that there might be a lot less infections as well. Hey - let's put Adobe and Flash out of their misery as well while were at it. Hmm what else can we rip - oh wait - I'm not hearing REPLACE in your arguments - you have no vision of what success looks like - without that how can anyone get there?

It's real easy to play the blame game and point at all the things that are wrong - the world has more than enough people doing just that (and half of the are actually creating more problems simply by doing so) - in stead perhaps you can slant the message more towards "here is the correct way to handle things".

As someone who makes a full time living writing java (not just JavaScript) programs I'm not sure I like the advice your giving out. We use SpiceWorks to ensure all our sites are in fact patched (both windows and Java) to the latest versions.

Hey - let's remove ISC.SANS.EDU from your bookmarks and the DNS servers as well - it uses JavaScript - and chances are you won't miss it...
"f you have to keep it installed, by all means, patch it. But if you can get away with it, the better option is to throw Java off your computer completely."

Gary, that's standard security advice - if you don't need it, remove it. If it's not installed, you don't have to worry about it falling behind and being exploited. This applies to all programs and services.
Have to agree w/ Gary here. While I understand where folks are coming from with the "don't need it, turn it off" mentality, Java is necessary for hosts of multiplatform applications. Taken to the extreme, the only secure computer is one that's not used. Our jobs aren't to say No, but to figure out how to protect our users in the conduct of their business.
Have to agree w/ Gary here. While I understand where folks are coming from with the "don't need it, turn it off" mentality, Java is necessary for hosts of multiplatform applications. Taken to the extreme, the only secure computer is one that's not used. Our jobs aren't to say No, but to figure out how to protect our users in the conduct of their business.
The only one who's talking about doing away with Javascript is Gary. The original article is about Java.

How many Java *client* applications do you actually use? More to the point, how many of those are applets that run in the browser? I personally use one for managing a particular piece of software, but apart from that I can't remember the last time I've loaded an applet in my browser.

Of course YMMV, but there is no good reason for me to browse the web with a plugin enabled that (a) I almost never use and (b) has a terrible security track record. I'd rather keep an alternate browser around with the Java plugin enabled for when I actually need it.

*Server-side* Java is a whole other story. *Javascript* is a whole other story. Disabling either of those would be a huge problem. But 99% of users could uninstall the JRE from client machines and never notice the difference.
I recently had the misfortune to land a contract with a client that uses w7 and an anti-virus product that corrupts the task image of a forked task, thereby messing up my ability to reliably use my old trusted cygwin/xemacs development environment to explore a large source base. I had to install eclipse instead, as it would give me the most important capabilities, and it would work under th w7.av combination. BTW eclipse is written in java. Now I am frequently running a non-web-based java client application on my workstation. Hmmm.....
I started to see this IP address in October, 35 entries so far. Seems to be if a user enter an invalid URL they are taken there.

Diary Archives