TCP Spoofing: Reliable Payload Transmission Past the Spoofed TCP Handshake

TCP Spoofing: Reliable Payload Transmission Past the Spoofed TCP Handshake

Speakers: Yepeng Pan; Christian Rossow

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=J1VCBXET7D8

Overview

In the realm of network security, TCP spoofing remains a persistent threat, allowing attackers to establish and utilize TCP connections with a forged source IP address. Historically, the primary motivation for such attacks has been to bypass IP-based authentication mechanisms or evade blocklists, which are common in systems like email servers using SPF, PostgreSQL databases verifying user IPs, or firewalls allowing specific IP ranges to access sensitive data. While modern operating systems have significantly improved the randomization of Initial Sequence Numbers (ISNs), making traditional ISN prediction attacks largely obsolete, the challenge of reliably injecting payloads into a successfully spoofed connection has largely been unaddressed.

This talk, presented by Yepeng Pan and Christian Rossow, delves into novel techniques that overcome the limitations of current TCP spoofing methods. The research introduces two critical primitives: a method to brute-force the server's send window on newly established connections using "ghost ACKs," and a suite of feedback channels that allow an attacker to precisely determine the server's ISN. These advancements fundamentally change the landscape of TCP spoofing, enabling attackers to not only establish a spoofed connection but also to reliably transmit arbitrary data, thus extending the practical impact of such attacks.

The implications of this work are significant for network defenders and protocol designers. By demonstrating practical methods for reliable payload injection, the research highlights critical vulnerabilities in TCP implementations and application-layer protocols. It underscores the need for more robust ACK validation, better isolation of connection establishment states, and careful consideration of information leakage, particularly in common applications like SMTP. The findings have already spurred action within the IETF to enhance TCP ACK validation standards, indicating the immediate relevance and impact of this research.

Background

▶ Watch: Introduction to TCP spoofing and its motivations (0:00)

TCP spoofing fundamentally relies on an attacker's ability to impersonate a legitimate IP address. The traditional approach to establishing a spoofed TCP connection involved predicting the server's Initial Sequence Number (ISN). In the early days of TCP/IP, ISNs were often predictable, allowing an attacker to send a SYN packet with a spoofed source IP, predict the server's SYN-ACK ISN, and then send a final ACK packet to complete the three-way handshake. This would establish a connection from the victim's IP to the server, controlled by the attacker.

However, over the past decades, operating systems have dramatically improved their ISN generation algorithms, making them highly randomized and practically impossible to predict. This enhancement effectively mitigated the predictive ISN attack vector. The contemporary method for establishing a spoofed connection, as discussed in the talk, involves a brute-force approach. An attacker sends a SYN packet with a spoofed victim IP address to the target server. The server responds with a SYN-ACK packet to the victim. Concurrently, the attacker floods the server with a large number of spoofed ACK packets, each guessing a different potential ISN. The hope is that one of these spoofed ACK packets will match the server's actual ISN, thus completing the three-way handshake and establishing the connection.

While this brute-force method can eventually establish a spoofed connection, it introduces a significant challenge: the attacker typically does not know when the connection was successfully established, nor do they know the exact ISN chosen by the server for that particular connection. Without this crucial information, the attacker cannot accurately determine the server's send window or the correct sequence and acknowledgment numbers required to send further data packets. This inability to reliably transmit payload data beyond the initial handshake has historically limited the practical utility of brute-forced TCP spoofing, often confining it to denial-of-service scenarios or simple connection establishment checks rather than full-fledged data exfiltration or command injection. The research presented in this talk directly addresses this critical gap, providing mechanisms for an attacker to reliably inject payloads even when the connection establishment is uncertain.

Key Findings

▶ Watch: First primitive: Injecting payload with 'ghost ACKs' (3:30)

The talk presents two primary attack primitives that enable reliable payload transmission over a spoofed TCP connection, effectively overcoming the challenges of unknown ISNs and send windows. These findings significantly enhance the capabilities of TCP spoofing attacks.

The first key finding is the discovery and exploitation of "ghost ACKs" to brute-force the server's send window on newly established connections. This vulnerability arises from permissive ACK validation in several operating systems (Windows, BSD, and older Linux kernels). These systems, for a brief period after connection establishment, accept ACK numbers that are technically "old" (i.e., before the server's ISN) but are not yet explicitly forbidden by current standards. This allows an attacker to inject data by sending a series of spoofed ACK packets with payloads, effectively guessing the correct ACK value within the server's initial receive window. The researchers noted that Linux has already patched this initial upstream issue, and the problem has been reported to the IETF, leading to ongoing efforts to improve ACK validation in an internet draft.

The second, and arguably more potent, set of findings revolves around the identification and utilization of feedback channels to acknowledge the exact server ISN to the attacker. These feedback channels fall into two categories:

1. SYN cookie-based feedback: This method exploits differences in ISN generation logic in Linux kernels when the SYN backlog queue is full, triggering the use of SYN cookies. By repeatedly probing the server with SYN packets and observing the variability of the generated ISNs, an attacker can infer whether the SYN backlog queue is full or not. A sudden change in ISN variability (from highly variable to less variable, or vice-versa) indicates a state change in the SYN backlog queue, which can signal the successful establishment of a spoofed connection and allow the attacker to deduce the precise ISN. Experiments showed this method could acknowledge the correct ISN in 50% of local setups and 70% of remote setups, with inaccuracies primarily due to network noise and legitimate user traffic.

1. Application-specific feedback channels: These channels leverage the behavior of specific application-layer protocols running on the target server. The talk highlights SMTP as a prime example. By embedding attacker-controlled information (such as a domain name or a specific ISN value) within the payload of a spoofed ACK packet, the attacker can trigger application-layer actions that directly or indirectly reveal the server's ISN. For instance, an SMTP server performing an SPF check by resolving DNS records for a sender domain specified in a spoofed MAIL FROM command can inadvertently leak the ISN if the attacker monitors DNS queries. Similarly, delivering an email to an attacker-controlled mailbox or triggering a bounce message can reveal the ISN embedded in the email's subject or body. The researchers found that at least 25% of the top 10,000 domains with email servers were susceptible to at least one of these SMTP-based feedback channels.

In summary, these findings demonstrate that despite robust ISN randomization, attackers can still achieve reliable payload transmission over spoofed TCP connections by exploiting subtle protocol behaviors and application-layer interactions, posing a renewed threat to IP-based security mechanisms.

Technical Deep Dive

▶ Watch: OS vulnerabilities and industry response to ghost ACKs (4:55)

The technical core of this research lies in two distinct yet complementary attack primitives: exploiting permissive ACK validation for immediate payload injection and leveraging side channels for precise ISN discovery.

Ghost ACKs and Permissive ACK Validation

The first primitive, ghost ACKs, takes advantage of a specific interpretation of TCP's ACK validation rules for newly established connections. According to RFCs, for an unestablished connection, an incoming ACK number must fall within a specific range relative to the sender's send sequence space. Specifically, RCV.NXT <= ACK <= RCV.NXT + RCV.WND, where RCV.NXT is the next sequence number expected, and RCV.WND is the receive window. For a newly established connection, RCV.NXT is typically the server's ISN + 1.

The vulnerability arises because some operating systems, specifically Windows, BSD, and earlier versions of Linux, permit ACK numbers that are before the server's ISN (i.e., ACK < ISN + 1) to be accepted as valid "old" ACKs, even though the server has never sent data corresponding to these sequence numbers. The talk visualizes this by showing Send Unacknowledged (SND.UNA) and Send Next (SND.NXT) pointers. For a new connection, SND.UNA and SND.NXT are both ISN + 1. A permissive window check might still accept ACKs that are less than ISN + 1 as long as they are within a defined "maximum window" range, despite the server having no prior data to acknowledge in that range. These are termed "ghost ACKs" because they acknowledge data that has never been sent.

An attacker can exploit this by simultaneously brute-forcing the server's ISN (to establish the connection) and the server's send window (to inject payloads). Once the initial three-way handshake is spoofed, the attacker can send a series of spoofed ACK packets, each containing a different payload and an incrementing ACK number within the potential initial receive window. Due to window scaling, the maximum window size can be extended up to 1 GB. Even with such a large window, the attacker can split the entire search space into equal window-sized pieces. The researchers estimate that only a few attempts, potentially as few as four, might be sufficient to inject a payload into the connection if the spoofed ACK hits the correct window. When the spoofed ACK with the correct sequence number (relative to the server's receive window) is accepted, its embedded payload is processed by the server. This allows for arbitrary data injection immediately upon connection establishment, without needing to know the precise ISN.

Feedback Channels for ISN Discovery

The second set of primitives focuses on enabling the attacker to learn the exact server ISN, which then allows for full, reliable control of the spoofed connection.

SYN Cookie-based Feedback (Linux)

This method specifically targets Linux's behavior when its SYN backlog queue (the syn_recv_queue) is full. Linux maintains this queue to store information about incoming SYN requests before a full connection is established.

1. Normal SYN-ACK: If the queue is not full, the kernel stores the SYN request and sends a standard SYN-ACK. The ISN for this SYN-ACK is generated using a hash computation over the 5-tuple (source IP, source port, dest IP, dest port, protocol) plus a clock counter that updates frequently, typically every 64 nanoseconds. This results in highly variable ISNs even for repeated SYNs from the same source tuple.
2. SYN Cookie SYN-ACK: If the queue is full, Linux activates SYN cookies to counter SYN floods. Instead of storing the SYN request, the server encodes connection information (including the ISN) into the SYN-ACK's sequence number itself. Crucially, the clock counter used in SYN cookie ISN generation is updated much less frequently, typically every 1 minute. This means that repeated SYN requests from the same source tuple will yield non-inferential (i.e., less variable) ISNs within that 1-minute window.

The attacker leverages this difference:

• The attacker first fills the server's SYN backlog queue by sending a flood of legitimate SYN requests from their own IP. One of these SYN requests will use the victim's spoofed IP.
• Once the queue is full, the attacker sends repeated SYN probes from their own IP address. If SYN cookies are active, they will observe non-inferential (less variable) ISNs.
• The attacker then sends spoofed ACK packets to complete the handshake for the victim's spoofed SYN.
• If the spoofing is successful, the corresponding entry is removed from the SYN backlog queue, making space.
• The attacker again probes the server with SYNs from their own IP. If the queue is no longer full, SYN cookies will deactivate, and the attacker will observe highly variable ISNs again.
• The change in ISN variability (from non-inferential to inferential) acts as a signal that the spoofed connection was successfully established. By correlating this signal with the specific spoofed ACK that was sent, the attacker can deduce the exact ISN used by the server for the spoofed connection.

Experiments showed this method could determine the exact ISN in 50% of local tests and 70% of remote tests. Inaccuracies were primarily attributed to network noise (packet reordering, loss) and legitimate user traffic filling/emptying the queue, which could delay or obscure the signal. SYN cookie clock shifts (every 1 minute) were also a noise source but were easily recognizable.

Application-Specific Feedback Channels (SMTP)

These channels exploit the behavior of specific application protocols. The talk focuses on SMTP as a prominent example, due to its widespread use and common IP-based security mechanisms like Sender Policy Framework (SPF).

1. DNS Resolution via SPF: In a typical SMTP session, after a client connects, it issues a MAIL FROM command specifying the sender's email address and domain. SMTP servers commonly perform SPF checks by resolving the DNS TXT records for the sender domain to verify if the connecting IP (which, in a spoofing scenario, is the victim's IP) is an authorized sender.

• An attacker, after establishing a spoofed TCP connection, embeds a payload in the spoofed ACK that contains a MAIL FROM command with an attacker-controlled domain (e.g., attacker.com).
• The server, upon receiving this payload, attempts to resolve the DNS records for attacker.com to perform the SPF check.
• If the attacker controls the DNS server for attacker.com, they can log the incoming DNS query from the target SMTP server. The timing of this DNS query, relative to the sequence of spoofed ACKs sent, allows the attacker to correlate it with the specific ACK that successfully established the connection and delivered the payload. The ISN can then be precisely inferred.

1. Email Delivery/Bounce Messages: This method directly leverages the email delivery process.

• Direct Delivery: The attacker embeds a payload in the spoofed ACK that instructs the SMTP server to send an email to an attacker-controlled mailbox (e.g., attacker@gmail.com). The server's ISN can be embedded within the email's subject or body. Once the spoofed connection is successful, the email is delivered to the attacker, who can then extract the ISN.
• Bounce Messages: If the attacker cannot register an account on the target server, they can set up their own mail server. The payload instructs the SMTP server to send an email to a non-existent address or an address configured for auto-reply. When the target server attempts delivery and fails, it sends a bounce message back to the sender (the attacker's controlled mail server). The attacker's mail server receives this bounce message, which can contain the ISN embedded by the attacker in the original spoofed payload, thus revealing the ISN.

The prevalence study revealed that at least 25% of the top 10,000 domains with email servers were vulnerable to at least one of these SMTP-based feedback channels, highlighting a significant and widespread weakness.

Demo / Proof of Concept

▶ Watch: How Syn Cookie ISN generation reveals server state (6:40)

While the talk did not feature a live, interactive demonstration in the traditional sense, the researchers thoroughly verified the behavior of ghost ACKs across different operating systems. They explicitly stated that Windows, BSD, and Linux (prior to the patch) all exhibited the ghost ACK vulnerability. This verification implies the existence of a working proof of concept to test and confirm the permissive ACK validation logic. The successful identification of this behavior across multiple platforms underscores the practical applicability of the ghost ACK primitive.

Furthermore, the effectiveness of the feedback channels was rigorously tested in both local and remote environments. For the SYN cookie-based feedback, experiments were conducted to determine the accuracy of ISN acknowledgement, yielding results of 50% in local setups and 70% in remote setups. This quantitative assessment demonstrates a working implementation and validation of the ISN inference mechanism.

For the application-specific feedback channels, particularly those targeting SMTP, a prevalence study was conducted. The researchers tested against the top 10,000 domains with email servers and found that "at least 25% of all these email servers [were] susceptible to at least one of these feedback [channels]." This large-scale testing confirms the widespread viability and impact of these attack techniques in real-world scenarios, effectively serving as a broad-scale proof of concept for the identified vulnerabilities. The details of how these tests were performed, including the specific payloads and monitoring techniques, provide a clear blueprint for replicating and understanding the attack methodologies.

Defensive Implications

▶ Watch: Full attack scenario using Syn Cookie feedback (7:45)

The findings presented in this talk necessitate a reevaluation of current TCP/IP stack implementations and application-layer security practices. Defenders must consider several key areas to mitigate the risks posed by these enhanced TCP spoofing techniques.

First, regarding ghost ACKs and permissive ACK validation, operating system vendors must ensure strict adherence to TCP state machine transitions and window management. The fact that Linux has already patched the initial upstream issue and the IETF is working towards an internet draft to improve ACK validation indicates the urgency of this. Defenders should ensure their systems are running the latest kernel versions and apply patches promptly. Beyond patching, network security devices (like firewalls and intrusion prevention systems) could potentially be enhanced to detect and block ACK packets that fall outside the expected window for newly established connections, especially those acknowledging sequence numbers before the server's ISN.

Second, the SYN cookie-based feedback channel highlights a subtle information leak in Linux's SYN cookie mechanism. While SYN cookies are a crucial defense against SYN floods, their differing ISN generation logic can be abused. Defenders should be aware that rapid changes in ISN generation patterns or the activation/deactivation of SYN cookies could be indicative of an ongoing spoofing attempt. Monitoring tools could be developed to detect these shifts, although distinguishing them from legitimate traffic fluctuations might be challenging. Implementing robust rate limiting on SYN requests from suspicious sources, even if spoofed (by analyzing other network characteristics), could also help, though this is inherently difficult with IP spoofing.

Third, the application-specific feedback channels, particularly those involving SMTP, expose critical vulnerabilities at the application layer.

• DNS Resolution Leakage: Servers performing DNS lookups (like SPF checks) based on attacker-controlled data in initial connection payloads create a powerful side channel. Applications should be designed to minimize information leakage during initial connection phases, especially for data derived from potentially untrusted inputs. If DNS lookups are necessary, they should ideally be performed in an isolated environment or through a mechanism that doesn't reveal timing or other metadata to potential attackers.
• Email Delivery/Bounce Messages: Embedding ISNs in email content or relying on bounce messages for feedback demonstrates how seemingly benign application functionality can be weaponized. Email servers should sanitize or restrict the content that can be included in auto-replies or bounce messages, especially when triggered by connections from unauthenticated sources. Furthermore, organizations should review their email server configurations to ensure that sensitive internal information is not inadvertently leaked through such mechanisms.
• General Application Design: More broadly, any application that processes attacker-controlled data during the initial, unauthenticated phase of a TCP connection and then performs an external action (e.g., database query, external API call, logging to an external system) creates a potential feedback channel. Developers should assume that initial connection payloads are hostile and design applications to validate inputs rigorously and delay external interactions until after full authentication and authorization.

Finally, organizations should strengthen their overall network monitoring and anomaly detection capabilities. Detecting a flood of spoofed ACK packets, unusual connection patterns, or unexpected DNS queries originating from internal servers (in response to spoofed traffic) could signal an ongoing TCP spoofing attack. Implementing strong network segmentation and minimizing the exposure of services that rely heavily on IP-based authentication are also crucial steps.

Key Takeaways

• TCP spoofing remains a viable threat: Despite advances in ISN randomization, brute-forcing techniques combined with new primitives allow attackers to reliably establish and use spoofed TCP connections.
• "Ghost ACKs" enable immediate payload injection: Permissive ACK validation in Windows, BSD, and older Linux kernels allows attackers to inject payloads into newly spoofed connections by brute-forcing the server's receive window.
• Feedback channels reveal exact ISNs: Two main types of feedback channels were identified: SYN cookie-based mechanisms in Linux and application-specific behaviors (e.g., SMTP). These allow attackers to learn the precise server ISN, enabling full control over the spoofed connection.
• SMTP servers are highly vulnerable: Application-specific feedback channels, particularly those leveraging DNS resolution for SPF checks or email delivery/bounce messages, were found to affect at least 25% of the top 10,000 email servers.
• Defenders must patch and re-evaluate: Operating systems require stricter ACK validation (Linux has already patched, IETF is drafting improvements). Applications need to minimize information leakage during connection establishment and be wary of processing untrusted data too early.
• Comprehensive monitoring is crucial: Detecting unusual ISN generation patterns, unexpected DNS queries, or anomalous connection activity can help identify ongoing TCP spoofing attempts.

About the Speaker(s)

The talk "TCP Spoofing: Reliable Payload Transmission Past the Spoofed TCP Handshake" was presented by Yepeng Pan. The research was co-authored by Christian Rossow. The metadata does not provide further details regarding their titles or affiliations beyond their names.