Chapter 7. Spoofing Attacks

IN THIS CHAPTER

·        What Is Spoofing?

·        Internet Security Fundamentals

·        The Mechanics of a Spoofing Attack

·        Documents Related Specifically to IP Spoofing

·        How Do I Prevent IP Spoofing Attacks?

·        Other Strange and Offbeat Spoofing Attacks

In this chapter you learn about spoofing attacks—how they are performed and how you can prevent them.

What Is Spoofing?

The secret to creativity is knowing how to hide your sources.

—Albert Einstein

Spoofing can be summed up in a single sentence: It's a sophisticated technique of authenticating one machine to another by forging packets from a trusted source address.

From that definition, you can safely conclude that spoofing is a complicated process. However, by this chapter's end, you'll have a clear understanding of spoofing and how to prevent it.

Internet Security Fundamentals

There are two recurring themes in Internet security:

·        Trust

·        Authentication

Trust is the relationship between machines that are authorized to connect to one another. Authentication is the process those machines use to identify each other.

Trust and authentication generally have an inverse relationship. Thus, if a high level of trust exists between machines, stringent authentication is not required to make a connection. On the other hand, if little or no trust exists between machines, more rigorous authentication is required.

If you think about it, humans exercise similar rules. For example, if your best friend came to your front door, you'd let him right in. Why not? You trust him. However, if a total stranger came knocking, you would demand that he identify himself.

Methods of Authentication

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:

·        Your Internet connection

·        FTP sites

·        Telnet services and shell accounts

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 for setting this up.

RHOSTS

The RHOSTS system can be used to establish a relationship of trust between machines. It's described in the Solaris 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.

Note

hosts.equiv files are essentially .rhosts configuration files for the entire system. These are set by root and apply hostwide. In contrast, .rhosts files are user-based and apply only to particular users and directories. (This is why users should be restricted from making their own .rhosts files. These open smaller holes all over the system.)

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 now trusted. These can access the local machine through the r services without being subjected to password authentication.

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

Note

The r services consist of the following applications:

rlogin—Remote login. This works in very similar fashion to Telnet and offers a remote login session.

rsh—Remote shell. This enables users to run shell commands on the remote box.

rcp—Remote file copy. This enables users to copy files from local to remote machines, and vice versa.

rcmd—Remote command. This enables privileged users to execute commands on remote hosts.

All four r services use the /etc/hosts.equiv or .rhosts allow/deny scheme for trust purposes. No trust exists if these files are empty or don't exist, and therefore a spoofing attack (of this variety) cannot occur.

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:

If available, the easiest mechanism to abuse is IP source routing. Assume that the target host uses the reverse of the source route provided in a TCP open request for return traffic. Such behavior is utterly reasonable; if the originator of the connection wishes to specify a particular path for some reason—say, because the automatic route is dead—replies may not reach the originator if a different path is followed.

The attacker can then pick any IP source address desired, including that of a trusted machine on the target's local network. Any facilities available to such machines become available to the attacker.

Security Problems in the TCP/IP Protocol Suite by Steve M. Bellovin can be found on the Web at ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z.

The following points have been established for now:

1.       Trust and authentication have an inverse relationship; more trust results in less stringent authentication.

2.       Initial authentication is based on the source address in trust relationships.

3.       IP source address authentication is unreliable because IP addresses (and most fields of an IP header) can be forged.

4.       A trust relationship of some kind must exist for a spoofing attack to work.

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 having obtained 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.

The Mechanics of a Spoofing Attack

The mere fact that source address authentication is flawed does not in itself make IP spoofing possible. Here's why: The connection process requires more than just the right IP address. It requires a complete, sustained dialog between machines.

You can more easily understand the process in steps:

·        IP is responsible for packet transport. Packet transport performed by IP is unreliable, meaning that there is no absolute guarantee that packets will arrive unscathed and intact. (For example, packets can be lost, corrupted, and so forth.) The main point is this: IP merely routes the packets from point A to point B. Therefore, the first step of initiating a connection is for the packets to arrive intact to the proper host.

·        After the packets do arrive, TCP takes over. TCP is more reliable and has facilities to check that packets are intact and are being transported properly. Each one is subjected to verification. For example, TCP first acknowledges receipt of a packet and then sends a message verifying that it was received and processed correctly.

TCP's process of packet error checking is done sequentially. If five packets are sent, packets 1, 2, 3, 4, and 5 are dealt with in the order they were received. Each packet is assigned a number as an identifying index. Both hosts use this number for error checking and reporting.

In his article Sequence Number Attacks, Rik Farrow explains the sequence number process used in the attack on Tsutomu Shimomura's computer by Kevin Mitnick:

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. Thus, it takes three packets to establish a TCP connection….

Find Sequence Number Attacks by Rik Farrow online at http://www.nwc.com/unixworld/security/001.txt.html.

The attacker's problem can thus far be characterized as twofold. First, he must forge the source address, and, second, he must maintain a sequence dialog with the target. It is this second task that makes the attack complex. Here's why: The sequence dialog is not arbitrary. The target sets the initial sequence number, and the attacker must counter with the correct response.

This further complicates the attack and here's why: The attacker must guess the correct sequence response because he never actually receives packets from the target. In his article A Weakness in the 4.2BSD UNIX TCP/IP Software, Robert Morris explains

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.

Find Morris's article online at ftp://ftp.research.att.com/dist/internet_security/117.ps.Z.

That might sound confusing, so let me illustrate the concept more clearly. Assume the following:

·        The cracker knows that the hosts 207.171.0.111 and 199.171.190.9 have a trust relationship.

·        He intends to penetrate 207.171.0.111.

·        To do so, he must impersonate 199.171.190.9.

·        To impersonate 199.171.190.9, he forges that address.

The problem is that all responses from 207.171.0.111 are actually routed to 199.171.190.9 (and not the cracker's machine). Because of this, the cracker cannot see the packet traffic. He is driving blind. It is because of this inability to see the responses that this method of spoofing is known as blind spoofing. Non-blind spoofing occurs when the responses can be seen because the traffic occurs along a network segment that the attacker can watch.

The blind spoofing situation presents an even more serious obstacle. What if 199.171.190.9 responds to packets from the target while the cracker is conducting his attack? This blows the entire operation. Therefore, the cracker must perform one last, additional step prior to actually conducting the attack: He must either attempt the spoof when 199.171.190.9 is not running or put 199.171.190.9 to sleep.

Note

Killing 199.171.190.9 is simple. To do so, the cracker exposes 199.171.190.9 to a syn-flood attack. This floods the connection queues of 199.171.190.9, temporarily rendering that machine unable to process incoming connection requests. (This works because of the way connection requests are processed. Each time a connection request is received, the target attempts to complete the three-way handshake. Eventually, the target times out on that request and then attempts to process the next one. All connection requests are handled in the order they were received. Thus, if the target is flooded with hundreds of such requests, considerable time will pass before the flooded host can again process connection requests.)

At this point, it's time to recap everything presented until now.

The Ingredients of a Successful Spoofing Attack

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

1.       The cracker must identify his targets.

2.       He must anesthetize the host he intends to impersonate.

3.       He must forge the address of the host he's impersonating.

4.       He must connect to the target, masquerading as the anesthetized host.

5.       He must accurately guess the correct sequence number requested by the target.

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:

·        He contacts the intended target requesting connection.

·        The target responds with a flurry of sequence numbers.

·        The cracker logs these sequence numbers and cuts the connection.

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.

Opening a More Suitable Hole

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.

Who Can Be Spoofed?

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 configurations and services are known to be vulnerable:

·        Any device running Sun RPC

·        Any network service that uses IP address authentication

·        The X Window System from MIT

·        The r services

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

Windows NT, for example, is vulnerable to sequence number attacks. Sessions can be highjacked 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 here:

                                                             http://www.engarde.com/software/seqnumsrc.c

Sun RPC refers to Sun Microsystems'standard of Remote Procedure Calls, which enable users to issue system calls that work transparently over networks. The RFC that addresses RPC, titled RPC: Remote Procedure Call Protocol Specification, can be found at http://www.netsys.com/rfc/rfc1057.txt

How Common Are Spoofing Attacks?

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

ASSIST has received information about numerous recent IP spoofing attacks directed against Internet sites internationally. A large number of the systems targeted in the IP spoofing attacks are name servers, routers, and other network operation systems, and the attacks have been largely successful.

To view the DDN bulletin online, visit http://csrc.ncsl.nist.gov/secalert/ddn/1995/sec-9532.txt.

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 generally. That 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.

Spoofing/Hijacking Utilities

1644

Author: Vasim V.

Language: C

Build Platform: FreeBSD

Target Platform: UNIX

Requirements: C compiler, IP header files, FreeBSD

URL: http://www.insecure.org/sploits/ttcp.spoofing.problem.html

Hunt

Author: Pavel Krauz

Language: C

Build Platform: Linux

Target Platform: Linux

Requirements: C compiler, Linux

URL: http://lin.fsid.cvut.cz/~kra/index.html

ipspoof

Author: Unknown

Language: C

Build Platform: UNIX

Target Platform: UNIX

Requirements: C compiler, IP Header Files, UNIX

URL: http://www.rootshell.com/archive-j457nxiqi3gq59dv/199707/ipspoof.c

Juggernaut

Author: route

Language: C

Build Platform: UNIX

Target Platform: UNIX

Requirements: C compiler, IP Header Files, UNIX

URL: http://staff.washington.edu/dittrich/talks/qsm-sec/P50-06.txt

rbone

Author: Unknown

Language: C

Build Platform: Linux

Target Platform: UNIX

Requirements: C compiler, IP header files, Linux

URL: http://www.net-security.sk/network/spoof/rbone.tar.gz

Spoofit

Author: Brecht Claerhout

Language: C

Build Platform: Linux

Target Platform: UNIX

Requirements: C compiler, IP header files, Linux 1.3 or later

URL: http://rootshell.com/archive-j457nxiqi3gq59dv/199707/IP-spoof.txt.html

synk4.c (Syn Flooder by Zakath)

Author: Zakath with Ultima

Language: C

Build Platform: Linux

Target Platform: UNIX

Requirements: C compiler, IP header files, Linux

URL: http://rootshell.com/archive-j457nxiqi3gq59dv/199707/synk4.c.html

Note

There's also a UDP spoofing utility available. To try it, download it from http://www.deter.com/unix/software/arnudpc.

Documents Related Specifically to IP Spoofing

There are many documents online that address IP spoofing. Here are a few good ones:

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.nwc.com/unixworld/security/001.txt.html

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

Defending Against Sequence Number Attacks. S. Bellovin; Request for Comments: 1948. AT&T Research. May 1996. http://andrew2.andrew.cmu.edu/rfc/rfc1948.html

A Short Overview of IP Spoofing. Brecht Claerhout. http://rootshell.com/archive-j457nxiqi3gq59dv/199707/IP-spoof.txt.html (An excellent freelance treatment of the subject)

Internet Holes—Eliminating IP Address Forgery. Management Analytics. http://all.net/journal/netsec/9606.html.

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

IP-Spoofing Demystified Trust-Relationship Exploitation. route@infonexus.com (Michael Schiffman). http://www.fc.net/phrack/files/p48/p48-14.html

How Do I Prevent IP Spoofing Attacks?

Configuring your network to reject packets from the Net that claim to originate from a local address can thwart IP spoofing attacks. This is done at the router level. Conversely, it is also generally a good policy to reject packets originating inside of your network that claim to come from a host on the outside.

Note

Although routers are a solution to the general spoofing problem, they too operate by examining the source address. Thus, they can only protect against incoming packets that purport to originate from within your internal network. If your network (for some inexplicable reason) trusts foreign hosts, routers will not protect against a spoofing attack that purports to originate from those hosts.

There are several products that incorporate anti-spoofing technology into their general design. Here are a couple:

·        NetVision Synchronicity for Windows NT. The Synchronicity product line incorporates concurrent management of NDS and NT objects and systems. Anti-spoofing support is built in. Check it out here: http://www.netvision.com/products/synchronicity.html

·        Cisco PIX Firewall. PIX is Cisco's premier Internet BXsecurity product and is a full-fledged firewall with built-in anti-spoofing capabilities. http://www.cisco.com/warp/public/cc/pd/fw/sqfw500

Certain products can also test your network for vulnerability to IP spoofing. (Check Chapter 11, "Vulnerability Assessment Tools (Scanners)," for scanners that perform this diagnostic.)

Caution

If you're running a firewall, this 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. Moreover, if your firewall runs proxies and those proxies perform their authentication based on the IP source address, you have a problem. (Essentially, this type of authentication is no different from any other form of IP-based authentication.)

Closely monitoring your network is another preventative measure. Try identifying packets that purport to originate within your network, but attempt to gain entrance at the firewall or first network interface that they encounter on your wire. The following paragraph is excerpted from Defense Information System Network Security Bulletin #95-32. This bulletin can be found online at http://csrc.ncsl.nist.gov/secalert/ddn/1995/sec-9532.txt.

There are several classes of packets that you could watch for. The most basic is any TCP packet where the network portion (Class A, B, or C or a prefix and length as specified by the Classless Inter-Domain Routing (CIDR) specification) of the source and destination addresses are the same but neither are from your local network. These packets would not normally go outside the source network unless there is a routing problem worthy of additional investigation, or the packets actually originated outside your network. The latter can occur with mobile IP testing, but an attacker spoofing the source address is a more likely cause.

As a closing note, if you can afford the resource overhead, you can also detect spoofing through logging procedures (even in real-time). Running a comparison on connections between trusted hosts is a good start. For example, assume that 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 indicate activity, a spoofing attack is afoot.

Other Strange and Offbeat Spoofing Attacks

IP spoofing is only one form of spoofing. Other spoofing techniques exist, including ARP and DNS spoofing. Let's briefly examine each.

ARP Spoofing

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:

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.

Get Paul Buis'paper from http://www.cs.bsu.edu/homepages/peb/cs637/nameadd/.

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 here:

ftp://ftp.ee.lbl.gov/arpwatch.tar.gz

Note

To use ARPWATCH, you need UNIX, C, and AWK. (The distribution comes in source only.)

DNS Spoofing

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, he or she is given a bogus address; this address is the IP address of a machine that is completely under the cracker's control.

The likelihood of this happening is slim, but widespread exposure could result if it does occur. The rarity of these attacks should not be taken as a comforting indicator. Earlier in this chapter, I cited a DDN advisory that documented a rash of 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 might 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. There's a utility called Jizz, written by Nimrood (and based on code written by Johannes Erdfelt). To try it out, download it from this address:

                                                             http://packetstorm.securify.com/Exploit_Code_Archive/jizz.c

There is an interesting document that addresses a DNS spoofing technique—Java Security: From HotJava to Netscape and Beyond, by Drew Dean, Edward W. Felten, and Dan S. Wallach. The paper discusses a technique by which 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 lookups from the default name server to an untrusted one. From there, the attacker might conceivably compromise the client machine or network. (This bug was fixed in 1.02.)

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, 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:

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/sysutils/doc/doc.2.0.tar.Z.

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

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

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

Summary

Spoofing is popular now and when done from the outside, it leaves relatively little evidence. At a minimum, you should block apparent local requests that originate outside your network, and as always, you should employ logging utilities. Finally, I recommend keeping up with the latest advisories—particularly from your router vendor. New spoofing attacks tend to emerge every few months or so.