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:

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.
  1. 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?
  2. Besides Cisco IOS, name three operating systems that performed poorly in original Strange Attractors article.
  3. Of the poor performers from Question 2, have any improved their generator in the 2002 followup article?
  4. 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.
  5. Why is the ability to fingerprint a system based on the ISNs a concern?