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