I read the recent blog post from Talos Intelligence. Great write up, but noticed they mentioned they were unable to get the final stage of the payload. I had also analyzed the “EDGAR_Rules_2017.docx” document yesterday, and happened to get the final payload.

So picking up where they left off –

As they described, the stager powershell code uses DNS A records and TXT records to pull down the next payload. After some testing with the malicious powershell code, I ran into similar issues as Talos likely did and couldn’t get the next payload. Eventually I determined the A records were unnecessary, so wrote up my own quick powershell to pull down all the TXT records (turned out to be 44 TXT requests):

The result is just your typical C&C bot code, still using the same C&C servers mentioned in the Talos Intelligence blog.

A different structure of DNS records is being used for different commands. Instead of the hardcoded “stage” string to make up the URL (such as AAAAAAAAAA.stage.0.ns0.pw), we now have “add” (register bot), “mx1” (get ‘mode’), and “www” (get tasks). Exfiltration appears to be done via a web form hardcoded to the url: hxxp://ns0[.]pw/index[.]php?r=bot-result/index

I registered a “fake bot” to see what the initial list of tasks were. The first list of tasks were:

I initially had some doubts that I could get it to work how I intended, but after a short few hours, I had effectively disabled all java applications, except from the ones I explicitly had in my XML whitelist.

Backing up a little bit, everyone out there is aware that many enterprises have issues with upgrading to the latest java version. There have been many proposed solutions, some which work better than others, but in my opinion, there really hasn’t been anything that mitigates the risk significantly enough for the additional cost of any given solution. For example, using two browsers, one for internal use, one for web browsing, was a proposal I’ve heard thrown around. While this may work in theory, by doing this, an enterprise would incur more costs to keep the second browser patched and maintained, and more costs to build security controls around this new browser as well (policies to disable the ability for users to use a proxy, or using the intranet browser to go on the internet, ect), not to mention any additional installed software introduces additional risk just by being there.

In any case, after initially reading various articles, such as this one, this whitelisting concept sounded interesting, so I thought I would give it a try.

Preperation

After that, I mostly followed Oracle’s initial blog about Deployment Rule Sets, so some of the following is repeated, but I tried to give more detail, as some part’s were unclear in their blog if you just quickly wanted to throw together a POC.

In the real-world, you would have a rule for every white-listed internal application at your enterprise, but I just wanted to test this new functionality out. The first rule should allow Java applets in the javatester.org domain to run fine, under version Java6u30. The second rule is a catch-all, and should block all other Java applets you browse to.

Testing the RuleSet

First, the Java 7 update 40 console appeared (left console appeared first), and appears to have checked the ‘whitelist’, and ran the applet under Java 6 update 30 (right console appeared second), just as the ruleset specified. The version the applet detected was in fact Java 6u30, which is what we were going for, as our “legacy” java software would break under the newer java versions 🙂

And, if we go anywhere else, whether it be intranet or internet, we are presented with the following:

So everything appears to work as intended.

Conclusion

While this was just a quick POC, it was enough to show this actually has some promise as a solution to mitigate the risk an enterprise incurs by using legacy java applications.

There are some cons to this approach:

If not protected, the end user may be able to delete the DeploymentRuleSet.jar and bypass these restrictions. This mostly would affect corporations that allow their users to run as a local administrator, and so there’s less control over what the user does on their PC

There would be some overhead of managing this DeploymentRuleSet.jar file, storing the certificates, ect.

This is a new feature in Java, so there may be some bugs/vulnerabilities introduced (perhaps the white-list can be bypassed? I don’t know, I haven’t looked into how this feature works quite yet)

Still, I am thinking the benefits gained outweigh all the potential cons. Instead of flat out blocking java for the default rule, you can set the version to SECURE-1.7, which in theory will force users to have the latest/secure version of Java 1.7 installed in order to run all other Java applets they come across. While all versions of Java appear to be vulnerable to something, much of the risk of being infected would be mitigated by running the latest version of Java while browsing the internet.

So in conclusion, this (currently) appears to be a great risk-mitigation solution for enterprises who can’t (or don’t want to) remove or patch Java. I just hope that this white-list isn’t as easy to bypass as the JVM sandbox has been 😀

Now after my 30 day lab time at OffSec’s CTP course is up (awesome, more on that later), onto CVE-2013-2465, which can exploit all of Java 6, including the latest (6u45), as well as Java 7u21 and below and Java 5u45 and below. As noted elsewhere, this exploit, among many others, is significant as Java6u45 will not be patched by Oracle, so anyone not upgrading to Java 7 (ie the latest out there) will be easily exploited… not that Java 7 is much better, but at least it’s being patched… on occasion…

UPDATE: I decided I didn’t need sleep, took a look at the Neutrino CVE-2013-2463 acquired from dontneedcoffee.com as well as CVE-2013-2465. They are nearly the same, so figured might as well include both here 🙂

Anyway, I wanted to see how this exploit worked and put together some working code, so I downloaded Neutrino’s take on the exploit, and analyzed it (‘deobfuscating’ manually of course… I use that term loosely this time).

After some review, honestly, the exploit has very little obfuscation. Really, Alt.java is the most notable file, as it contains the actual exploit (the “attempt” function). The only other two files that are necessary are ijk.java (it extends ICC_ColorSpace) and jki (extends ComponentColorModel).

This is the reduced files (which as always, will pop up calc.exe upon exploit).

Note: Remember to only use this on machines you’re authorized to exploit, anything else is illegal!

And, the result against Java6u45 (no click to run apparently necessary):

The CVE description says this is related to “Incorrect image channel verification”.

The key seems to be where the AccessControlContext class is essentially passed a Permissions object containing AllPermission(). From what I gather, AffineTransformOp has a call to a vulnerable storeImageArray() method, which seems to have something like a buffer overflow vulnerability, where once outside of that buffer, you are working outside of the sandbox (or something like that, Java isn’t my specialty). Then you use the AllPermissions Permission to work without a Security Manager.

Update:
Now, taking a look at CVE-2013-2463, the code is just about the same, it just exploits AlphaComposite.Src.createContext instead of AffineTransformOp. But the end code is very similar (the key different areas are bolded). Also, only a single class is used for this exploit.