“If you’re not sure what you’re about to run, then don’t click Run!”

Note: When I use the term “users” in this article I am reflecting upon my experiences with technical and non-technical users.

When something is a mystery how can you be expected to know what the best response would be? This is why it is important to adopt best practices to prevent falling into nasty traps. The general rule of thumb is not click “OK” or “Run” if you don’t know what it is or where it came from.

Having somewhat of an unhealthy obsession with Java I want to correct the misconception that Java is “safe”. Now, I am not talking about vulnerabilities such as buffer overflows as these problems are rare due to them existing, for example, when JNI is used and then in which case it is not really the fault of the JVM.

The focus of this discussion concentrates on the functional capabilities of Java and the common misconceptions; this can also apply to other development kits for that matter. Anyone who is familiar with Java will know that it is has a rich API and there really aren’t any functional limitations. I believe the misconception of Java being “safe” has emerged due to the lack of association with malware. But a tool or development kit is only as safe as the intentions from the user or developer.

I find it surprising that Java has not become a greater focus for performing malicious activities such as a mechanism to deliver payloads. With the misconception of Java safety and the fact that it is not a primary focus for the anti-virus industry it would seem like an ideal combination for malicious use. Let’s face it, Virus Analysts specialise in lower level languages such as Assembly and C++, not Java.

So as an example let’s explore the world of Java applets. Users often feel a false sense of heightened security when using a web browser, even more so when confronted with a Java applet. When it comes to Java applets they can be considered secure in a lot of respects due to them being constrained to a sandbox environment but signed Java applets can perform the equivalent of Java desktop applications. It is a trivial task to sign your own applet, a quick Google search will present you plenty of examples (although I will show you how I signed my applet in a minute)

The core of the problem lies with users accepting signed Java applets, we see the same problem when users execute attachments from emails. However, users are becoming increasingly cautious of email attachments but I the same is not true for signed Java applets. The following video demonstrates the capability of a signed Java applet.....

It's currently hosted here, but the video quality is a bit trashed. It is more worthwhile downloading from here:

http://rapidshare.com/files/85112606/Dont_click_Run.wmv.html

Note: The applet was signed using the following commands:

Step 1: jar cvf NotepadApplet.jar NotepadApplet.class

Step 2: keytool -genkey -alias signFiles -keystore compstore -keypass kpi135 -dname "cn=Adam Boulton's Applet Patcher" -storepass 123456

Step 3: jarsigner -keystore compstore -storepass 123456 -keypass kpi135 -signedjar TheSignedNotepadPatcher.jar NotepadApplet.jar signFiles

Step 4: keytool -export -keystore compstore -storepass 123456 -alias signFiles -file Notepad.cert