Lab 7 - TCP Initial Sequence Number Vulnerability

Due: Thursday by 5pm

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)   <--- From ISNb, X can guess next ISN, ISNb'
   X->B: Closes connection      <--- No longer needed
   Ax->B: SYN, ISNx'            <--- From attacker, spoofing A
   B->A: SYN, z, ACK(ISNx')     <--- Goes to real A, z = ISNb'
   Ax->B: ACK(ISNb')            <--- 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.

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 (alternative: http://lcamtuf.coredump.cx/oldtcp/tcpseq.html), published in 2001. The second whitepaper is Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later, published in 2002.

Another intriguing consequence of this research into ISN predictability is using the ISN to fingerprint the system. Take for example the Nmap fingerprinting methods or Chapter 10: Advanced Sheep-Counting Strategies in Michal Zalewski's book "Silence on the Wire". If an operating system has a unique ISN generator, it may no longer be very vulnerable to spoofing, but can now be identified.

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?