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

Continue reading →