Analysis of TCP sequence number vulnerability

This is some very technical stuff. But if you already know what they are talking the whole article is very interesting. They look at a variety of OS's including the Windows versions, Solaris, Mac, etc. Below is an excerpt of the introduction from the paper:

Upon connection via TCP/IP to a host, the host generates an Initial Sequence Number (ISN). This sequence number is used in the conversation between itself and the host to help keep track of each packet and to ensure that the conversation continues properly. Both the host and the client generate and use these sequence numbers in TCP connections.

As early as 1985 there was speculation that by being able to guess the next ISN, an attacker could forge a one-way connection to a host by spoofing the source IP address of a trusted host, as well as the ISN which would normally be sent back to the trusted host via an acknowledgement packet. It was determined that to help ensure the integrity of TCP/IP connections, every stream should be assigned a unique, random sequence number. The TCP sequence number field is able to hold a 32-bit value, and 31-bit is recommended for use by RFC specifications. An attacker wanting to establish connection originating from a fake address, or to compromise existing TCP connection integrity by inserting malicious data into the stream [1] would have to know the ISN. Because of the open nature of the Internet, and because of large number of protocols that are not using cryptographic mechanisms to protect data integrity, it is important to design TCP/IP implementations in a way that does not allow remote attackers to predict an ISN (this is called a "blind spoofing" attack).

It is difficult to generate unpredictable numbers using a computer. This is because computers are designed to execute strictly defined sets of commands in repeatable and accurate ways. Thus, every fixed algorithm can be used to produce exactly the same results on another computer, which then can be used to effectively predict output values, assuming attracker can reconstruct internal state of such a remote system. Also, even if the target PNRG function is not known, sooner or later the algorithm will start generating the same exact sequences over again, because there is a limited number of possible internal states that can be used by a specific algorithm (computers are using finite precision and range arithmetics). Hopefully this happens later and the conditions to start the repeating of sequential numbers will take many months or years. But, there are known vulnerable implementations with a PRNG generator period of just over 500 elements or less.

The common approach of dealing with this lack of true randomness is to introduce additional randomness, or entropy, from an external, unpredictable source. Usually, this randomness is calculated from keystroke intervals, specific I/O interrupts and other parameters that are not known to the attacker. This solution, combined with a reasonably good hashing function that produces full 32 or 31-bit data with no correlation between subsequent results without revealing useful information about the internal state of PRNG function, can be used to make an excellent TCP sequence generator. Unfortunately, TCP ISN generators are rarely written this way, and when they are, there are numerous flaws or implementation errors that can lead to predictable ISNs.

RFC1948 suggests the use of source IP address, destination IP address, source port and destination port, plus an additional random secret key. This data should be hashed using a shortcut function to generate random and unique sequence numbers for every unique connection. Failing to account for this can lead to improper conclusions when analyzing TCP generators with respect to ISN predictability. Indeed, statements that are true for the ISNs coming back to the attacker might not be true for other connections, as the hash values would be different.

This research attempts to analyze the pseudo-random number generators (PRNGs) used for TCP sequence number generation in different operating systems and to expose potential flaws in the algorithms used. We analyzed the generated sequence numbers, instead of trying to focus on the actual implementations in the various operating systems. In essence, we approached the analysis from the same standpoint as the remote attacker would – from the network.

(Read the whole article at http://razor.bindview.com/publish/papers/tcpeq.html)

Leave a Reply

Your email address will not be published. Required fields are marked *