This chapter will examine spoofing attacks, how they work, and how to defend against them.
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:
The important parts of the TCP header are a source port number, a destination port number, a sequence number, an acknowledgement number, and some flags. The port numbers identify which virtual circuit is involved, the sequence and acknowledgement numbers ensure that data is received in the correct order, and the flags affect the state of the virtual circuit. An IP header consists primarily of source and destination host identifiers; these are 32 bit numbers which uniquely indicate a hostand a network.
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:
4.2BSD provides a remote execution "server", which listens for TCP connection requests on port 514. When such a request arrives at a machine, the server checks that the originating host is "trusted" by comparing the source host ID in the IP header to a list of trusted computers. If the source host is OK, the server reads a user id and a command to execute from the virtual circuit TCP provides. The weakness in this scheme is that the source host itself fills in the IP source host id, and there is no provision in 4.2BSD or TCP/ IP to discover the true origin of a packet.
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:
The /etc/hosts.equiv
and .rhosts
files provide the "remote authentication" database for rlogin
(1), rsh
(1), rcp
(1), and rcmd
(3N). The files specify remote hosts and users that are considered "trusted". Trusted users are allowed to access the local system without supplying a password.
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 sequence number is used to acknowledge receipt of data. At the beginning of a TCP connection, the client sends a TCP packet with an initial sequence number, but no acknowledgment (there can't be one yet). If there is a server application running at the other end of the connection, the server sends back a TCP packet with its own initial sequence number, and an acknowledgment: the initial sequence number from the client's packet plus one. When the client system receives this packet, it must send back its own acknowledgment: the server's initial sequence number plus one.
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:
4.2BSD maintains a global initial sequence number, which is incremented by 128 each second and by 64 after each connection is started; each new connection starts off with this number. When a SYN packet with a forged source is sent from a host, the destination host will send the reply to the presumed source host, not the forging host. The forging host must discover or guess what the sequence number in that lost packet was, in order to acknowledge it and put the destination TCP port in the ESTABLISHED
state.
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).
Vulnerability to this technique varies from platform to platform. Some are more (or less) susceptible depending on how predictable their random number generator is. Although Linux has a better random-number generator than most, this alone will not defeat a determined cracker.
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
.
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.
My test environment involved three machines:
172.16.0.1
—A Silicon Graphics Indigo, the target.
172.16.0.2
—A Linux AT, the attacking machine.
172.16.0.3
—A Linux AT, the host whose address I spoofed.
172.16.0.1
(the target) had a hosts.equiv
file, allowing rsh
traffic from 172.16.0.3
:
# /etc/hosts.quiv localhost 172.16.0.3
My object was to execute an rsh
command on 172.16.0.1
as a user from 172.16.0.3
while actually logged into 172.16.0.2
. mendax
makes this task easier via a command function. If mendax
finds that the target host is vulnerable, it will execute any command of your choice on it. By default, Mendax sends this one:
mv .rhosts .r; echo + + > .rhosts
This command either creates a new .rhosts
file or clobbers an existing one on the target. Either way, the end result is an .rhosts
file on the target that will let anyone from any host log in.
On 172.16.0.2
, I issued this command:
[root@linux6]# mendax -p 514 172.16.0.3 172.16.0.1 -l mikal -r mikal
This instructed mendax
to spoof an rsh
request from 172.16.0.3
to rshd
at 172.16.0.1
as user mikal
. To perform this task, mendax
first incapacitated 172.16.0.3
so that it wouldn't answer packets from the target:
flooding source with TCP SYN packets from 143.209.4.3:
Next, mendax
analyzed sequence number generation from 172.16.0.1
:
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
And finally, after making an educated guess about sequence number incrementation, mendax
spoofed rshd
and attempted to execute the command:
using 64000 as prediction difference (3 hits). spoofing rshd. resetting TCP target connection: . resetting source: .................... [root@linux6]#
Did it work? You bet. A new file appeared in user mikal
's directory on 172.16.0.1
:
$ls -l .r* -rw-r--r-- 1 mikal user 4 Jun 22 08:31 .rhosts
Here are the file's contents:
++
From that point on, 172.16.0.1
was wide open to full-on attack, but here's the interesting part—the target logged the connection as a rshd
request from 172.16.0.3
:
6 Jun 22 08:30:29 GNSS rshd: [email protected] as mikal
As you can see, Morris was quite right. The source address isn't reliable after all. The preceding log entry shows absolutely no evidence of an attack from 172.16.0.2
.
If you'd like to experiment with IP spoofing or learn how spoofing utilities are designed, get the following tools.
Author: Brecht Claerhout
Language: C
Required: C, net includes
Location: http://www.firosoft.com/security/philez/utilities/iptools/spoofit.h
Description: spoofit.h
is a nicely commented library for including IP spoofing functionality into your programs.
Author: Mike Neuman (En Garde Systems)
Language: C
Required: C, net include files
Location: http://sunshine.sunshine.ro/FUN/New/hacking/seq_number.c
Description: A TCP sequence number exploit for use in spoofing. The source is also exceptionally well commented (a great study aid).
Author: Unknown
Language: C
Required: C, netinet includes
Location: http://www.ryanspc.com/spoof/ipspoof.c
Description: ipspoof
is a straight-ahead IP and TCP spoofing utility.
Author: Vasim V.
Language: C
Required: C, net includes
Location: http://www.insecure.org/sploits/ttcp.spoofing.problem.html
Description: A TTCP spoofing utility that allows attackers to execute commands even before the full TCP handshake is complete. (Note that this only affects hosts running TTCP. For information on TTCP, please see the Linux Ethernet HOWTO.)
Also, check out hunt
, a sniffer that offers various spoofing functions, in Chapter 7, "Sniffers and Electronic Eavesdropping."
Please use the aforementioned tools responsibly.
IP spoofing affects only certain machines running certain services. Configurations and services known to be vulnerable include
To put it in perspective, consider this: Most network services use IP-based authentication. And while RPC, X, and the r
services are UNIX-centric, other operating systems are not immune. Certain unpatched releases of Windows NT, for example, are vulnerable to sequence number attacks. (Sessions can be hijacked via TCP sequence number guessing.)
These problems aren't limited to operating systems, either. Consider BorderWare, popular firewall software for Novell NetWare. Early releases used a 64KB-incrementation pattern for sequence numbers. (These releases assign each connection an initial sequence number 64,000 higher than the last and then increment this number 128,000 for each subsequent second.) This pattern was well known to crackers, and its existence made BorderWare vulnerable to attack.
But a spoofing attack needn't result in authentication and login to cause problems. Some spoofing attacks are ingredients in wider attacks with a different focus. For example, in October 1998, CIAC reported a Windows NT RPC spoofing attack that could lock two servers in a loop:
(From CIAC Information Bulletin J-001: Windows NT RPC Spoofing Denial of Service Vulnerability,at http://ciac.llnl.gov/ciac/bulletins/j-001.shtml.)
Such "looping" attacks are quite annoying and are often operating-system-neutral. Particularly insidious examples (which sometimes enlist network hardware) are UDP and ICMP flooding. In RFC 2267, P. Ferguson and D. Senie discuss several such attacks and means of preventing them. They wrote:
The former attack (UDP flooding) uses forged packets to try and connect the chargen
UDP service to the echo
UDP service at another site. Systems administrators should NEVER allow UDP packets destined for system diagnostic ports from outside of their administrative domain to reach their systems. The latter attack (ICMP flooding), uses an insidious feature in IP subnet broadcast replication mechanics. This attack relies on a router serving a large multi-access broadcast network to frame an IP broadcast address (such as one destined for 10.255.255.255) into a Layer 2 broadcast frame (for Ethernet, FF:FF:FF:FF:FF:FF). Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen to a select number of addresses in normal operation. The one MAC address that all devices share in common in normal operation is the media broadcast, or FF:FF:FF:FF:FF:FF. In this case, a device will take the packet and send an interrupt for processing. Thus, a flood of these broadcast frames will consume all available resources on an end-system.
(From Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing, Request for Comments 2267, P. Ferguson, Cisco Systems, Inc. ftp://ftp.isi.edu/in-notes/rfc2267.txt).
For these reasons, IP source address spoofing is a major concern (one often overlooked in otherwise well-secured environments). Let's look at some techniques to foil such attacks.
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:
Good sequence numbers are not a replacement for cryptographic authentication. At best, they're a palliative measure. An eavesdropper who can observe the initial messages for a connection can determine its sequence number state, and may still be able to launch sequence number guessing attacks by impersonating that connection.
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
Configuring your network (at the router) to reject packets from the Net that claim to originate from a local address. (Note that you may have to explicitly enforce these rules. Merely running a firewall does not automatically protect you from spoofing attacks. If you allow internal addresses access through the outside portion of the firewall, you're still vulnerable.)
If Linux is your face to the world and your internal network runs Windows or Novell, consider stopping TCP at the firewall. That is, allow incoming connections to your mail server, but provide in-house workstations with IPX-based connectivity for retrieving mail.
If you do allow outside connections from trusted hosts, enable encryption sessions at the router. This will prevent attackers from capturing network traffic for sampling (and prevent them from authenticating themselves).
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.
ARP stands for Address Resolution Protocol. ARP resolves IP addresses to physical addresses. When a host wants a session, it sends out an ARP broadcast carrying the IP address of its desired target. However, for convenience's sake, the system provides an ARP cache so that machines can quickly connect to known hosts without performing a broadcast. It is this cache that attackers compromise in ARP spoofing attacks. (The ARP cache contains hardware-to-IP mapping information.)
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.
Hardware addresses (also called media access control addresses) are unique values, burned into your Ethernet adapter by the manufacturer, that identify your physical network interface. They consist of 48-bit (12-character) values. Here's a typical hardware address: 00-10-BB-72-AA-73
.
To find your hardware address in Linux, use the ifconfig
utility. In Windows 95/98, open a command prompt and issue the command winipcfg
. Finally, in Windows NT, choose START | PROGRAMS | ADMINISTRATIVE TOOLS | WINDOWS NT DIAGNOSTICS | NETWORK | TRANSPORTS
. Note that hardware addresses are permanent, irrespective of whether your IP address changes (although hardware address spoofing is possible in certain cases, particularly on Novell NetWare).
To learn more about hardware addresses, see Eric Brager's Hardware Address HOWTO, located at http://network.uhmc.sunysb.edu/hdw_addr/.
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.
There are several ways to defeat ARP spoofing, but the most effective is to write your address mappings in stone. Unfortunately, as Paul Buis explains in his paper Names and Addresses, this can be tiresome and time-consuming:
Many operating systems do however have provisions for making entries in the ARP cache "static" so they do not time out every few minutes. I recommend using this feature to prevent ARP spoofing, but it requires updating the cache manually every time a hardware address changes.
Notwithstanding the extra time spent, though, the effort is well worth it. The easiest way to set static ARP tables is at the router. However, if you don't have a router, you can still do so with the arp
command.
arp
allows you to interactively manipulate the arp
cache. Table 9.1 summarizes arp
command-line options and what they do.
Table 9.1. arp
Command-Line Options
To establish static arp
mappings, use either the –s
or –f
options. The –s
option is most suitable when you alter just a few entries:
-s hostname hardware_address
Otherwise, if you intend to commit many entries, create an arp
translation table file (typically /etc/ethers
) and call arp
with both the -f
option and the filename.
Finally, one good additional measure to get ARPWATCH, a utility that watches changes in your IP/Ethernet mappings. If changes are detected, you will be alerted via email. (Also, the information will be logged, which helps in tracking down the offender.) Get ARPWATCH at http://ftp.su.se/pub/security/tools/audit/arpwatch/arpwatch-1.7.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 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:
Although you might be willing to accept the risks associated with using these services for now, you need to consider the impact that spoofed DNS information may have… It is possible for intruders to spoof BIND into providing incorrect name data. Some systems and programs depend on this information for authentication, so it is possible to spoof those systems and gain unauthorized access.
(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:
Author: Unknown
Language: C
Required: C, net includes
Location: http://bob.urs2.net/computer_security/152cscripts/jizz.c
Author: Johan and Dioxide
Language: C
Required: C, net includes
Location: http://www.geocities.com/SiliconValley/Peaks/7837/explo/any-erec.txt
Author: Doc_Chaos [RoC]
Language: C
Required: C, net includes, dig
Location: http://www.c0p.org/security/feb/snoof.tgz
Description: snoof
is a DNS spoofing utility.
One interesting document that addresses a possible new technique of DNS spoofing is "Java Security: From HotJava to Netscape and Beyond," by Drew Dean, Edward W. Felten, and Dan S. Wallach. The paper discusses a technique whereby a Java applet makes repeated calls to the attacker's machine, which is in effect a cracked DNS server. In this way, it is ultimately possible to redirect DNS look-ups from the default name server to an untrusted one. From there, the attacker might conceivably compromise the client machine or network.
("Java Security: From HotJava to Netscape and Beyond" is located online at http://www.cs.princeton.edu/sip/pub/oakland-paper-96.pdf.)
DNS spoofing is fairly easy to detect. 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 may not be sufficient if the originally spoofed server has been compromised for some time. Bogus address-hostname tables may have been passed to other DNS servers on the network. If you are noticing abnormalities in name resolution, you may want to employ a script utility called DOC (domain obscenity control), as articulated in the utility's documentation:
DOC (domain obscenity control) is a program which diagnoses misbehaving domains by sending queries off to the appropriate domain name servers and performing a series of analyses on the output of these queries. DOC is available online at ftp://coast.cs.purdue.edu/pub/tools/unix/doc.2.0.tar.Z.
Other techniques to defeat DNS spoofing attacks include reverse DNS schemes. Under these schemes, sometimes referred to as tests of your forwards, the service attempts to reconcile the forward look-up with the reverse. This technique may have limited value, though. With all likelihood, the cracker has altered both the forward and reverse tables.
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.
Author: Rootshell
Language: C
Required: C, net includes
Location: http://24.92.91.91/Members/pROcon/exploits/spoofscan.txt
Description: spoofscan
is a hybrid utility. It implements port scans using a spoofed source address.
Author: Eric Hanson, Sam Fortiner, Hans Buchheim, and Richard Patchett
Language: C++
Required: C++ (g++), net includes
Author: Gamma '98
Language: C
Required: C, net includes
Location: http://www.jabukie.com/Unix_Sourcez/syslog-poison.c.html
Author: Wolvesbane
Language: C
Required: C, net includes
Location: http://www.geocities.com/SiliconValley/Sector/8208/ICQHack.htm
Description: A utility that spoofs ICQ, allowing attackers to hijack sessions, change user passwords, and spoof messages.
Author: Seth McGann
Language: C
Required: C, net includes
Location: http://www.hotmanscave.com/filez/icqspoof.c
Description: A utility that spoofs ICQ. It allows attackers to send messages that appear to originate with arbitrary user ID numbers.
Author: Kit Knox
Language: C
Required: C, net includes
Author: Yuri Volobuev
Language: C
Required: C, net includes
Location: http://www.martnet.com/~johnny/exploits/network/syslog_deluxe.c
Author: Greg Miller
Language: C++
Required: C++
Location: http://www.fastlane.net/homepages/thegnome/faqs/netware/a-02.html
Description: A program that spoofs Novell Netware's bindery mode login protocol. (Good for versions 3.x and 4.x.)
Author: Johan
Language: C
Required: C, net include files
Location: http://www.firosoft.com/security/philez/utilities/c/sirc4_tar.tar
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.
18.226.177.86