Although you might not realize it, you are constantly being authenticated. For example, you might have to provide a username and password to use any of the following services:

In fact, today most subscription-based Web sites require a username and password. You’re subjected to high levels of authentication every day. Do you know what that means? The Internet simply doesn’t trust you!

Authenticating humans, therefore, involves a password scheme. Some models employ a simple username/password scheme, whereas others can be more complex, such as challenge-response systems based on one-time passwords. The end result is the same, though—the user either has the correct password or she does not.

Machines can be authenticated in other ways, depending on their trust relationship. For example, a machine can be authenticated by its host name or an IP source address. Using RHOSTS entries is a common procedure in the Unix world for setting this up.

The RHOSTS system can be used to establish a relationship of trust between machines. It’s described in the Solaris Manual Page:

A sample .rhosts file might look like this:

node1.sams.hacker.net hickory 
node2.sams.hacker.net dickory 

This file specifies that the user hickory on node1 and user dickory on node2 are now trusted. These users can access the local machine through the r services without being subjected to password authentication. No other users from these nodes are trusted, however.

To complete the process (and create a two-way trust relationship), all four of the machines must also maintain rhost entries.

The authentication that occurs at connection time, then, is based solely on the IP source address. This is known to be a flawed model, as Steve M. Bellovin explains in his paper “Security Problems in the TCP/IP Protocol Suite”:

The following points have been established for now:

From this, you can surmise one of the reasons why IP spoofing has achieved cult status in the cracker community. Most cracking attacks have historically relied on password schemes; crackers would steal the /etc/passwd file and crack it. They would do their dirty work after obtaining the root password (and at least one user login/password). In spoofing, however, neither a username nor a password is passed during the attack. The security breach occurs at a very discrete level.

Another reason IP spoofing has gained much notoriety is that it can be used as a key element in other forms of attack. One example of this is known as “session hijacking,” which is described in the next section.

These are the essential steps that must be taken in a spoofing attack:

The first four steps are easy. The difficult part is guessing the correct sequence number. To do so, the cracker must execute a trial run:

The cracker next examines the logs of sequence numbers received from the target. In his analysis, he seeks to identify a pattern. He knows, for example, that these sequence numbers are incremented uniformly by an algorithm designed specially for this purpose. His job is to determine that algorithm, or at least determine the numeric values by which the numbers are incremented. When he knows this, he can reliably predict what sequence numbers are required for authentication.

He is now ready to perform the spoofing attack. In all, spoofing is an extraordinary technique. However, what’s even more extraordinary is this: Since 1985, the security community has known that spoofing was possible.

When the connection and authentication procedures are complete, the cracker must create a more suitable hole through which to compromise the system. (He should not be forced to spoof each time he wants to connect.) He therefore fashions a custom hole. The easiest method is to rewrite the .rhosts file so that the now-compromised system accepts connections from any source without requiring additional authentication.

Having done this, the cracker shuts down the connection and reconnects. He can now log in without a password and has control of the system.

IP spoofing can only be implemented against certain machines running certain services. Many flavors of Unix are viable targets. (This shouldn’t give you the impression that non-Unix systems are invulnerable to spoofing attacks. There’s more on that later in this chapter.)

The following are some of the configurations and services are known to be vulnerable:

To put that in perspective, consider this: Most network services use IP-based authentication, and although RPC, X Window System, and the r services have problems inherent to Unix-based operating systems, other operating systems are not immune.

Windows NT and even Windows 2000, for example, are vulnerable to sequence number attacks. Sessions can be hijacked via TCP sequence number guessing. At its heart, the problem is a spoofing issue. It affects a multitude of network services, not just RPC. In fact, it even affects NetBIOS and SMB connections. Exploit code for the attack can be found at http://www.engarde.com/software/seqnumsrc.c.

Spoofing attacks used to be rare. However, they became far more common after January 1995. Consider this Defense Data Network advisory from July 1995:

Prior to 1995, spoofing was a very grass-roots attack. Anyone trying to spoof had to have a very strong background in TCP/IP, sockets, and network programming in general. This is no longer true.

After it was demonstrated that spoofing actually worked (it was previously a theoretical notion), spoofing code immediately began surfacing. Today, prefabbed spoofing utilities are widely available. The following sections present some useful spoofing utilities.

ARP spoofing is a technique that alters the ARP cache. Here’s how it works: The ARP cache contains hardware-to-IP mapping information. The key is to keep your hardware address, but to assume the IP address of a trusted host. This information is simultaneously sent to the target and the cache. From that point on, packets from the target are routed to your hardware address. (The target now “believes” that your machine is the trusted host.)

There are severe limitations to this type of attack. One is that the ruse might fail when crossing intelligent hubs and some routers. Therefore, ARP cache spoofing is reliable only under certain conditions, and even then it might be restricted to the local network segment. Moreover, cache entries expire pretty quickly. Thus, you still have to backtrack periodically and update the cache entries while implementing the attack.

Can ARP spoofing be defeated? Absolutely. There are several things that you can do. One is to write your address mappings in stone. This can, however, be an irritating prospect. Paul Buis explains in his paper “Names and Addresses”:

Another choice is to use ARPWATCH. ARPWATCH is a utility that watches changes in your IP/Ethernet mappings. If changes are detected, you are alerted via email. (Also, the information will be logged, which helps track down the offender.) Get ARPWATCH at ftp://ftp.ee.lbl.gov/arpwatch.tar.gz.

In DNS spoofing, the cracker compromises the DNS server and explicitly alters the hostname-IP address tables. These changes are written into the translation table databases on the DNS server. Thus, when a client requests a lookup, she is given a bogus address; this address is the IP address of a machine that is completely under the cracker’s control.

DNS spoofing has now been automated, at least on some platforms. A utility called Jizz, written by Nimrood (and based on code written by Johannes Erdfelt), does this. To try it out, download it from http://packetstormsecurity.org/Exploit_Code_Archive/jizz.c.

DNS spoofing is fairly easy to detect, however. If you suspect one of the DNS servers, poll the other authoritative DNS servers on the network. Unless the originally-affected server has been compromised for some time, evidence will immediately surface that it has been spoofed. Other authoritative servers will report results that vary from those given by the cracked DNS server.

Polling might not be sufficient if the originally-spoofed server has been compromised for some time. Bogus address-host name tables might have been passed to other DNS servers on the network. If you are noticing abnormalities in name resolution, you might want to employ a script utility called DOC (domain obscenity control). As articulated in the utility’s documentation:

Other techniques that defeat DNS spoofing attacks include the use of reverse DNS schemes. Under these schemes, sometimes referred to as tests of your forwards, the service attempts to reconcile the forward lookup with the reverse. This technique might have limited value. In all likelihood, the cracker has altered both the forward and reverse tables. For more information on configuring your DNS server, see the following sites:

http://www.dns.net/dnsrd/

http://www.cert.org/advisories/CA-1999-14.html

Quite a few sites on the Internet these days require a paid membership to access their content. Often, when you pay for membership at one site, you also get access to other paid content as well. There are several ways this can be implemented. It is easy, however, to implement a setup that is easy to spoof.

Our examples feature a paid membership site called Music By Gus (http://members.musicbygus.com/). All the members of Gus’s site also get free access to the site Music by Alice (http://members.musicbyalice.com/). It should be stressed that you can easily find examples of each of the following setups on the Internet, as they’re all common.