Hostile Java Applets Project

               


Introduction

"A Java applet is a Java program that can be included in an HTML page, much
like an image can be included. When you use a Java-compatible browser to
view a page that contains a Java applet, the applet's code is transferred
to your system and executed by the browser." (Quote taken from
http://java.sun.com/applets.) This should make you feel nervous.
Fortunately, (untrusted) applets that are loaded over the Internet are
loaded with restricted rights which minimize the potential damage to your
system. On the other hand, applets that are loaded via the local system
file system are granted many more "interesting" rights.

The purpose of the first part of the project was to create a "honeypot"
applet, one that is so tempting that a user will want to download the
applet to the local file system for use in their own web page. Once the
applet is in the user's file system, it can be loaded via the local file
system, for example, when testing the web page. At this point, the applet
should carry out an attack on the unsuspecting user. The goal of the second
part of the project was to protect a system against malicious downloaded
applets.

Scenario

Please visit our mock "Free Applets" web page to see how we plan to
distribute the hostile applet to unsuspecting users (henceforth referred to
as victims). On this page we offer samples of a number of marginally useful
graphical applets and provide an opportunity to the user to download these
applets for free. Installation instructions are provided to ensure that the
applet is installed in a directory which resides on the user's CLASSPATH.
This is necessary in order for the browser to recognize that the applet was
loaded from the local file system so the applet can be granted extra
privileges. (All of the applets found on this page contain code to carry
out an attack when loaded via the local file system, as described below.
However, there is no risk in looking at this page because all of the
applets will be loaded over the Internet before they are executed and thus
will not acquire sufficient rights.)

As would probably be done in practice, the source code of the applets is
not offered on this page. We have taken care, though, to ensure that the
applet we show on the page and the applet we offer for download are the
same file. Thus the user can observe that the applet they are about to
download does indeed perform the desired function. (It does, of course,
have some additional functionality when downloaded and then loaded from the
local file system.) Another strategy we have used to increase the trust
level is to associate the name of well-known company with the applet. In
this case, we have suggested that the applet is directly from Sun's page of
sample applets.

Possible Attacks

When an applet is loaded from the local file system, the following
violations of security are possible:

   * Read the system properties of the victim's machine
   * Read directories on the victim's machine
   * Read (text) files on the victim's machine
   * Make use of the user's CPU time
   * Create a socket to communicate with any other machine on the Internet
   * Forge email from the victim's account
   * Open up a popup window without the usual warning

Implementation

We implemented a pair of applets to carry out most of the attacks mentioned
above. We did not implement an attack based upon using the CPU resources or
opening a popup window. One applet serves as a client and executes on the
victim's machine. The other acts as a server on the attacker's machine. The
client applet contains two threads of execution: the first carries out the
expected behaviour of the applet; the second collects information from the
victim's system and sends it back to the server. All security exceptions
are caught so that when loaded over the Internet, the applet does not
reveal that it is attempting an attack. For demonstration purposes, we have
arranged that the server can send specific commands to the client. This
might actually be more useful than a self-contained attack. For instance,
it allows more flexibility in the attack, as it can be directed by a human
who has reviewed the preliminary information gathered by the client applet.
In addition, we anticipate that the client applet will be executed many
times for only short periods of time, and this technique would allow an
attack to be "resumed" each time the applet is started.