How secure is the Java
Wallet
Most readers are probably aware of the
numerous security problems discovered in the past two years in Java-enabled Web
browsers. Hostile applets remain a threat, even in the latest browsers, and
third parties who claim to offer tools to bolster security frequently fail to
do so. Thus there is a real need to scrutinize all types of Java-based products
for security problems and to candidly report those problems in a public forum.
This has the desirable dual effects of alerting users to potential threats and
bringing market pressure to bear on vendors who continue to offer flawed
products as secure solutions.
In keeping with this line of thinking,
we have recently taken a close look at Sun's Java Wallet. Our examination
revealed a number of problems that allow untrusted applets to exploit systems
on which the Java Wallet is installed. Among our examples are applets such as
the following:
- Pickpocket: an applet
which steals information and passwords from the Java Wallet
- BookMarker: an applet
which alters the behavior of the Java Wallet's "Help Contents"
button
- DemonDialer: an applet
which can gain full access to your modem.
Since the Java Wallet is a recent and
evolving product, we begin with an overview of its key components before moving
on to consider several of its problems. For more details, the reader is invited
to consult The Java Wallet Architecture White Paper and the Java Commerce
Business Perspective from Sun Microsystems which are linked from the bottom of
this article.
What
is the Java Wallet?
There are at least two distinct senses
in which the term Java Wallet is used. In its broadest sense, the Java Wallet
is simply the Java Electronic Commerce Framework (JECF). In a non-O'Reilly
nutshell, the JECF is designed to be an open, extensible architecture for
developing secure electronic commerce applications in Java. It consists of a
number of application programming interfaces (APIs) that extend those of the
Java Developer's Kit (JDK) as well as a suite of tools to assist developers in
building electronic commerce applications with those APIs. (These APIs are
sometimes collectively referred to as the Java Commerce Client (JCC)
Framework.) In its narrower sense, the Java Wallet is a program with a
wallet-like graphical user interface that can be used for on-line purchasing
and numerous other financial transactions. As such it is one of the JECF tools
developed by Sun using the JECF API's. It is in this narrower sense that we
consider the Java Wallet.
In order to better understand how the
Java Wallet can fail, we first review some of its key concepts and components.
We may enumerate these briefly as follows:
- Gateway
Security Model: The Gateway Security Model is the foundation of the
Java Wallet's security. It defines such concepts as roles, permits, gates
and contexts which the Java Wallet implements and uses to enforce security
restrictions.
- Instruments,
Protocols and Operations: Instruments are objects that represent confidential
user data and, more significantly, a Java Wallet user's relationships with
businesses and financial institutions. The classic example of an
instrument is a credit card. Protocols are fixed sequences of actions,
agreed upon in advance, that allow two or more parties to complete a task.
Operations are procedures which utilize protocols and instruments to
complete significant tasks, such as the electronic transfer of payments.
·
Commerce JavaBeans: Commerce JavaBeans are modular components that extend the
JavaBeans model in three ways: they are typed, they offer an extended version
of Java Bean Info and they support the Gateway Security Model.
- Cassettes: Cassettes
are signed Java archive (JAR) files that may contain JavaBeans as well as
the resources required for their operation. In order to be useful,
cassettes must be signed for the proper roles and installed in the Java
Wallet. Operations can require specific cassettes, which can be installed
dynamically, and cassettes can depend on other cassettes being installed
in order to function.
- Java
Commerce Messages: A Java Commerce Message (JCM) is a block of text sent
from a commerce server to the user. JCMs use a specific format to convey
information about operations, protocols and instruments. They can be
downloaded from static files, generated by scripts and invoked by applets.
In every case they are used to activate the Java Wallet which parses them,
instantiates the necessary Commerce JavaBeans and carries out the
requested operations.
- Java
Wallet GUI: The Java Wallet's GUI is typically invoked when a JCM
is downloaded. This allows a user and a commerce server to interact
effectively. Though designed to be almost completely customizable by developers,
the user interface should always contain three main areas: the selector
area, the service area and the frame. Of these, the frame, which contains
the Trusted Seal indicating communication with a secure server, is not
designed to be manipulated by developers for security reasons.
- JCC
Database and its properties: Installing the Java Wallet and creating a wallet user
sets up a relational database, the JCC Database, in a file with a name of
the form wallet_login.wlt. Since the JCC Database contains sensitive data
about registered cassettes and may contain credit card numbers, PINs and
passwords, it is encrypted and should be accessible only to the wallet
owner who logs in to the Java Wallet. Other important configuration
information can be stored in file called jecf.properties in a .jcc folder
under the user's home directory. When a user chooses to save a default
login name and password for the Java Wallet, that information is stored
here in plain text. As we will see, this can lead to a certain amount of
applet mischief.
This review of the Java Wallet's main
components, while perhaps too brief, should be sufficient to understand its
problems. Though a commerce server can invoke a user's Java Wallet in a variety
of ways, most of these will not concern us here. Our main interest lies in
exploring what untrusted applets can do when the Java Wallet is present. Two of
our applets will simply employ the Java Wallet's classes to obtain unauthorized
access to sensitive information and services on the user's machine. Though a
third applet will invoke the Java Wallet, it will do so in trivial way in order
to induce a careless user into using a "Help Contents" button whose
behavior the applet has altered.
Applet
exploits
We are now ready to take a look at
three examples of untrusted applets that exploit weaknesses in the Java Wallet.
In order to develop these applets, we downloaded the Java Wallet (Early Access
Release 1) and installed it according to the instructions. Since the Java
Wallet required Sun's Java Plug-in 1.1 to be installed, we downloaded and
installed that as well. We later learned that the Java Wallet does not always
work properly with the Java Plug-in, and so we also installed it with the
Project Java Activator (Early Access Release 3). Unfortunately, our example
applets work with both the Activator and the Plug-in-in.
Pickpocket:
an applet which steals information and passwords from the Java Wallet
Applications that save login and
password data for your convenience are always tempting targets. Unfortunately,
Sun's Java Wallet offers this feature, and we found that it is easy for an
untrusted applet to recover any saved information. Our first example shows how
an applet can discover the Java Wallet's home on a user's machine. This
necessarily contains the user's home directory (according to the user.home
property). The example also shows that an applet can read the Java Wallet's
properties file (jecf.properties). This allows the applet to gather saved user
login data and "decrypt" saved passwords.
To test this applet, you first need to
set up Sun's Java Plug-in (or Activator) and Java Wallet, and you need to
create and save a wallet as the default for auto-login. We set up a wallet with
a login name "dummy" and password "easy2read," and then we
ran our applet. This yielded some very interesting information. You can also
read the source code to see how applets can easily access the jecf.properties
file. Clearly some restrictions will need to be placed on this applet
capability. Using a BASE64Encoder to "encrypt" passwords is also not
a very good idea.
BookMarker:
an applet which alters the behavior of the Java Wallet's "Help
Contents" button
Our second example demonstrates how an
untrusted applet can alter the behavior of the Java Wallet's "Help Contents"
button. On Solaris systems this allows the applet to execute commands via
Netscape's Communicator when that button is pressed.
In order for the "Help
Contents" button to function at all, the user must have already set the
property jecf.browser.path in the file jecf.properties. Since this is an
apparently unadvertised feature of the Java Wallet, a second applet runs on the
same page as the BookMarker and prompts the user to set that property. Note
that this applet runs via the Communicator's own Java Runtime and that it uses
Netscape's security apparatus to display Netscape's certificate along with its
own message.
In order to try these applets, you need
to set up Sun's Java Plug-in (or Activator) and Java Wallet along with
Netscape's Communicator (4.04 or 4.05) on a Solaris system. You should also
have Sun's Purchase 1.1 Java Wallet cassette and a Java Wallet user set up.
Then you should be able to run the applets.
Helper.java retrieves private
information about Netscape's System Principal by creating a handy encoder. It
then creates a fake System Principal and uses that to display Netscape's
certificate along with a message asking you to verify that jecf.browser.path is
properly set in jecf.properties. If this social engineering effort works, the
Java Wallet's "Help Contents" button will function and be able to do
the applet's bidding.
BookMarker.java first downloads a bogus
Java Commerce Message to start the Java Wallet. Once the Java Wallet is
started, the applet can gain access to the field JECF.globals.releaseBundle and
set that to a new ListResourceBundle of its own construction. The bogus Java
Commerce Message causes the Java Wallet to display a phony message about an
internal test along with instructions to press the "Help Contents" button
for more information. If you do so, the applet then adds a bookmark to the
Hostile Applets Home Page to your bookmarks.
Note that on Solaris systems lots of
other options are available to the applet. Using the -remote flag allows the
applet to run any of the Communicator's xfeDoCommand options. Using the -java
flag allows the applet to have the Communicator's Java Runtime execute any Java
program in your CLASSPATH. For example, this particular ListResourceBundle
allows the applet to set up a ServerSocket and echo server on your machine.
Clearly the ability to change the behavior of the "Help Contents"
button can lead to much mischief.
The
Java Wallet and its problems
While troubles like these are serious
and embarrassing for vendors of any product that touts itself as a secure
solution to the problems of electronic commerce, they need not be fatal for the
Java Wallet. It is clear that they can all be corrected by properly restricting
public access to methods in the Java Wallet's classes. (Saving login and password
information, while perhaps convenient for the user, is a foolish feature that
should be removed from future releases of the Java Wallet.) All of these
problems may, however, give another black eye to electronic commerce and leave
lingering doubts in the public's mind about the wisdom of trusting products
like the Java Wallet. In that regard the Java Commerce team may be shooting
itself in the foot by releasing a product with too many obvious flaws. We can
only hope that as electronic commerce, Java Security and the Java Wallet all
mature, we will see fewer and fewer such problems in Java-based products.
No comments:
Post a Comment