What Is a Malicious Applet? (Ch. 4, Sec. 1) [Securing Java]

Malicious Applets: Avoiding a Common Nuisance
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9

Section 1 -- What Is a Malicious Applet?

A malicious applet is any applet that attacks the local system of a Web surfer using one of the three less-serious classes of attacks discussed in Chapter 2. Malicious applets involve denial of service, invasion of privacy, and/or annoyance. Malicious applets are written by researchers, crackers, and Net miscreants to harass, annoy, and damage Java users. They can even seriously damage a Java user's machine. Any applet that performs an action against the will of the user who invoked it should be considered malicious.

It is important to emphasize again that use of the term Java user applies equally to Java developers and people surfing the Web with a Java-enabled browser. Using Java does not require any programming, or even possession of the JDK; it is enough to use a Java-enabled browser. Under this definition, most people who surf the Web with Java on are Java users. Malicious applets exist on the Web today that do the following bad things:

Forge mail from you to whomever the evil applet's author chooses, saying whatever they wish while masquerading as you
Steal your CPU cycles to perform their own work while your legitimate processes languish
Crash your local system by using all available system resources

These activities are both impressive and daunting, and we have only scratched the surface.

There are also malicious applets created simply to annoy. These applets go only a bit too far, lingering at the edge of respectability. These sorts of applets do things like play sound files continuously, set up threads that monitor your Web use, and display unwanted graphics on your screen.

Stopping Malicious Applets before They Start

What can be done to stop malicious applets from doing their evil deeds? The best alternative now is to set a security policy that allows only applets signed by trusted parties to run. But if you want to surf with a Java-enabled browser and run every Java applet you come across on the Web, the safest thing to do is to avoid unknown and untrusted Web sites unless you first disable Java. Just by using a Java-enabled browser to surf the Web, you are open to attack by both attack applets and malicious applets. This danger, combined with the serious attacks discussed in Chapter 5, has caused the CERT Coordination Center to recommend disabling Java when surfing untrusted sites [CERT, 1996a; CERT, 1996b].

What can be done to stop these applets from doing their evil deeds in the future? There are many possibilities. One interesting approach would be to write detectors for bad applets based on known vulnerabilities. That way, they could be screened out by the byte code Verifier (or some similar extension). Princeton's Secure Internet Programming team has investigated this possibility extensively, and research at Reliable Software Technologies continues. (It turns out that the problem is harder than it may seem on first consideration.) A number of commercial enterprises now sell products that claim to screen byte code for malicious characteristics. We investigate these products in Chapter 6, "Securing Java: Improvements, Solutions, and Snake Oil."

Another way to protect against malicious applets is by improving Java's security model. To the extent that any holes identified by researchers have been quickly and thoroughly patched, the security model can be said to be improving. However, the practice of patching software after exploits have been demonstrated is backwards. This unfortunately common strategy is known as penetrate and patch, and has been criticized for many years by security practitioners. (For more on this issue, see [McGraw, 1998].) Better software engineering and more thorough software assurance practices are much more appealing. It is even possible to write your own code defensively so it makes a much harder target for bad guys to attack (see both the guidelines of Chapter 7, "Java Security Guidelines: Developing and Using Java More Securely," and Chapter 9, "The Future of Java Security: Challenges Facing Mobile Code").

The addition of code signing to Java in JDK 1.1 and its extension with access control in Java 2 allow for the creation of complex security policies based on authentication of applet signers. Using this technology, a Web surfer could specify a list of trusted sites whose applets should be allowed to run without restrictions. The trick is creating a sound security policy and correctly coding it into your browser.

The next few sections discuss various kinds of malicious applets. Starting with the least worrisome category-the merely annoying-the text progresses through the truly malicious machine-hangers. Possible motives for creating these applets are discussed along the way. Keep in mind while you read this chapter that the malicious applets described here pale in comparison with the attack applets described in Chapter 5. Fortunately, the security researchers who discovered those vulnerabilities are the good guys.

Disabling Java

Certainly, many unsavory characters are on the Net, and many of them have created similarly unsavory Web pages. If for some reason you wish to check such sites out, it would be a good idea to disable Java first.

The best way to protect yourself from malicious applets is to create a policy that allows only code you trust to run. It is quicker and easier, however, to disable Java when surfing dangerous Web sites. Much like being street-wise in a big city, your choice to use or disable Java depends on what browsing you will be doing. If you keep to the sites of big business, you are less likely to find dangerous applets, just as the finance districts of New York and Chicago are less dangerous than the housing projects. Know where you are on the Web and take precautions accordingly.

Disabling Java in Netscape Navigator 4.x
Disabling Java under Netscape Navigator 4.x is easy and can be done in the midst of a session. Reenabling Java is also possible, should you change your mind. Figures 4.1 and 4.2 explain how Java can be disabled in Netscape Navigator 4.x.

Figure 4.1 Disabling Java in Netscape Navigator under Solaris.
From the Edit menu, select Preferences. Click on the word Advanced, which will appear in the window entitled "Category" (as shown here). To the right of that window, a series of radio buttons will appear, one of them labeled Enable Java. Click the button so it appears to be sticking out. Finally, click OK, and Java will be disabled.

Figure 4.2 Disabling Java in Netscape Navigator under Windows NT.
From the Edit menu, select Preferences. Click on the word Advanced, which will appear in the window entitled "Category" (as shown here). To the right of that window, a series of checkboxes will appear, one of them labeled Enable Java. Click on the check box, removing the check mark. Finally, click OK, and Java will be disabled.

Disabling Java in Internet Explorer 4.x
Internet Explorer also allows Java to be disabled. Figure 4.3 explains how Java can be disabled in Internet Explorer 4.x.

Figure 4.3 Disabling Java in Microsoft Internet Explorer.
Unfortunately, under MSIE you can only disable Java on a per-zone basis. From the View menu, select Internet Options. Click on the Security tab. Select the zone for which you want to disable Java (for example, the Internet zone). (For more on zones, see Chapter 1.) Then select the Custom radio button and click on the Settings button. A dialog will come up called Security Settings. This is the dialog shown here. Scroll down until you see the Java category. It will have an expanded sub-category called Java permissions. The sub-category will have a list of options. Click on the circle labeled Disable Java, then click OK. You'll then be back at the Security tab. Click OK again, and Java will be disabled.

Snagging Malicious Code

Running malicious code, especially code that explicitly claims to be malicious, is always an interesting conundrum. You may want to check a malicious applet out to see how it works against your machine, but at the same time, you don't want your machine to be compromised by an attack. Although it is advisable to avoid running malicious code at all, some people can't resist. The following strategy may help.

With Java off, surf to the Web page with a suspected malicious applet; for example, the DigiCrime site includes a malicious applet called "bluescreen" at www.digicrime.com/exploits/javawin. A quick look at the HTML source for the page shows that the malicious applet is invoked with the following code snippet:

<APPLET CODE="bluescreen.class" 
CODEBASE="http://www.digicrime.com/surprise" width=1 height=1>

This gives you all the information you need to snag the class file (without running it) and bring it home for dissection.

The next step is to point your browser directly at the class file by opening URL www.digicrime.com/surprise/bluescreen.class. Your browser will display some gobbledygook like Ê_°_me`, which is actually the byte code of the class file as shown in "human readable" form. Use the Save As feature of your browser to save the file bluescreen.class on your disk.

Now that you have the file, you can use a Java decompiler to turn it back into readable Java source code. The once-popular Mocha decompiler is now out of date as its author, Han Peter van Vliet, died an untimely death. However, there are other decompilers available. The best is the SourceAgain decompiler from Ahpah Software. After decompiling the byte code, you can inspect the resulting Java source code for malicious behavior.

Note that the decompilation issue is a complex political football. Laws have been proposed that make decompiling copyrighted code illegal, even if it is done by security researchers for the purposes of code analysis. The intent of the laws is to prevent software piracy, but they are overly broad in their language. The bottom line is to educate yourself about such laws before you begin decompiling code to analyze it.

Once you know what a malicious applet is going to do, you may feel more comfortable running it. Keep in mind that there is no guarantee that the class file that you grab and decompile will be the same as the one you eventually run from a Web site. The Web server can easily be programmed to bait and switch so that it changes the class file that it distributes unpredictably. Unless you run your grabbed copy of the class file from your own Web server, all bets are off.

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help