CMPS 376 - Lab 9

Lab 9 - TCP Initial Sequence Number Vulnerability

One issue with the selection of an initial sequence number (ISN) for the TCP connection is spoofing. If the initial sequence number is guessable, an attacker can spoof the TCP handshake. The canonical attack has three parties: A the spoofed host, B the hapless server, X the attacker. The attacker first floods A to prevent it from receiving messages from B. This can be accomplished by any number of denial of service attacks. The attacker then connects to B to get sequence number data from B. Let's call this sequence number ISNb. If B is using a sequence number scheme that is easy to guess, the attacker can extrapolate the next sequence number(s) that B will use. Let's call this number ISNb'. The attacker will then connect to B pretending to be A. B will send a reply to A, that will never get there due to the denial of service on A, that contains B's sequence number, z. If the attacker has guessed correctly, z = ISNb'. The attacker can then spoof an acknowledgement of ISNb', and B will be tricked into thinking it has a connection with A. The flow of events can be summarized as follows:

   X->A: Flood A                <--- Denial of service
   X->B: SYN, ISNx              <--- Attacker makes legitimate connection to B
   B->X: SYN, ISNb, ACK(ISNx+1) <--- From ISNb, X can guess next ISN, ISNb'
   X->B: Closes connection      <--- Legit connection no longer needed
   Ax->B: SYN, ISNx'            <--- From attacker, spoofing A
   B->A: SYN, z, ACK(ISNx'+1)   <--- Goes to real A, attacker does not see z, guesses z = ISNb'
   Ax->B: ACK(ISNb'+1)          <--- X uses guessed ISNb' to generate ACK

If the attacker can also guess how B will increment its sequence number during the connection, then the attacker can continue sending data to B while posing as A. The increment is usually the size of the data that B sends. This can be guessed if the application protocol uses relatively fixed sized responses from B for certain input.

Note that if the attacker can also guess ISNb' without connecting to B (such as if B is using a clock-based sequence number), then the connection from X->B is not needed and the attacker can skip down to the Ax->B step.

Also note that the attacker does not even need to be able to see packets traveling from B to A to make this attack succeed. As long as B uses a guessable sequence number generator and sends predictably sized responses, the attacker can guess the appropriate sequence number to use in the ACK field without any additional input.

The following papers, whitepages and advisories give more details about the ISN vulnerability:

Robert Morris, A Weakness in the 4.2BSD Unix TCP/IP Software - 1985
This details the above scenario and how it is particularly easy on the 4.2BSD kernel. The 4.2BSD kernel increments the sequence number by fixed amounts, which makes it easy to guess the next sequence number to be used by the server.
Steve Bellovin, Security Problems in the TCP/IP Protocol Suite - 1989
This paper proposes some solutions to the ISN problem. One solution is to use randomized increments, since any time-based increments can be guessed. Another solution is to use a cryptographic ISN generator with a well-chosen key.
CERT Advisory CA-1995-01: IP Spoofing Attacks and Hijacked Terminal Connections - Jan 1995 (original), Sep 1997 (revised)
This advisory highlights how spoofing can be used to hijack a system or overcome IP-based authentication.
RFC 1948: Defending Against Sequence Number Attacks - May 1996
This RFC proposes a solution for the ISN selection problem. The solution is to have a sequence number space for each connection. This is accomplished by adding a hash of the connection information (srcIP, dstIP, srcPort, dstPort) to the old ISN generator (timer based). The hash should also include some secret data (not guessable). It does not solve the issue of an attacker that can see all of the handshake. Such an attacker can still guess sequence numbers of an ongoing connection.
CERT Vulnerability Note VU#498440: Multiple TCP/IP implementations may use statistically predictable initial sequence numbers - Mar 2001
This is an advisory that there is a statistical weakness in using psuedo-random increments to the sequence number.
CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers - May 2001 (original), Feb 2005 (revised)
This advisory gives more information about the statistical weakness of using pseudo-random increments. It also gives more detailed information about the variations on the attack that can be used. It gives several approaches that can be used to mitigate the problem.

Two interesting whitepapers by Michal Zalewski give a graphical representation of the ISN generator. The author analyzed various ISN generators and plotted them on a graph. The more the points in the graph cluster, the easier it would be for an attacker to guess the next sequence number. A table below each graph also summarizes the attack feasibility for that graph as a percentage. The higher the percentage, the more likely an attacker is to be able to guess the sequence number. The first whitepaper is Strange Attractors and TCP/IP Sequence Number Analysis published in 2001. The second whitepaper is Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later published in 2002. Read through both of these whitepapers to see the importance of a good initial sequence number.

Another intriguing consequence of this research into ISN predictability is using the ISN to fingerprint the system. Even if the operating system has taken care to make its ISN unpredictable, if it has a unique ISN generator, it can still be identified. Take for example the Nmap fingerprinting methods. Michal Zalewski also covers this issue in Chapter 10 of his book Silence on the Wire.

Questions

Email me the answers to these questions as your lab writeup.

Look at the graph for Cisco IOS in the original Strange Attractors article and the 2002 followup. How has Cisco's ISN generator changed? Is this change for the better?
Besides Cisco IOS, name three operating systems that performed poorly in original Strange Attractors article.
Of the poor performers from Question 2, have any improved their generator in the 2002 followup article?
One of the common recommedations in the above articles is to use a cryptographically secure protocol for communication instead of TCP. Give your theory as to why this has not become a widespread solution.
Why is the ability to fingerprint a system based on the ISNs a concern?