IP Spoofing and TCP Sequence Number Prediction
by Gregory W. MacPherson

On February 19th, 1995, Kevin Mitnick was arrested in Raleigh, NC on charges of violating the Cellular Piracy Act by making cellular phone calls on a cloned phone. His arrest was precipitated by the intrusion into the system of computer security consultant Tsutomu Shimomura on Christmas Day in 1994. While much was written by the media concerning Mitnick's alleged criminal career, no technical description of the techniques used for the intrusion was published. Fortunately, Shimomura's system logged the intrusion, and his description of the intrusion was e-mailed to various security administrators on the internet.

This article is a technical description of the methods used to infiltrate Shimomura's system. The techniques described can easily be used to penetrate a UNIX system using TCP sequence number prediction. To do so requires a program (not described here, but easily implemented) to generate TCP packets. An understanding of TCP protocol data units is useful in following the discussion. A great deal of the following information is taken from the description of the break in provided by Shimomura. Thanks and credit where credit is due. Now on to the hack.

The following names are used to describe the various machines involved:

server = a SPARCstation running Solaris 1 serving an X terminal
X-terminal = a diskless SPARCstation running Solaris 1
target = the apparent primary target of the attack

The first step of the attack involved determining the machine configuration of the target system. The IP spoofing attack began with the following commands being issued from a machine identified as toad.com:

finger -l @target
finger -l @server
finger -l @X-terminal
finger -l root@server
finger -l root@X-terminal

The finger commands generate a display of the user's login name, real name, terminal name, write status, idle time, login time, office location and office phone number. The -l option displays the user's home directory, home phone number, login shell, and contents of the .forward, .plan, and .project files for the user's home directory, if they exist.

showmount -e X-terminal

The showmount command displays the names of all hosts that have NFS file systems mounted on the X-terminal machine. The -e option shows the export list for X-terminal.

rpcinfo -p X-terminal

The rpcinfo command displays the connections of the port mapper of X-terminal. The -p option displays the programs that are currently being tracked by the port mapper.

The above commands would indicate whether some kind of trust relationship existed between the systems, and how that trust relationship could be exploited with an IP spoofing attack.

The source port numbers for the showmount and rpcinfo commands indicated that the attacker was logged in as root on toad.com.

The second step involved generating a large number of TCP initial connection requests (SYNs) in order to fill up the connection queue for port 513 on the server with "half-open" connections. This ensures that the server will not respond to any new connection requests. In particular, it will not generate TCP RSTs in response to unexpected SYN-ACKs. Port 513 is a privileged port, and will allow server.login to be used as the putative source for an address spoofing attack on the UNIX "r-services" (rsh, rlogin). 130.92.6.97 is a non-existent address that will not generate a response to packets sent to it.

Below is a portion of Shimomura's log showing some of the generated SYN records:

14:18:22.516699 130.92.6.97.600 > server.login: S 1382726960:1382726960(0) win 4096
14:18:22.566069 130.92.6.97.601 > server.login: S 1382726961:1382726961(0) win 4096
14:18:22.744477 130.92.6.97.602 > server.login: S 1382726962:1382726962(0) win 4096
14:18:22.830111 130.92.6.97.603 > server.login: S 1382726963:1382726963(0) win 4096

.
.
.

The server generated SYN-ACKs for the first eight SYN requests before the connection queue filled up. The machine would periodically retransmit the SYN-ACKs as there is no ACK response to them.

The third step involved sending a series of SYN packets to determine the behavior of the TCP sequence number generator. This allows for the prediction of what the sequence number of the SYN-ACK from the target machine would be, and for subsequent simulation of the response to that machine. Note that the initial sequence numbers increment by one for each connection, indicating that the SYN packets are not being generated by the system's TCP implementation. This cause the generation of TCP RSTs in response to each unexpected SYN-ACK, so the connection queue on x-terminal does not fill up. The source machine for the connection requests is apollo.it.luc.edu.

Below is a portion of the log showing two of the server's responses:

14:18:25.906002 apollo.it.luc.edu.1000 > x-terminal.shell: S 1382726990:1382726 990(0) win 4096
14:18:26.094731 x-terminal.shell > apollo.it.luc.edu.1000: S 2021824000:2021824 000(0) ack 1382726991 win 4096
14:18:26.172394 apollo.it.luc.edu.1000 > x-terminal.shell: R 1382726991:1382726 991(0) win 0
14:18:26.507560 apollo.it.luc.edu.999 > x-terminal.shell: S 1382726991:13827269 91(0) win 4096
14:18:26.694691 x-terminal.shell > apollo.it.luc.edu.999: S 2021952000:20219520 00(0) ack 1382726992 win 4096

.
.
.

Note that the SYN-ACK packet sent by X-terminal has an initial sequence number that is 128,000 greater than the previous one.

The fourth step involved sending a false SYN connection request to the target machine. The SYN appears to be from server.login, a trusted host, using the predicted sequence number to simulate the trusted host. X-terminal will reply to server with a SYN-ACK, which must be ACK'd in order for a connection to be opened. Because server is ignoring packets sent to server.login, because the connection queue is full, the ACK must be forged as well.

TCP uses a three way handshake to establish communications between a client and a server. The SYN bit in the control field of the TCP protocol data unit (PDU) is used to establish initial sequence numbers. The first PDU does not acknowledge any data. The second PDU has both the SYN and the ACK bits set. The third PDU acknowledges the second PDU and has the ACK bit set. The three way handshake is illustrated below:

            Client                               Server



        1st SYN (seq #1)  - - - - - - - - >  Receives SYN - - - - |

                                                                  |

    | - Receives SYN-ACK < - - - - - Sends SYN-ACK (seq #?) - - - |

    |                                                              

    | - Sends ACK (seq # = ?+1) - - - - - > Connection established!
The sequence number from the SYN-ACK is required in order to generate a valid ACK. By knowing the interval between the sequence numbers of the SYN-ACKs sent by X-terminal, the attacker is able to predict the sequence number contained in the SYN-ACK based on the known behavior of X-terminal's TCP sequence number generator, and is thus able to ACK the SYN-ACK without seeing it.

Below is a portion of the log containing the generated ACK:

14:18:36.245045 server.login > x-terminal.shell: S 1382727010:1382727010(0) win 4096
14:18:36.755522 server.login > x-terminal.shell: . ack 2024384001 win 4096

The spoofing machine now has a one-way connection to x-terminal.shell which appears to be from server.login. It can maintain the connection and send data provided that it can properly ACK any data sent by x-terminal.

The fifth step requires the attacker to send the UNIX command

rsh x-terminal "echo + + >>/.rhosts"

to the target machine. This command generates a line of two plus signs and either appends that line to the end of the .rhosts file in the root directory of the target machine, or creates the file if it does not exist. The line with two plus signs in the .rhosts file allows any user to perform remote logins from any host without being prompted for a password. The attacker now have root access to the target machine without password authorization prompting.

Finally the spoofed connection is shut down and TCP RSTs are sent to the server machine to reset the "half-open" connections and empty the connection queue for server.login so that server.login can again accept connections. Below is a portion of the log containing the RSTs:

14:18:52.298431 130.92.6.97.600 > server.login: R 1382726960:1382726960(0) win 4096
14:18:52.363877 130.92.6.97.601 > server.login: R 1382726961:1382726961(0) win 4096
14:18:52.416916 130.92.6.97.602 > server.login: R 1382726962:1382726962(0) win 4096
14:18:52.476873 130.92.6.97.603 > server.login: R 1382726963:1382726963(0) win 4096

.
.
.

The information in this article is for demonstration purposes only. Tsutomu Shimomura's e-mail is tsutomu at ucsd.edu.