|
|
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:
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.
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).
Cross Reference: The RFC that addresses RPC, titled "RPC: Remote Procedure Call Protocol Specification," can be found at http://www.pasteur.fr/other/computer/RFC/10xx/1057.
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":
Cross Reference: "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.
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.
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.
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.
NOTE: Jumpers are small plastic sheaths that slip over pins on a computer card (this card could be an Ethernet card, a motherboard, a modem, or a hard disk drive controller). These plastic jumpers are typically used to set addresses on such cards. The manufacturer of the card generally includes a manual on their product which shows the locations of jumpers on the board. Such manuals also usually describe different ways of configuring your jumpers. A jumper pin set consists of two pins. If these pins are covered by a plastic jumper sheath, they are deemed to be shorted out. Shorting out different jumpers alters the configuration of the card. Jumper pin sets are typically arranged in a row on the board. For example, a modem that has jumpers to assign IRQ addresses will probably have four or five jumper pin sets. By covering various combinations of these pin sets with plastic jumper sheaths, you can change the IRQ from three to four, five, seven, and so forth.
CAUTION: Never use MAC addresses as an index for authentication. Mac addresses on most modern cards can be changed easily using existing software or quickly hacked code. It is argued that MAC address spoofing is difficult because when two machines have the same MAC address on the same segment, communication failures and crashes result. Note, however, that this is not always true. This generally happens when both are trying to reach the same resource or when the active protocol is IPX (NetWare). In a passive state, these could co-exist, particularly in a TCP/IP environment. Nonetheless, there is no guarantee that the packets will arrive in a pristine state.
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.
Let's begin our analysis at a point after the cracker has determined the levels of trust within the network. An overview of one segment of our mock target network, called Nexus, is shown in Figure 28.1.
FIGURE 28.1.
Overview of Nexus segment.
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.
NOTE: It is not always necessary to incapacitate the machine from which you are claiming to originate. On Ethernet networks in particular, however, you may have to. If you do not, you may cause the network to hang.
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.
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:
Cross Reference: Find "Sequence Number Attacks" by Rik Farrow online at http://www.wcmh.com/uworld/archives/95/security/001.txt.html.
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":
Cross Reference: Find Morris's article online at ftp://ftp.research.att.com/dist/internet_security/117.ps.Z.
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.
NOTE: The cracker cannot see the sequence numbers because Nexus 2 is sending them (and they are being routed) to Nexus 3, the actual, intended recipient. These are routed to Nexus 3 because Nexus 3 is the owner of the actual IP address. The cracker, in contrast, only purports to have Nexus 3's IP.
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.
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.
Spoofing attacks are rare, but they do occur. Consider this Defense Data Network advisory from July, 1995:
Cross Reference: To view the DDN bulletin online, visit ftp://nic.ddn.mil/scc/sec-9532.txt.
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.
Cross Reference: One of these individuals posted to a well-known security list with the subject line "Introducing in the Left Corner: Some Spoofing Code." The posting was a brief description of a paper (and accompanying code) available on the author's Web site. It is still available today. It can be found at http://main.succeed.net/~coder/spoofit/spoofit.html.
Because this is not owned by the user, and because it is located in a foreign country, I advise you to save it to your local disk. The spoofing code is good. The author also offers code to hijack Telnet sessions and a general-purpose C program to kill TCP connections on your subnet.
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 (see Figure 28.2).
FIGURE 28.2.
LAN and WAN spoofing in action.
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.
Cross Reference: Jeffery Fritz, a telecommunications engineer for West Virginia University, wrote a consuming article about this type of technique to save money in Wide Area Network environments. That article, titled "Network Spoofing: Is Your WAN on the Wane? LAN Spoofing May Help Solve Some of Your Woes," can be viewed online at http://www.byte.com/art/9412/sec13/art4.htm. Fritz also wrote the book Sensible ISDN Data Applications, published by West Virginia University Press. This book is a must read for ISDN users.
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:
Cross Reference: The white paper on Lightning's MultiCom Software Release 2.0 can be found online at http://www.lightning.ch/products/software/ipx/details.html.
There are other router products that perform this function. One is the Ethernet Router IN-3010/15.
Cross Reference: For further information about the Ethernet Router IN-3010/15, visit http://www.craycom.co.uk/prodinfo/inetwork/fsin301x.htm.
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:
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.
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.
CAUTION: If you are running a firewall, this does not automatically protect you from spoofing attacks. If you allow internal addresses to access through the outside portion of the firewall, you are vulnerable!
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:
Cross Reference: The previous paragraph is excerpted from Defense Information System Network Security Bulletin #95-29. This bulletin can be found online at ftp://nic.ddn.mil/scc/sec-9532.txt.
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:
Cross Reference: 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 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.
Cross Reference: "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 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:
Cross Reference: 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 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 may have limited value, though. With all likelihood, the cracker has altered both the forward and reverse tables.
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.
© Copyright, Macmillan Computer Publishing. All rights reserved.