Misdirecting IP Datagrams from Hosts

If a machine is a passive participant in the RIP protocol—it listens to RIP broadcasts and uses them to update its routing table—one simple way to route spoof is to broadcast illegitimate route information via UDP on port 520. On a typical Unix system, port 520 is numbered so low that special privileges are required to access it. However, it is possible for almost any personal computer user and anyone with special privileges to use RIP to mount a route spoofing attack on all the passive participants in RIP on a network. A particularly serious situation arises if routers are passive participants in RIP, using it as an internal routing protocol. If so, RIP propagates the illegitimate information throughout a company’s portion of the Internet and the damage can be widespread.

A Case Study of a RIP-Based Route Spoof

To illustrate such an attack, assume everyone at the university is well-intentioned and the network seems to be normal. The network as well as the major multiuser systems and many network servers are managed by Central Computing. The university has so many individual systems, however, that some departments, such as Computer Science, have a separate system administration staff. Each departmental system administration staff is responsible for a set of networked hosts and is capable of installing network wiring without the knowledge of Central Computing. Presumably, the Computer Science staff has enough common sense not to modify the wiring installed by Central Computing. Occasionally, however, Computer Science chafes at what seem to be unreasonable policies imposed by Central Computing.

As you can imagine, Computer Science came up with the brilliant idea of installing a network that does not use the wiring installed and maintained by Centralized Computing. After all, Computer Science will have to pay Central Computing to install a network, so why not control the network after it is installed? Of course, the network installation crew is months behind as it is. Network administration does not seem that hard and does not seem particularly distinct from system administration, so the Computer Science staff takes the plunge and tries to do it themselves. They are successful and the new network works wonderfully—they are proud of their work.

The problem comes when the Computer Science head points out that it would really be nice if the new Computer Science network would communicate with the Central Computing net-work. The solution is obvious to the Computer Science staff: install a router between the Computer Science network and the Central Computing network. The Computer Science staff can control the new router and use RIP to advertise connectivity between the Central Computing network and the Computer Science network. They spend a few dollars on a new network card for one of their workstations and it becomes a router.

At first, the system works fine. The Central Computing routers recognize the availability of the new Computer Science network and forward datagrams in both directions via the newly installed departmental workstation/router. Then, one day, a departmental staff member decides to reconfigure the workstation and makes a small mistake. He inadvertently changes the IP address of the interface connecting the workstation to the Computer Science network. His error prevents machines on the Computer Science network from being able to send IP datagrams to the workstation/router because it no longer responds to their ARP requests. Computer Science’s use of the Central Computing network is light and network failures on the Central Computing network are common, so no one in Computer Science immediately becomes worried when they can no longer communicate.

This mistake, however, causes much more severe problems than anyone could have predicted. The IP address installed on the Computer Science router makes it appear to belong to a subnet of the Central Computing network. This subnet is really in a building on the far side of campus with several Central Computing routers in between Computer Science and the router in the building with this Central Computing subnet. The Computer Science workstation/router begins advertising, via RIP, its direct connection to this subnet with a zero hop count. The nearest Central Computing router decides that it can get to this subnet with a hop count of one via the Computer Science workstation/router instead of using the next Central Computing router that says it has a hop count of three to the subnet in question. The next centrally controlled router gets a RIP broadcast from the first and decides to begin routing datagrams for this subnet through the first.

Within minutes, a large portion of the network can’t communicate with the Computer Science network or the Central Computing subnet associated with the misconfigured IP address. These subnets, however, are used by the main multiuser computers and the off-campus Internet link. Complaints are registered with Central Computing from both directions: Computer Science complains its connection to Central Computing is down and the users in the building across campus complain that their link to the multiuser computers and the Internet is down. Initially, the two problems are seen as separate failures because they involve networks in widely separated buildings. The problem was eventually discovered when the routing tables of the routers were examined. To solve the problem, Central Computing made a manual entry in the routing table of the router closest to Computer Science and solved half of the problem. Computer Science fixed the address on its router and solved the other half.

The poor Computer Science system administrator who mistyped a single digit when working on the workstation/router is then chastised. Afterward, Central Computing figures out that someone might do such a thing on purpose, compromising the stability and security of the network.