Are you sure you're clean?

I do a ton of penetration testing as a tester. I've been doing this for quite a while now - nearly a decade. I advise a ton of peers, juniors, clients, non tech users .. well pretty much anyone about how to stay safe. I know all of this. And yet.. recently I inexcusably slipped up.

One of my Virtual machines which I'd cloned to test a thick client at a client site had a few viruses on it. One of them was C:\Windows\update.exe which did not sound good in the least. Most I found in Temporary Internet Files of the Local service and Network service accounts and there was 1 more EXE file somewhere.

The malware didn't behave like how it was "supposed" to based on the description on the website. So maybe they were all benign...and I was good. But that still doesn't explain how they got on to  my disk in the first place...and what they were doing a VM which also handled customer data. The worst part was that it had probably been lying there for a while without me noticing it. Most probably some remnant of my own research..but I can't be 100% sure. In short.. it was downright dumb on my part. No excuses.

So that made me relook at my setup and I have since gone on a drive to clean it all up. I dumped all my VMs (still in progress) and created everything from scratch from the ISOs, updated them, will harden them a bit and take snapshots of the clean state.

I deleted all my malware analysis images, reversing images and will recreate them from scratch and snapshot those too. So in the end here's a list of the VMs that I will eventually have.

1) WinXP 32 bit
2) Win 7 64 bit
3) Ubuntu 32 bit
4) Ubuntu 64 bit
5) Client WinXP machine + Word + Visio
6) Linux dev environment
7) Windows 64 bit reversing
8) Linux 64 bit reversing

All of them updated, hardened (services turned off) and snapshots taken. Ideally I'd just move everything on to a separate machine..all my malware... but I don't yet have another machine. Once I get that, I'll move all my reversing to a separate machine.

Overall though - you're not immune from doing stupid things. You may know but it doesn't mean you're perfect. Hopefully this post will help all you guys who dabble in multiple technologies all the time - to serve as a reminder of what can and does ..go wrong at times.

Restrict signed Java applets

There's a ton of information on the Internet on how to sign Java applets and restrict unsigned Java applets as well. Very strangely there is very little information on doing the same for signed applets.

I did manage to find information which eventually helped me out; just that it took an insane amount of searching. Hence this little blog..which just collects all the information I found and puts it in 1 place.

First of all, the reason (as you already most probably know) to restrict signed applets, is that they're all powerful and can perform dangerous file I/O and network operations. So it's a nice thing to be able to restrict them from doing so, if needed. So here are the steps to do so, in a nutshell:

a) Sign your Java applet using keytool and jarsigner. A self signed applet is sufficient for demo purposes. The same logic can be used in case a trusted CA signs the certificate.

b) Once the applet is signed it's usually packaged into a JAR file prior to deploying it.

c) It's then deployed by embedding it into the HTML of a web page.

d) When the user visits the page, there's a pop-up which will now appear, asking the user to grant the applet additional permissions. Note here that if you click Run, the signed applet has complete control and can make numerous file and network I/O calls. If however, you click Cancel, you're not granting it permissions. The applet still runs (contrary to what one might intuitively think) but behaves like an unsigned applet.

e) What we now want to do though, is to limit what the applet can do, when the user clicks Run. For example: If all the user wants to do, is write to /tmp and nothing else, why should it have a million other privileges?

f) There's 2 ways to do it. One is to call every single relevant method in the applet from JavaScript. The second way is to write a policy in java.policy. Without frustrating you further, I'm going to show you, with a little sample code on how to do both.

g) First of all here is the Java code that I used as a POC. It's grabbed and tweaked from some tutorial online and not my own.

import java.applet.*;
import java.awt.*;
import java.io.* ;
import java.util.*;

public class FirstApplet extends Applet{
  public void init() {
    createFile("/abc/testsignapplet.txt");
  }
 
  public void test_HTMLbutton_method_invoke() {
    createFile("/abc/booboo.txt");
  }

  public void test_js_onload() {
    createFile("/abc/doodoo.txt");
  }

  private void createFile(String filename) {
    FileOutputStream out = null;
    try {
      out = new FileOutputStream(filename);
      out.write(("Testing jar signing process...:" + new Date()).getBytes());
    } catch(Exception ex) {
      ex.printStackTrace();
    } finally  {
      try {
        if(out != null) {
          out.close();
        }
      } catch(IOException e) {}
    }
  }
}

h) Here is how you must call the public methods of the applet from either an HTML element or from JavaScript. The line in the last < script > block which embeds the applet is possibly not the best way to do things; it's just there to show you guys how to call a method via HTML and JS, which is the point of the post.

i) Doing so, will cause the applet to still behave as an unsigned applet. If there's any malicious code in any of those functions, it's not going to be able to break out and cause havoc.

j) The other way of limiting the operations an applet can perform is by editing the file called java.policy. On a Ubuntu system, by default this file is inside your home directory. It is named .java.policy.

k) Back the file up and then delete all the lines in that file. Now add these lines to the file. This limits the applet loaded from http://localhost/applets/ from writing to any other directory except /abc.

grant codeBase "http://localhost/applets/*" {
  permission java.io.FilePermission "/abc/*", "write";
};

l) Note that a cool GUI tool called policytool can also be used for this purpose. If you have JRE or/and JDK on your machine, you should have policytool as well. You can add/edit/remove policies using it as well.

m) Test your applet using appletviewer first. It's a tool which you can use to check if your policies are working properly, before deploying the applets everywhere.

appletviewer -J-Djava.security.policy=/home/arvind/.java.policy sample.html

n) If the results are as expected, launch the applet in the browser. All the HTML and JS calls to methods should be blocked :)

----------

p.s - It's a good idea to have the Java Console launched while you're doing this stuff. It throws exceptions that you can then see and modify your approach accordingly. The Java Console can be launched using javaws -viewer and ticking 'Show Console' in the Advanced Tab.

Other Java related settings can be tweaked too in here. A good guide to follow can be found here - http://seanthegeek.github.com/harden-java/