Escalating Java Exploitation
If you're into malware analysis or incident response, I'm sure you've come across a number of malicious Java applets lately. And perhaps you've noticed some new tactics being employed which are quite clever and probably effective in getting past perimeter and desktop security.
Here are three related articles that caught my eye:
A unique ‘fileless’ bot attacks news site visitorsAn interesting case of JRE sandbox breach
New Java Attack Rolled into Exploit Packs
As noted by Brian Krebs, the latest Java exploit, CVE-2012-0507, will be added to exploit packs soon. Some people believe that the Eleonore Exploit Kit is the first kit to use this exploit. An announcement at the end of 2011 revealed version 1.8.91 which included Java Rhino.
Eleonore Exploit Kit v 1.8.91
- Private sheaf exploit
- Coder - Exmanoize
- Are included new exploit:
- java_rhino
- pdf libtiff
- pdf u3d new
- flash pack
- quicktime
- iepeers
- mdac
Average having punched on a sheaf: 15-25% Depends on the traffic.
On сео traffic can be 25-35%
* Knock standard, even hardly above the standard:
< Zeus = 50-60%
< Loader = 80-90%
The price of last version 1.8.91 :
< Cost of the sheaf = 2200$
< Cleanings from antivirus = от 50$
< Domain change free of charge, change ip = 50$
< Updates = от 100$
* Sheaf with a binding to the domain or IP .
It's very possible that Eleonore has been updated since then with this new Java Atomic exploit as Exmanoize has added 0days to his kit before.
Microsoft researchers have already dissected this but let's have a quick look at this Java exploit anyway...
The exploit file has a hidden class in the applet ("arrayOfString"):
I used my Converter program to swap one character every one position to reveal the magic number for class files, "CAFEBABE":
After writing that out to a binary file, we can see that it uses two alternating values to XOR an encrypted file:
Since the file is encrypted and looks like a bunch of random bytes, it's very likely it would download just fine and land on the victim's PC as it's decrypted and executed by the applet.
Here's another tactic I found that's similar. This was part of a malvertisement campaign on a Chinese news site discovered the other day. Instead of downloading a separate binary file that gets decrypted and executed, malware authors are using a self-contained applet which includes the encrypted payload.
The entry point reveals a call to an external Javascript file, some encodings, and a redirect:
Here's the Javascript file doing the encoding:
You have to nail the referer and the parameters just right or you'd end up with this innocent JAR (I'm noticing that some new exploit kits require the same attention to details or you'll get a goose-egg):
If you're successful, you'll get the malicious applet.
The pl.class describes rotating four values to XOR decrypt a resource file that's actually included right in the JAR file itself. It's the CMQSQVRW file seen on the left-hand side.
Here's how the encrypted file looks like:
I wrote a quick and dirty program to XOR files using multiple values for added flexibility:
Sure enough, you end up with an executable, actually a DLL. You'll notice that the first two bytes are not "MZ". Those bytes are written out by the applet (see the above code) which my program didn't do.
When the applet runs, it decrypts the resource file, then writes it out to the temp folder as an innocent looking "htm" file:
The DLL file is then called up which scans the registry for known AV products. When done, it makes an HTTP request for a "tracking.gif" file which includes information in its user-agent string and cookie.
This behavior sounds similar to what the Kaspersky researcher found that preceded the Lurk infection.
Going back to the applet, I tried to look for clues that would tell me which Java exploit was used but there's nothing there. I noticed a Corba import and makes me wonder if this is using the vulnerability described here:
CVE-2012-0506 - "Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Update 30 and earlier, 5.0 Update 33 and earlier, and 1.4.2_35 and earlier allows remote untrusted Java Web Start applications and untrusted Java applets to affect integrity via unknown vectors related to CORBA."
There are no further information or technical details about this vulnerability so I can't confirm. Since Oracle indicated that they have fixed this vulnerability in Java SE 6u31, I installed this version and executed the applet. Nothing happened. The applet failed to decrypt and write out the DLL file to the temp folder.
DLL MD5: 52FA85A43AE7666DAAB7893385FA2F7FVT: 0/42Anubis
JAR MD5: 08331A5C7564FD61A84EDEA7FBCF56FCVT: 0/42