In the first problem, an attack applet launches network security attacks on other machines. This is something that an attacker could already do before Java came along. The twist is that by embedding the attack into an applet, the bad guy makes the attack come from the machine of an innocent bystander. Example: You're sitting at your desk, happily browsing the Web, and without realizing it, your machine is trying to penetrate the security of a machine down the hall. This kind of confusion is reason enough to use Java as the penetration vehicle, but the culprit has an even better reason for using Java. Many corporate networks protect themselves from Internet intrusion through the use of a firewall. (See Figure 5.1.) If your firewall is well configured, it prevents the mischievous cracker from making direct use of the network to probe the defenses of your machines. The firewall does this by blocking certain types of network traffic from entering the corporate network.
A Java applet, though, doesn't look suspicious to most firewalls. (This was more true in 1997 than it is today. We discuss the state of the art in applet blocking in Chapter 6, "Securing Java: Improvements, Solutions, and Snake Oil.") Many firewalls examine the type of packet, not the contents of the packet. For some firewalls, to block Java applet traffic, a system manager would have to block all Web traffic.1 The fact that your browser requested the applet makes the firewall's job that much trickier. If the applet can open network connections to other machines, it can connect from your machine to another machine behind the firewall. In the current case, the attack originates from the inside rather than the outside. Since the firewall only filters traffic coming from the outside, it is helpless to prevent this sort of attack. This is especially dangerous since many sites have strong firewall protection, but almost no protection against attacks from the inside. In security circles, these sites are jokingly referred to as "crunchy on the outside and chewy in the middle." The people who designed Java-enabled browsers thought of the possibility of inside-the-network attacks, so they made a security rule to prevent it. The rule states: An applet may not open a network connection, except back to the server from which it came.If enforced properly, this rule stops any network probing by applets. Netscape Navigator 2.0 did not enforce this rule properly. In order to understand what went wrong, you need to understand how machines are named on the Internet.
Like people, machines on the Internet need to have names to identify them. Specific names help machines send messages across a network. These names are also numeric addresses. Because these numbers are often difficult to remember, there are two layers of network addressing in the Internet. The Internet Protocol (IP) uses only numeric addresses to communicate between machines. The Domain Name System (DNS) keeps track of how the user-friendly names correspond to the IP numbers used to establish a machine's low-level connections. An IP address is just a number. For example, the Web server at JavaSoft has this numeric address: 11001110000110100011000001100100 in binary notation. IP addresses are often written in decimal form, which looks like 206.26.48.100. When the computers that make up the Internet talk to each other, they identify themselves with the numeric IP addresses. Computers deal naturally with numbers like this, but they are, to say the least, not very user-friendly. The other sort of Internet names, DNS names, are made for people. They look like java.sun.com, or sandbox.rstcorp.com. These names are made up of often intelligible words strung together with dots to separate them. DNS divides the world up into domains like sun.com (Sun Microsystems) and cs.princeton.edu (the Princeton University Computer Science department). Each domain corresponds to a single administrative entity. It is up to that entity to define names that end in its domain name. For example, the cs.princeton.edu domain is free to define names like elvis.cs.princeton.edu. Anyone can create his or her own domain by registering with an organization called InterNIC and paying a modest fee. The owner of each domain is responsible for providing two DNS server machines that respond to queries about DNS names inside that domain. For example, if someone wants to know the IP address of elvis.cs.princeton.edu, he or she can ask one of the DNS servers for cs.princeton.edu. A single DNS name might refer to several IP addresses. There are two reasons for this. First, a machine might be connected to more than one network, with a separate IP address for each of its connections. Second, there might be several machines providing the same service. For example, espn.sportszone.com might actually correspond to several machines, all providing identical services. Sometimes several DNS addresses refer to the same IP address. For example, a company's Web server www.rstcorp.com and its FTP server ftp.rstcorp.com might actually be the same machine. This makes sense because management might later want to move the two functions onto separate machines. Using two separate names allows them to keep this flexibility.
To enforce the rule that an applet can connect only to the server from which it originated, the implementers of Java needed a way to check whether the machine an applet wanted to reach was the same as the machine that the applet came from. They did this as follows:
The following scenario describes what can go wrong. Figure 5.3 shows the scenario visually.
Imagine that a bad guy wants to attack a machine called target.victim.org, with the IP address 10.10.10.2. The bad guy sets up a Web server called www.attacker.org, with IP address 172.16.16.16; then he waits. An unsuspecting person, surfing the Web on stooge.victim.org (IP address 10.10.10.1), happens to visit the attacker's Web site. The site contains a Java applet written by the attacker. The applet is downloaded to stooge.victim.org and run. The applet asks to create a network connection to bogus.attacker.org. Because that name is in the attacker.org domain, the attacker's DNS server is asked to provide an IP address for that machine and is free to provide any IP addresses it likes. The attacker's DNS server slyly returns the pair of addresses (10.10.10.2, 172.16.16.16). Because that list contains the address of the attacker's Web server (172.16.16.16), Java erroneously concludes that www.attacker.org and bogus.attacker.org are really the same machine, so it allows the connection to go ahead. Unfortunately, after verifying the connection is allowed, Java connects to the first address on the list, 10.10.10.2, or target.victim.org. The attacker has achieved his goal: to connect to the target machine. What does the attacker do next? The attacker can systematically probe the defenses of the target machine, looking for weaknesses. Sophisticated tools such as SATAN, Ballista, and ISS even exist to automate this part. If the attacker finds a weakness, the victim could be in big trouble.
This problem was fixed by simply changing the criterion by which Java decides to allow a connection. The new approach is to store the IP address of the Web server, and allow a connection only to that IP address. This simple and complete solution is implemented in Netscape Navigator versions beginning with 2.01 and all Java-enabled Microsoft Internet Explorer versions. It is no longer possible to jump the firewall with Java using the DNS bug; however, it is important to make sure that you are not using the unpatched Netscape 2.0.
The announcement of this flaw triggered a flurry of press reports, beginning with a story in USA Today. Reporters learned of the flaw from a brief message in the comp.risks forum. The discoverers of the attack were surprised to learn that many reporters monitor comp.risks. It turned out that the existence of this flaw had been postulated independently by Steve Gibbons about four weeks before the announcement. Steve Gibbons had reported the bug to Sun Microsystems, but it was not fixed. After the USA Today article, Sun Microsystems and Netscape said they would fix the bug within days. It was fixed quite quickly. The security researchers who uncovered the DNS attack were surprised to see that the press treated the news as a business story rather than as a technical story. This was probably a naïve point of view. These days, technology reporting, even when discussing noncommercial technology, seems to be considered a branch of business reporting. It was also surprising to see that many news organizations repeated a story that they had read elsewhere without contacting the parties involved and apparently without reconfirming any of the facts! As usual, when information is heard and then repeated, small inaccuracies creep in at each stage. It was sometimes possible to figure out who had copied the story from whom, by tracking small inconsistencies. The USA Today story also triggered a blip in the stock market. Netscape's stock price dropped significantly on the day the story appeared. CNN and the Nightly Business Report attributed the drop to the announcement of this flaw, although there were other factors (for example, the expiration of the post-IPO embargo on insider sales) also driving down Netscape's stock that week. In any case, the stock bounced back when it became clear that the product was not irretrievably broken.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
