10.5 Detecting Malicious Java Applets | Malicious Mobile Code: Virus Protection for Windows (OReilly Computer Security)


Team-Fly

	Malicious Mobile Code: Virus Protection for Windows By Roger A. Grimes Slots : 1
	Table of Contents

	Chapter 10. Malicious Java Applets

10.5 Detecting Malicious Java Applets

Detecting a malicious Java applet without an automated detection tool isn't easy unless you are a Java programmer.

Disable Internet access: If you suspect a malicious Java applet, disable Internet or network access to prevent the spread of potential damage.
Use an antivirus scanner or detection tools: Your first step after disabling Internet access should be to use a reliable antivirus scanner to look for malicious code.
Review saved Java applets: You can list the Java applets (and ActiveX controls in Internet Explorer) that are installed with your browser. If you take the time to look, you might be surprised. Internet Explorer lists the following information about each object:

Name and type of object
Company that made the object (optional)
Size , GUID, and version
Time and date created
Time and date last accessed
Physical location of object
Package archive file it came from (i.e., .ZIP , .JAR , .CAB , etc.)
Name spaces used for Java applets
File dependencies needed to run

To access the object list in Internet Explorer 5.x, choose Tools InternetOptions General Settings View Objects. You can then select an object and choose File Property to view specific object information. Figure 10-7 shows a list of Java and ActiveX objects stored in my Internet Explorer browser.

Choose File Show All Files menu options to display all files, if offered .

Figure 10-7. List of Java and ActiveX objects

View Java activity: Microsoft included two Java troubleshooting utilities that allow for the viewing of browser- related Java: a log file and a runtime console. The log file captures Java executions and errors. The console reads the log file and makes it easy to view the log in real-time. You enable either tool in Internet Explorer by choosing Tools Internet Options Advanced, and checking Java logging enabled and Java console enabled. Then stop and start the browser to let your changes take effect. The Java log, JAVALOG.TXT , is located at C:\%WINDIR%\JAVA , and can be read with an file text editor.

As with any diagnostic log in Windows, JAVALOG.TXT can take up all available space on your hard drive if it isn't monitored .

The log records applet errors (as often produced with malicious code) and applet names and locations, but there are lots of caveats. First, it doesn't record everything. I've run lots of applets that don't appear in the log, but fortunately, every malicious applet I've run remotely does. Second, the log file captures only the Java traffic of the current session. Stop and restart the browser and a new log file is written over the previous log when the first applet is detected . You should rename your logs right after you close your browser.

The Java Console can be viewed within your browser by choosing View Java Console or by typing in JAVASCRIPT: in the URL location and hitting Enter. Unlike the log file, this tool will reveal real-time happenings and events that will eventually be written to the log. It has a small menu of commands that can be used to see how many execution threads are running and how much memory the applet is taking up. Information you request through the Java Console will be recorded into the log file.

Example 10-5 was produced in the Java log from Mark LuDue's AppletKiller, which is an applet that stops, and prevents , any other applets from running. I use the log to track Java activity when a client suspects an active content exploit. Unless you are a Java programmer, most of what is contained in the log will not make sense. In this example, the code phrases, AppletKiller and ThreadKiller, should be warning signs to anyone . Although it might sound like a neophyte recommendation, malicious mobile code often contains visible text strings that give away its true intent.

Example 10-5. Java log results from AppletKiller

 com.ms.security.SecurityExceptionEx[ThreadKiller.killAllThreads]:  Illegal ThreadGroup access. at com/ms/security/permissions/ThreadPermission.checkThreadGroup at com/ms/security/permissions/ThreadPermission.check at com/ms/security/PolicyEngine.shallowCheck at com/ms/security/PolicyEngine.checkCallersPermission at com/ms/security/StandardSecurityManager.chk at com/ms/security/StandardSecurityManager.checkAccess at java/lang/ThreadGroup.checkAccess at java/lang/ThreadGroup.getParent at ThreadKiller.killAllThreads at AppletKiller.run at java/lang/Thread.run

Inspect suspected malicious code: This recommendation is for programmers comfortable with writing and disassembling code. Before I surf a suspicious web site, I turn off automatic downloading of active content. Then I choose, View Source to inspect the HTML source code of the page. There, I can usually find the tag (one of the three listed earlier) that pulls the Java applet into my browser. Sometimes the HTML coding will reveal maliciousness in comment lines or filenames. If I see a file called damagehdd.class or a comment saying, "Wait till the sucker gets a load of this!" it raises the appropriate suspicions. If I want to review what the suspicious file might do, I will capture and decompile it.

I can then point my browser to the exact location as referenced previously in the CODEBASE parameter. Sometimes relative location names are used and make it a bit harder to grab the code. But if done successfully, my browser's window will look a little funny as it now contains the executable code displayed as data. Using File Save As, I save the file to my local hard drive for further analysis. In this example, I would use a decompiler program to turn the byte code into readable source code. I then look for suspicious subroutines. I'm not a Java programming expert, but I can usually pick up a bit of what the code is doing just by browsing my way through. Subroutines that contain offensive language, names of death, the words, "kill" or "die," all arouse my suspicion. Be careful not to accidentally run the executable content that is now on your hard drive, as it may now be trusted.

As I said at the beginning of this chapter, manually detecting malicious Java applets can be tough unless you know the Java programming language well. Removal is typically easier because there is not a lot you can do. You can either delete the offending code or start from scratch.


Team-Fly

Top