Sniffing + Forging = Trouble

Clearly, one way to obtain an estimate of the sequence numbers in a TCP/IP connection is to sniff the network somewhere between the client and the server. An attacker could possibly be controlling more than one machine along this path so the machine doing the sniffing need not be the machine doing the forging.

If a machine on the same physical network as the legitimate sender does the forging, then routers will not have much of a chance of stopping the forged datagram. The only possible place to stop the forged datagram would be at the router on the forger’s network, where a discrepancy might be detected between the hardware address of the legitimate sender and the forger.

If a machine on the same physical network as the receiver does the forging, the receiver would also have the opportunity to note such a discrepancy. If the forging occurs on neither of the two endpoint networks, then the opportunity to stop the forged datagram decreases. However, in many cases attackers would only have access to physical networks attached to routers with a single legitimate source network. You can protect your network from being the source of a forging attack by configuring these routers not to forward datagrams with impossible IP network addresses.

One particular case deserves special note. If both endpoints are on the same physical network, an attacker might be bold enough to forge a datagram from another physical network. Because only the destination address needs examination to deliver a datagram, the datagram could get to the receiver via the normal routing mechanisms. However, the router would have the opportunity to detect the forged datagram by noting that the IP source network address matches the IP destination network address. Datagrams with matching source and destination network addresses should not be allowed into the router if the network address matches that of an internal network.

---

Note:  See the CERT Advisories CA-96.21 and CA-95:01 to find out more about IP spoofing attacks and recommended fixes from vendors.

---

TCP/IP Forging without Sniffing

With four billion possible initial sequence numbers, it should be extremely difficult to guess a valid current sequence number for a TCP/IP connection. However, this assumes assignment of the initial sequence numbers in a completely random manner. If an attacker establishes a TCP/IP connection with the receiving end of another TCP/IP connection, the attacker also obtains an initial sequence number from the receiving end. If the initial sequence numbers of the two connections are related in some way, the attacker will be able to compute the initial sequence number of the other connection.

When the attacker has the initial sequence number of the connection, the next and final step is to estimate how much TCP/IP data has been sent to the receiver. This estimate added to the initial sequence number estimates the current sequence number. An estimate of the current sequence number goes into a forged TCP/IP header.

Some TCP/IP implementations use initial sequence numbers generated by a simple random number generator that generates numbers in a fixed order. If the attacker knows this ordering, the attacker can establish a connection at about the same time as the connection to be spoofed. Knowing that connection’s initial sequence number will provide enough information to narrow the plausible initial sequence numbers for the connection to a very few instead of four billion. The way to prevent this attack is to use a TCP/IP implementation that does a good job of generating random initial sequence numbers.

Terminal Hijacking: An Example of TCP/IP Forging

Imagine the following everyday scenario at my workplace. Many workers use windowing systems such as the X Window system or Microsoft Windows to start terminal sessions to one or more of the timesharing systems. The most convenient way to use these systems is to have them start automatically. With this setup, many of the windows will have idle terminal sessions using a TCP/IP-based protocol such as Telnet, tn3270, or rlogin.

In fact, some of these sessions are never used after they start. Some of these remain idle for days or weeks at a time. An attacker with ordinary access to one of the timesharing systems can easily detect the time any particular worker starts a terminal session by monitoring the set of users on the timeshared system.

Immediately after the targeted worker logs in to the timesharing system, the attacker determines the initial sequence number of the TCP/IP connection used for the terminal session. The attacker may have received this number using a sniffer running on another host on the network or by taking advantage of the deterministic pattern of initial sequence numbers.

Next, the attacker estimates the number of data bytes the worker’s terminal session has sent to the timesharing system. Typically, the worker types in at most a user name, password, and a command or two by this time. By simply estimating the number of data bytes to be between zero and one hundred, the attacker will be close enough to hit the window of acceptable sequence numbers.

To do some real damage, the attacker simply has to insert a sequence of characters in the data stream that correspond to a command being typed in at the command prompt. Just to be sure that the command is accepted as an entire command, the attacker could place characters in the data stream that would exit a typical application and get to a new command line. Putting “rm -rf *” on the command line in Unix deletes all files in the current directory along with all files in all subdirectories of the current directory.

If the attacker really wants to spook the worker, he or she could wait to see if the terminal session will remain idle overnight while the worker is gone, the office locked, and all the physical security mechanisms in place to ensure no one enters the office.

If the attacker determines the exact initial sequence number for the terminal session, the command is executed by the timesharing system in the worker’s absence. The echo of the presumed keystrokes will appear in the worker’s terminal window along with a new command prompt indicating that the command has completed. Imagine the surprise the worker gets when he or she shows up in the morning and sees this terminal window. Imagine the horror of realizing that backups were done shortly after the command executed and that a whole backup period of work has been lost.