A Hacker's Guide to Protecting Your Internet Site and Network
There has never been more controversy about a cracking technique than the controversy surrounding IP spoofing. IP spoofing is the most talked about and least understood method of gaining unauthorized entry to a computer system. For example, a well publicized spoofing case occurred in December, 1994. John Markoff, in his article that appeared in The New York Times titled "New Form of Attack on Computers Linked to Internet is Uncovered," reported:
That report was not entirely accurate. The IP spoofing technique was not "new," nor was it "uncovered." Rather, it has been known for more than a decade that IP spoofing was possible. To my knowledge, the first paper written on this subject was published in February 1985. That paper was titled "A Weakness in the 4.2BSD UNIX TCP/IP Software," and it was written by Robert Morris, an engineer at AT&T Bell Laboratories in Murray Hill, New Jersey.
Because I want to relay information about IP spoofing as accurately as possible, I will approach the subject in a slow and deliberate fashion. If you already know a bit about the technique, you would be wise to skip ahead to the section titled "Point of Vulnerability: The R Services."
I should immediately make three points about IP spoofing:
What Is a Spoofing Attack?
A spoofing attack involves nothing more than forging one's source address. It is the act of using one machine to impersonate another. To understand how this occurs, you must know a bit about authentication.
Every user has encountered some form of authentication. This encounter most often occurs while connecting to a network. That network could be located in the user's home, his office, or, as in this case, the Internet. The better portion of authentication routines known to the average user occur at the application level. That is, these methods of authentication are entirely visible to the user. The typical example is when a user is confronted with a password prompt on FTP or Telnet. The user enters a username and a password; these are authenticated, and the user gains access to the resource.
On the Internet, application-level authentication routines are the minority. Each second, authentication routines that are totally invisible to the user occur. The difference between these routines and application-level authentication routines is fundamental. In application-level authentication, a machine challenges the user; a machine requests that the user identify himself. In contrast, non-application-level authentication routines occur between machines. One machine demands some form of identification from another. Until this identification is produced and validated, no transactions occur between the machines engaged in the challenge-response dialog.
Such machine-to-machine dialogs always occur automatically (that is, they occur without human intervention). In the IP spoofing attack, the cracker attempts to capitalize on the automated nature of the dialog between machines. Thus, the IP spoofing attack is an extraordinary method of gaining access because in it, the cracker never uses a username or password.
This, for many people, is difficult to grasp. Consequently, reports of IP spoofing have needlessly caused much fear and paranoia on the Internet.
Who Can Be Spoofed?
The IP spoofing attack is unique in that it can only be implemented against a certain class of machines running true TCP/IP. True TCP/IP is any fully fledged implementation of TCP/IP, or one that--in its out-of-the-box state--encompasses all available ports and services within the TCP/IP suite. By this, I am referring almost exclusively to those machines running certain versions of UNIX (only a handful are easily spoofed). PC machines running DOS, Windows, or Windows 95 are not included in this group. Neither are Macintoshes running MacOS. (It is theoretically possible that Macs running A/UX and PCs running Linux could be vulnerable, given the right circumstances.)
I cannot guarantee that other configurations or services will not later be proven vulnerable to IP spoofing, but for the moment the list of vulnerable services is short indeed:
Sun RPC refers to Sun Microsystems' standard of Remote Procedure Calls, which are methods of issuing system calls that work transparently over networks (that is, of executing commands over remote machines or networks).
IP address authentication uses the IP address as an index. That is, the target machine authenticates a session between itself and other machines by examining the IP address of the requesting machine. There are different forms of IP authentication, and most of them are vulnerable to attack. A good discussion about this appears in a classic paper written by Steve M. Bellovin titled "Security Problems in the TCP/IP Protocol Suite":
Point of Vulnerability: The R Services
In the UNIX environment, the R services are rlogin and rsh. The r represents the word remote. These two programs are designed to provide users with remote access to other machines on the Internet. Although these programs may be compared to programs of a similar ilk (for example, people often liken rlogin to Telnet), these programs (or services) are unique:
The R services are vulnerable to IP spoofing attacks.
How Spoofing Attacks Work
Spoofing attacks differ from random scanning and other techniques used to ascertain holes in the system. Spoofing attacks occur only after a particular machine has been identified as vulnerable. By the time the cracker is ready to conduct a spoofing attack, he or she knows the target network is vulnerable and which machine is to be attacked.
Trust Relationships and Spoofing Generally
Nearly all forms of spoofing (and there are types other than IP spoofing) rely on trust relationships within the target network. By trust, I don't mean human or application-layer trust. Instead, I refer to trust between machines.
Chapter 18, "Novell," briefly discusses spoofing of a hardware address on an Ethernet network. This is accomplished by redefining the network address of the workstation used to perform the spoof. In Novell networks, this is commonly accomplished by redefining this value in the NET.CFG file, which contains parameters that are loaded upon boot and connection to the network. NET.CFG includes many options for altering the configuration by hand (which is useful, because conventional configurations sometimes fail to come out correctly). To sidestep possible problems with factory configurations, changes may be made directly to the interface using this file. Options include number of buffers, what protocols are to be bound to the card, port number, MDA values, and the node address.
Hardware address spoofing is, to a certain extent, also dependent upon the card. Cards that do not allow for software-driven settings of the hardware address are generally useless in this regard. You might be able to report an address, but in most instances, the technique does not actually work. Older cards support software-driven alteration of the address, usually with a jumper setting. (This is done by shorting out the jumper pins on the card.) A good example is the old Western Digital Ethernet card. Newer cards are more likely to automatically allow software-driven changes, whereas IRQ settings may still be a jumper issue. It is likely, however, that in the near future, Ethernet cards may not have jumpers at all due to the fact that plug-and-play technology has emerged.
This type of spoofing works because each machine on a given network segment trusts its pals on that same segment. Barring the installation of a hub that hardwire-routes packets to each machine, at least a few trust relationships between machines will exist within a segment. Most commonly, those machines know each other because their addresses are listed within some database on each machine. In IP-based networks, this is done using the IP address--I hope--or with the hostname. (Using hostnames is a potential security problem in itself. Whenever possible, hard numeric addresses should be used.)
Machines within a network segment that are aware of the addresses of their pals are referred to as machines that trust each other. When such a trust relationship exists, these machines may remotely execute commands for each other with no more authentication than is required to identify the source address.
Crackers can determine trust relationships between machines using a wide range of commands or, more commonly, using scanners. One can, for example, scan a host and easily determine whether the R services are running. Whatever method is used, the cracker will attempt to map the trust relationships within the target network.
Anatomy of an IP Spoofing Attack
Let's begin our analysis at a point after the cracker has determined the levels of trust within the network.
As you can see, this segment has two trust relationships: Nexus 1 trusts Nexus 2, and Nexus 2 trusts Nexus 3. To gain access to Nexus, then, the cracker has two choices:
The cracker decides to spoof Nexus 2, claiming to be Nexus 3. Thus, his first task is to attack Nexus 3 and temporarily incapacitate it.
Step One: Putting Nexus 3 to Sleep
To temporarily incapacitate Nexus 3, the cracker must time out (hang or temporarily render inoperable) that machine on the targeted port (the port that would normally respond to requests about to be issued).
Normally, when a request is issued from Nexus 3 to Nexus 2, Nexus 2 replies to Nexus 3 on a given port. That response generates a response from Nexus 3. The cracker, however, does not want Nexus 3 to respond because he wants to respond with his own packets, posing as Nexus 3.
The technique used to time out Nexus 3 is not particularly important as long as it is successful. The majority of such attacks are accomplished by generating a laundry list of TCP SYN packets, or requests for a connection. These are generated from a bogus address and forwarded to Nexus 3, which tries to respond to them. You may remember that in Chapter 4, I discussed what happens when a flurry of connection requests are received by a machine that cannot resolve the connection. This is one common element of a denial-of-service attack, or the technique known as syn_flooding.
The cumulative effect of the flooding times out Nexus 3. That is, Nexus 3 attempts to resolve all the connection requests it received, one at a time. The machine's queue is flooded. It cannot respond to additional packets until the queue is at least partially cleared. Therefore--at least on that port--Nexus 3 is temporarily down, or unreachable; it will not respond to requests sent by Nexus 2.
Step Two: Discovering Nexus 2's Sequence Number
The next step of the process is fairly simple. The cracker sends a series of connection requests to Nexus 2, which responds with a series of packets indicating receipt of the cracker's connection requests. Contained within these response packets is the key to the spoofing technique.
Nexus 2 generates a series of sequence numbers. Chapter 6, "A Brief Primer on TCP/IP," mentioned that sequence numbers are used in TCP/IP to mark and measure the status of a session. An articled titled "Sequence Number Attacks" by Rik Farrow articulates the construct of the sequence number system. Farrow explains:
Each side must adhere to the sequence number scheme. If not, there is no way to reliably transfer data across the network. As articulated by Robert Morris in his article titled "A Weakness in the 4.2BSD UNIX TCP/IP Software":
This procedure begins with reading the sequence numbers forwarded by Nexus 2. By analyzing these, the cracker can see how Nexus 2 is incrementing them. There must be a pattern, because this incremental process is based on an algorithm. The key is identifying by what values these numbers are incremented. When the cracker knows the standard pattern Nexus 2 is using to increment these numbers, the most difficult phase of the attack can begin.
Having obtained the pattern, the cracker generates another connection request to Nexus 2, claiming to hail from Nexus 3. Nexus 2 responds to Nexus 3 as it normally would, generating a sequence number for the connection. However, because Nexus 3 is temporarily incapacitated, it does not answer. Instead, the cracker answers.
This is the most difficult part of the attack. Here, the cracker must guess (based on his observations of the sequence scheme) what sequence number Nexus 2 expects. In other words, the cracker wants to throw the connection into an ESTABLISHED state. To do so, he must respond with the correct sequence number. But while the connection exchange is live, he cannot see the sequence numbers being forwarded by Nexus 2. Therefore, the cracker must send his requests blind.
If the cracker correctly guesses the sequence number, a connection is established between Nexus 2 and the cracker's machine. For all purposes, Nexus 2 now believes the cracker is hailing from Nexus 3. What remains is fairly simple.
Opening a More Suitable Hole
During the time the connection is established, 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. Actual cases suggest that the easiest method is to re-write the .rhosts file so that Nexus 2 will accept connections from any source without requiring additional authentication.
The cracker can now shut down all connections and reconnect. He is now able to log in without a password and has run of the system.
How Common Are Spoofing Attacks?
Spoofing attacks are rare, but they do occur. Consider this Defense Data Network advisory from July, 1995:
The attack documented by John Markoff in The New York Times occurred over the Christmas holiday of 1994. By mid-1995, the attack had been discussed in cracker circles across the Internet. After it was demonstrated that the Morris attack technique was actually possible, crackers quickly learned and implemented IP spoofing worldwide. In fact, source code for pre-fabbed spoofing utilities was posted at sites across the Net. A fad was established.
Even though the word is out on spoofing, the technique is still quite rare. This is because, again, crackers require particular tools and skills. For example, this technique cannot--to my knowledge--be implemented on a non-UNIX operating system. However, I cannot guarantee that this situation will remain. Before long, someone will introduce a Windows-based auto-spoofer written in Visual C++ or some other implementation of C/C++. I suspect that these will be available within a year. For the moment, the technique remains a UNIX thing and therefore, poses all the same obstacles (root access, knowledge of C, technical prowess to manipulate the kernel, and so forth) as other UNIX-based cracking techniques.
Spoofing is sometimes purposely performed by system administrators. This type of spoofing, however, varies considerably from typical IP spoofing. It is referred to as LAN spoofing or WAN spoofing. These techniques are used primarily to hold together disparate strings of a WAN.
In many WAN environments, networks of widely varying design are attached to a series of WAN servers, nodes, or devices. For each time a message is trafficked over these lines, a toll is generally incurred. This can be expensive, depending largely on the type and speed of the connection. One thing is obvious: The best arrangement is one in which none of the nodes pays for the connection unless data is being trafficked across it (it seems wasteful to pay merely for the connection to exist).
To avoid needless charges, some engineers implement a form of spoofing whereby WAN interfaces answer keep alive requests from remote LAN servers rather than actually routing those requests within the overall WAN network. Thus, the remote LAN assumes it is being answered by the remote WAN, but this is not actually true.
This is a very popular technique and is now incorporated into many routers and routing software. One good example is Lightning's MultiCom Software Release 2.0. White paper documentation on it explains:
There are other router products that perform this function. One is the Ethernet Router IN-3010/15.
What Can Be Done to Prevent IP Spoofing Attacks?
IP spoofing attacks can be thwarted by configuring your network to reject packets from the Net that claim to originate from a local address (that is, reject packets that purport to have an address of a workstation on your internal network). This is most commonly done with a router.
Routers work by applying filters on incoming packets; for example, they can block particular types of packets from reaching your network. Several companies specialize in these devices:
Certain security products can also test for your vulnerability to IP spoofing. Internet Security Systems (ISS), located online at http://iss.net, is a company that offers such products. In fact, ISS offers a trial version that can be used on a single local host. These tools are quite advanced.
At least one authoritative source suggests that prevention can also be realized through monitoring your network. This starts with 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:
Other Strange and Offbeat Spoofing Attacks
Other forms of spoofing, such as DNS spoofing, exist. DNS spoofing occurs when a DNS machine has been compromised by a cracker. The likelihood of this happening is slim, but if it happens, widespread exposure could result. 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 widespread attacks against DNS machines. Moreover, an important CIAC advisory addresses this issue:
DNS spoofing is fairly difficult to accomplish, even if a cracker has compromised a DNS server. One reason is that the cracker may not be able to accurately guess what address DNS client users are going to request. Arguably, the cracker could assume a popular address that is likely to appear (www.altavista.digital.com, for example) or he could simply replace all address translations with the arbitrary address of his choice. However, this technique would be uncovered very quickly.
Could a cracker implement such an attack wholesale, by replacing all translations with his own address and still get away with it? Could he, for example, pull from the victim's environment the address that the user really wanted? If so, what would prevent a cracker from intercepting every outgoing transmission, temporarily routing it to his machine, and routing it to the legitimate destination later? Is it possible via DNS spoofing to splice yourself into all connections without being discovered? Probably not for more than several minutes, but how many minutes are enough?
In any event, 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 would be the IP address of a machine completely under the cracker's control.
You may be wondering why DNS attacks exist. After all, if a cracker has already compromised the name server on a network, what more can be gained by directing DNS queries to the cracker's own machine? The answer lies primarily in degrees of compromise. Compromising the name server of a network does not equal compromising the entire network. However, one can use the system to compromise the entire network, depending on how talented the cracker is and how lax security is on the target network. For example, is it possible to convince a client that the cracker's machine is really the client's local mail server?
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 where 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 a remote untrusted one. From there, the attacker might conceivably compromise the client machine or network.
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 cracked. Other authoritative servers will report results that vary from those given by the cracked DNS server.
Polling may not be sufficient if the originally cracked server has been compromised for an extended period. 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:
Spoofing is popular now. What remains is for the technique to become standardized. Eventually, this will happen. You can expect point-and-click spoofing programs to hit the circuit within a year or so.
If you now have or are planning to establish a permanent connection to the Internet, discuss methods of preventing purportedly internal addresses from entering your network from the void with your router provider (or your chief network engineer). I say this for one reason: Spoofing attacks will become the rage very soon.
Previous chapter Next chapter Contents
© Copyright, Macmillan Computer Publishing. All rights reserved.
With any suggestions or questions please feel free to contact us