| This section includes several examples of malicious Java code, including annoying applets, applets that break the sandbox, and Java viruses. 10.4.1 Annoying Applets Java programmer Dr. Mark D. LaDue has a web site called the Hostile Applets Home Page (http://www. cigital .com/hostile-applets) dedicated to simple proof-of-concept malicious Java programs. The next two examples of hostile code are taken from Mark's site. 10.4.1.1 Java.NoisyBear Mark's most famous creation, NoisyBear, appears as a picture of a bear with a clock superimposed over his belly. The clock emits an annoying drum noise that will not stop until you close your browser. A malicious applet of this type could be downloaded with the user thinking they are simply getting a picture file. During early speculation surrounding malicious Java applets, it was thought by some that simply moving to a new web page, would make the applet lose control of the browser and stop. Mark's NoisyBear, shown in Figure 10-4, disproved that belief. Figure 10-4. The NoisyBear applet  10.4.1.2 Hostile Thread Java applet This example applet showed how easy it is to let a malicious Java applet activate, but then go into a long delay mode. Security experts fear the release of such hostile applets. By the time the applet goes off and crashes the browser, the user would probably end up blaming something else. The Hostile Thread applet eventually starts an infinite number of high priority threads that eat up system resources and crash either your browser or your system. It contains a delay counter that can be adjusted to vary the "sleep" timer. When downloaded, the applet displays a message saying, "I'm a friendly applet." It then goes into a predetermined delay mode. When it awakes, it begins to play the sound of a dog barking as it executes thread after thread, which eventually locks the browser (and sometimes the whole computer) up. 10.4.1.3 DigiCrime's Irritant DigiCrime ( http://www.digicrime.com ) is a professional hacker site with lots of malicious code. Don't visit it without disabling Java, ActiveX, and any other scripting languages that may be enabled in your browser. DigiCrime's site includes dozens of demonstration programs, some of which don't give you a lot of warning. Although they haven't broken Java's sandbox, what they have done with malicious applets is clever. For example, Irritant.class (see Figure 10-5) opens a new window each time you try to close one and can only be stopped by closing your active browser window. A few times, the growing windows subroutine has continued well after I've closed the browser. When the number of windows becomes too much for Windows to handle, it becomes sluggish and other applications start to malfunction. Figure 10-5. Irritant.class in action  10.4.2 Java Viruses The next few examples were taken from various antivirus web sites around the Internet. 10.4.2.1 Strange Brew Java virus Originating in August 1998, Strange Brew is the first virus written in Java to infect Java programs. When Strange Brew is activated, it searches the current directory for existing class files and adds itself to the new host file. It also adds enough bytes to make the resulting file evenly divisible by 101 to allow the virus to skip over previously infected files when it's checking for new hosts . When the infected class file is run, it passes control to the virus code and the cycle continues. It contains no payload damage routine. 10.4.2.2 BeanHive Java virus The BeanHive is considered the second Java virus and was discovered in January 1999. It is a demonstration Java virus, but contains enough bugs that it doesn't really spread well. Still, it is notable for a few reasons. First, the virus is made up of several different classes, all but one of which are contained in a Java archive file ( .CAB or .JAR ) that is downloaded as a malicious applet. The archive file is digitally signed as belonging to Landing Camel International. If an end user were to accept the digital certificate, his browser would automatically accept future code signed with the same certificate (i.e. the virus author) and not be warned again. After you accept the bogus certificate, portions of the virus class files will infect host files with another "loader" class method. This class will then search on the local system for a final class file, the main virus portion, and if not found, contact the virus author's site (this site, http://www.codebreakers.org , was shut down during the Melissa virus outbreak) and download it from there. Once downloaded, the virus will infect three class files at a time. Although this virus attempts to use Java to construct an interesting distributed malicious code exploit, its complexity and the resulting bugs, ensures that it will fail almost every time. It has never been documented infecting a system in the wild. 10.4.2.3 Hoax Java bombs There are several " joke" Java applets floating around the Internet. After they download, they start displaying fake warning messages indicating that your hard drive is being formatted, a virus is being planted, or some other sort of malicious damage is occurring. Even after they appear to have stopped, they continue to plague the user with more realistic, but fake, error messages. They appear to violate Java's sandbox, but they don't. I have heard of more than one report where a user formatted their hard drive after being tricked. Symantec used to host a popular harmless demonstration applet prank so users could experience how realistic they could be. Figure 10-6 shows its screen output. Figure 10-6. Symantec's hoax Java applet  10.4.3 Compromising Intrusions The next three Java exploits were taken as a sample from Princeton University's Secure Internet Programming web site at http://www.cs.princeton.edu/sip/History.html. The attacks described in this section represent the more serious security breaches as they focus on violating the Java sandbox. 10.4.3.1 DNS subversion trick One of the central tenets of Java's Security Manager is that an untrusted applet can only connect back to the computer from which it came, and cannot initiate or listen for new connections. Princeton's Safe Internet Programming Team discovered a weakness in February 1996, that could allow a malicious applet to connect to a new host. A common hacker trick, called DNS Spoofing, is often used to bypass firewalls that deny access based on IP address. Domain Name System (DNS) servers convert hostnames (ex. http://www.java.sun.com) into physical IP addresses, which the Internet uses to establish connections. DNS spoofing is accomplished by hackers using a rogue DNS server with incorrect address translation tables that fool the victim's computer into thinking a particular hostname is related to another IP address that it doesn't belong to. In this exploit, the hacker's rogue DNS server returns two or more IP addresses as being related to one hostname (this can actually be the case and isn't always foul play). When the cooperative malicious applet asks to connect to its "host" computer it lists a new (not source) IP address that was returned by the rogue DNS server. Java's Security Manager compares the new IP address and finds it listed in the DNS entry for the original host's domain name entry and allows the connection request to the new server. This bug only impacted Netscape's Navigator 2.0, but shows one of the complicated interactions that Java can have with a PC. 10.4.3.2 Bug in the Java Byte Code Verifier The Princeton team scored another big victory in March of 1996 with a serious full system compromise exploit in the Verifier portion from Java's 1.0 and 1.0.1 SDK. Although the details were never publicly released, the bug allowed a malicious applet to execute any program or command it wanted under the security rights of the end user's credentials. This bug had such serious consequences that CERT recommended disabling Java and JavaScript if you didn't need it. A related bug was found in May of that year and not fixed until Internet Explorer 3.0 beta2. 10.4.3.3 Microsoft Virtual Machine Verifier vulnerability In early October 1999, Karsten Sohr, from the University of Marburg in Germany, reported a vulnerability with all of the current versions of Microsoft's Internet Explorer. By the end of the same month, Microsoft had released a JVM upgrade to eliminate this vulnerability. The bug allowed a malicious coder to "hand-compile" a hostile applet that would get past Microsoft's JVM security. No legitimate Java compiler could produce the threat (because of Java's built-in security), but Sohr had discovered a way and Princeton's security team wrote an applet that demonstrated the new exploit. Once past security, the hostile applet could do anything it wanted to, limited only by the user's security rights. It could delete files, format hard drives , and download files. The malicious Java applet accomplishes its exploit by containing byte codes in a particular order that confuses the JVM and allows it to change its type, from private (confined within the sandbox) to public (with full access to the local system). Internet Explorer's JVM continues to be plagued with security holes as evidenced by Microsoft Security Bulletins MS00-0011 and MS00-0081 . They announced Java exploits where an untrusted malicious Java applet could operate outside the safety of the security sandbox. In both cases, a malicious hacker could read the contents of any user's file, but not modify, change, or delete it. Microsoft recommends all Internet Explorer versions use the latest available JVM. You can usually find it at http://www.microsoft.com/java. 10.4.4 Plug-ins Plug-ins are programs that can be attached to a web browser to extend its default capabilities. Plug-ins are often used to manipulate a particular type of media object, such as a video stream or audio clip. Real Network's popular Real Player  plug-in allow users to see and hear real-time video clips, radio stations , and television channels. Apple's QuickTime and Macromedia's Shockwave plug-ins are Internet standards for viewing all types of video media. Once accepted and installed, plug-ins have complete access to a system's resources and are not limited to a sandbox security model. A plug-in potentially disrupts the security model of anything it comes in contact with. This was demonstrated by the Windows Media Player skin exploit covered in Chapter 9. Java can be embedded in other objects used in a plug-in application and be executed as trusted code. In March 1997, an exploit was demonstrated using Macromedia's Shockwave and Netscape Navigator's email (it could affect other email systems, like Eudora). Shockwave is installed on more than 20 million users' desktops and is one of the most popular browser add-ons in existence. Its main purpose is to play movie files. David de Vitry, a programmer, found a bug (http://www.webcomics.com/shockwave) in the way that Shockwave retrieved and played files. Using the exploit, a hacker could post a malicious Shockwave file that retrieves a user's email messages, including deleted ones, and sends them back to a hacker's site. Later on, another developer, Dave Yang, demonstrated another similar Shockwave vulnerability that allowed a Shockwave file to download any known file from a user's system. The downloading occurs in the background without the user knowing it. Macromedia eventually fixed these bugs and no known exploits were documented in the wild. These particular exploits would have no problem getting by malicious code-detecting firewalls, and just confirmed what security experts knew all along: plug-ins are another security vulnerability. There are sure to be more plug-in exploits found in the future. | 
