With so much of our business and personal lives relying on the transfer of information between points on the internet, it’s little wonder that cyber-criminals have long favored these connections as a target for their operations. Hijacking connections and/or intercepting data streams offers hackers a prime opportunity to extract valuable information assets, siphon off digital financial ones, or to interject malicious content of their own.
One of the techniques employed by unscrupulous operators in the cyber realm is known as a TCP sequence prediction attack (or TCP sequence number attack).
The Transmission Control Protocol (TCP) is a connection-based protocol which requires a formal connection to be established between a sender and a receiver before any data is passed between them. This formal connection is what’s known as a “three-way handshake”.
Here, a client (the sender) first transmits a SYN segment to a server (the receiver) requesting that a connection be set up. The SYN segment is a TCP data packet with the SYN (request for synchronization) flag turned ON.
At the receiving end, the server or host replies with a SYN-ACK segment (which is a TCP data packet with the synchronization SYN and acknowledge ACK flags on), acknowledging the request.
The client then sends back an ACK (acknowledgment) segment to confirm, establishing the TCP connection.
What’s a Sequence Number?
When the first SYN segment initiating contact is sent by the client, the packet also bears supplementary information, including the address of the source port, the destination port, and an Initial Sequence Number or ISN – a value generated by the TCP of the client system. The SYN-ACK segment returned by the server echoes this Initial Sequence Number, along with other information.
In verifying the integrity of this SYN-ACK packet that’s sent back, the client checks the SYN (synchronization) flag and the Acknowledgment Number – which should correspond to the client’s own Initial Sequence Number + 1. And the ACK segment that the client sends back in confirmation includes an Acknowledgment Number which is set to the server’s Initial Sequence Number + 1.
So sequence numbers play a big part in TCP communications. A sequence number is defined as the figure that TCP associates with the starting byte of data in a particular data packet. An acknowledgment number is always the next anticipated sequence number in an increasing series.
In terms of the layered model for network security, the TCP protocol acts at Layer 4 (The Transport Layer), with packet transfer between hosts being accomplished by layers below Layer 4. TCP uses the sequence number field to take responsibility for ensuring that data packets are delivered to higher layers in the protocol stack in their correct order.
An attacker listening into a TCP exchange could in principle determine the flow of sequence numbers by monitoring the packets moving between two hosts in a data exchange. And in fact, the archives of the Internet Engineering Task Force (IETF) from as far back as 1985 describe a situation where a cyber-attack was mounted based on guessing what sequence numbers that Transmission Control Protocol would use for new connections between two known endpoints.
This vulnerability is confirmed in an excerpt from the standards document RFC 793 (Transmission Control Protocol) concerning the generation of TCP sequence numbers, stating that:
“When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32-bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN’s will be unique.”
Unfortunately, the developers of the BSD Unix TCP/IP stack didn’t adhere to these recommendations. The sequence number for BSD TCP/IP stacks increases by 128,000 every second and by 64,000 for every new TCP connection. Such a sequence is relatively easy to predict and can be much more readily exploited than one which follows the RFC standard. X-Windows, NFS, SunRPC, and many other services which rely upon IP address authentication can be exploited via a successful TCP sequence prediction attack.
Anatomy of a TCP Sequence Prediction Attack
In a typical TCP sequence prediction attack scenario, an attacker would spend some time monitoring the data flow between two hosts, one of which is the targeted system. The attacker would then cut off the other system (which is trusted by the target) from the communication, perhaps via a Denial of Service (DoS) attack – leaving themselves free to take the place of that trusted system, in the eyes of their target.
Having predicted the sequence number of the next packet that the target is expecting from their trusted host, the attacker prepares a packet with the source IP address of the trusted system, and the expected sequence number. This packet will be certain to arrive at its destination before any legitimate information from the trusted host (which has a DoS attack to keep it occupied, and out of the picture). The packet from the attacker may be used as an avenue to gain access to the target system, forcibly terminate a communication, or deliver a malicious payload.
Measures to Prevent a TCP Sequence Prediction Attack
In response to its own observations, the Internet Engineering Task Force (IETF) issued a renewed standard (RFC 6528) in 2012, setting out an improved algorithm for generating Initial Sequence Numbers for TCP communications. It’s designed to increase the robustness of sequence number generation against the kind of predictive analytics and monitoring that allowed cyber-attackers such easy access to sequence numbers under the old regime.
At the enterprise level, operating system manufacturers responded to the threat by introducing new and more unpredictable methods of sequence number generation – a move that’s met with only partial success.
A more effective strategy has been for organizations and network administrators to block source routed packets and data packets with addresses inside of their own networks. Services that rely on IP-based authentication should ideally drop a connection entirely, on detecting that any source routed options are present.
Share this Post