Off-Path TCP Hijacking in Wi-Fi Networks: A Packet-Size Side Channel Attack

Off-Path TCP Hijacking in Wi-Fi Networks: A Packet-Size Side Channel Attack

Speakers: Ziqiang Wang

Conference: NDSS Symposium

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

Overview

This talk, presented by Ziqiang Wang (representing a collaborative effort from Tsinghua University, George Mason University, and Southeast University), unveils a critical vulnerability in modern Wi-Fi networks: an off-path TCP hijacking attack leveraging a novel packet-size side channel. The research demonstrates how an attacker, merely by being connected to the same Wi-Fi network as a victim, can infer sensitive TCP connection parameters even when Wi-Fi frames are encrypted with WPA2 or WPA3. This allows the attacker to either terminate active TCP connections (a denial-of-service attack) or inject malicious data into unencrypted TCP streams.

The significance of this work lies in its broad applicability and the fundamental nature of the discovered side channel. Despite the robust encryption provided by WPA2 and WPA3 at the link layer, the size of the encrypted Wi-Fi frames remains observable to any insider on the network. The researchers reveal that variations in TCP options (such as Timestamp and SACK) directly influence the TCP packet size, which in turn dictates the size of the encapsulating Wi-Fi frame. By carefully crafting TCP packets and observing the resulting Wi-Fi frame sizes, an attacker can deduce randomized TCP sequence and acknowledgment numbers, which are typically designed to prevent such off-path attacks.

This vulnerability poses a substantial threat to the integrity and availability of network communications, particularly in public or shared Wi-Fi environments like coffee shops, airports, and university campuses. The research highlights a subtle yet profound leakage of information that undermines the perceived security of encrypted Wi-Fi. The findings call for a re-evaluation of both Wi-Fi standards and TCP protocol stack implementations to ensure robust protection against such sophisticated side-channel attacks.

Background

▶ Watch: Introduction and off-path TCP hijacking threat model (0:00)

To understand the intricacies of the off-path TCP hijacking attack, it's essential to first grasp several foundational concepts. TCP hijacking generally involves an attacker taking control of an established TCP connection between a victim client and a remote server. This requires the attacker to accurately guess several randomized parameters: the victim's source IP address, source port number, and crucially, the current sequence number and acknowledgment number of the TCP connection. These values are randomized precisely to prevent off-path attackers, who cannot directly observe the traffic, from successfully guessing them and injecting their own packets.

The attack specifically leverages two key TCP mechanisms and one Wi-Fi characteristic. Firstly, TCP options are supplemental fields within the TCP header that provide additional functionality. The talk highlights two important options: the Timestamp option, used to improve Round Trip Time (RTT) measurements and prevent sequence number wrap-around, and the Selective Acknowledgment (SACK) option, which enables more efficient retransmission by acknowledging discontinuous data blocks. The critical insight here is that the presence or absence of these options directly influences the overall size of the TCP packet. For example, a TCP packet carrying only a Timestamp option will be larger than one with no options, and a packet with both Timestamp and SACK options will be larger still.

Secondly, the Challenge-ACK mechanism is a defense against blind window TCP attacks. When a TCP server receives a crafted TCP packet with an incorrect but "in-window" sequence number, it doesn't immediately reset the connection. Instead, it responds with a Challenge-ACK packet back to the client for verification. This mechanism, designed to improve robustness, is ironically leveraged by the attackers to trigger specific server responses that, due to varying TCP options, will have different sizes.

Finally, the core of the side channel lies in Wi-Fi encryption. Modern Wi-Fi networks utilize robust encryption protocols like WPA2 or WPA3 at the link layer to protect user data. While these mechanisms effectively encrypt the payload of Wi-Fi frames, they do not obscure the size of the encrypted frames. An attacker connected to the same Wi-Fi network can passively observe the sizes of all encrypted Wi-Fi frames transmitted over the air. The researchers discovered that the varying sizes of TCP packets (influenced by TCP options and the Challenge-ACK mechanism) translate directly into observable differences in the sizes of the encrypted Wi-Fi frames. This subtle leakage of information, the encrypted frame size channel, becomes the attacker's primary tool for inferring the randomized TCP parameters.

Key Findings

▶ Watch: Key vulnerability: Wi-Fi frame size leaks vital information (3:30)

The primary discovery presented in this research is the existence and exploitability of an encrypted Wi-Fi frame size side channel. This side channel allows an off-path attacker, located on the same Wi-Fi network as a victim client, to infer critical TCP connection parameters, including the source port number, sequence number, and acknowledgment number, even when the Wi-Fi traffic is encrypted by WPA2 or WPA3. This undermines the perceived security of modern Wi-Fi networks, demonstrating that link-layer encryption alone is insufficient to prevent certain types of sophisticated off-path attacks.

The researchers conducted an extensive empirical study to validate their findings:

• Widespread Vulnerability: They tested the frame size channel on a range of mainstream wireless routers and access points from nine different vendors, including Xiaomi, Tendar, and RJ. A significant finding was that all tested devices exhibited the frame size channel, confirming its pervasive nature across diverse hardware implementations.
• Practical Attack Feasibility: The researchers successfully implemented two concrete case studies of the attack:
• SSH Denial-of-Service (DoS): An attacker could terminate an active SSH connection. This attack achieved an average success rate of 84% with an attack time of approximately 19 seconds, leaving the SSH terminal stuck.
• HTTP Data Injection: For unencrypted HTTP connections, the attacker could inject malicious data. This attack demonstrated an average success rate of 72% within approximately 28 seconds.
• Real-World Efficacy: To assess real-world applicability, the attack was tested in 80 various real-world Wi-Fi networks, encompassing diverse environments such as bookshops, coffee shops, restaurants, hotels, and university campuses. A substantial 74% (74 out of 80) of these networks were found to be vulnerable to the presented attacks.
• Identified Mitigations: The study also identified specific network configurations that provided protection. The attack failed in five of the real-world Wi-Fi networks because they had both API isolation and reverse path validation enabled. This highlights that while the side channel is widespread, certain network hardening measures can significantly reduce or eliminate the attack's effectiveness.
• Proposed Solutions: Based on these findings, the researchers proposed two key mitigation strategies: revising the Wi-Fi standard to support random padding for encrypted frame sizes and modifying the TCP protocol stack to ensure consistent responses regardless of TCP option variations, thereby preventing information leakage. These proposals target fundamental changes at both the link and transport layers to address the root causes of the vulnerability.

Technical Deep Dive

▶ Watch: Overview of the four-step attack procedure (4:00)

The core of the off-path TCP hijacking attack hinges on a four-step process designed to infer the randomized TCP parameters that an off-path attacker cannot directly observe. The attacker operates as a malicious insider connected to the same Wi-Fi network as the victim, passively sniffing encrypted Wi-Fi frames over the air.

Step 1: Obtaining the Client's Source IP Address

The first prerequisite for the attacker is to identify the victim client's source IP address. The researchers propose several methods for this:

• Network Scanning Tools: Standard tools utilizing ARP requests can be employed to identify IP addresses of potential victim clients and their corresponding MAC addresses.
• DHCP IP Reservation: In Wi-Fi networks with AP isolation enabled (which prevents direct communication between clients), the attacker can leverage the IP reservation mechanism of the DHCP protocol to deduce IP addresses. More detailed information on this technique is provided in the full research paper.

Step 2: Guessing the Source Port Number

Once the victim's IP address is known, the attacker proceeds to infer the victim's ephemeral source port number, which is randomized at the client side.

• The attacker sends a series of SYN-ACK packets to the remote server. These packets are spoofed to appear as if they originate from the victim client's IP address but carry various guessed source port numbers.
• The server's response varies based on the correctness of the guessed port:
• If the attacker guesses the correct source port number, the server, according to the Challenge-ACK mechanism, will respond with a Challenge-ACK packet. This packet will carry the Timestamp option. Consequently, the encrypted Wi-Fi frame encapsulating this TCP packet will have a distinct size, specifically 68 bytes.
• If the attacker guesses an incorrect source port number, the server will typically respond with a RST (reset) packet. RST packets usually do not carry any TCP options. As a result, the encrypted Wi-Fi frame encapsulating this RST packet will be smaller, typically 56 bytes.
• By passively sniffing Wi-Fi frames and observing the sizes, the attacker can traverse the possible source port space, identifying the port that triggers the 68-byte Challenge-ACK response, thereby revealing the correct source port number.

Step 3: Inferring the Sequence Number

With the source IP and port identified, the attacker moves to the most critical parameter: the victim connection's current sequence number. This step also utilizes spoofed ACK packets and observes frame size differences.

• The attacker sends ACK packets to the server, spoofed with the victim's source IP and port. These ACKs carry various guessed sequence numbers, while the acknowledgment number is randomized.
• The server's response behavior depends on whether the guessed sequence number is within, less than, or greater than the expected sequence number for the connection:
• If the guessed sequence number is less than the exact sequence number of the victim's TCP connection, the server will respond with a SACK-ACK packet. This response will carry both the Timestamp option and the SACK option. The resulting encrypted Wi-Fi frame size will be 80 bytes.
• If the guessed sequence number is greater than the exact sequence number, the server will respond with a standard ACK packet. This ACK packet will typically carry only the Timestamp option. The resulting encrypted Wi-Fi frame size will be 68 bytes.
• The attacker employs a divide-and-conquer strategy across the possible sequence number space. By observing the 80-byte (SACK-ACK) vs. 68-byte (ACK) responses, the attacker can narrow down and eventually pinpoint the exact sequence number.

Step 4: Inferring the Acknowledgment Number

The final step involves determining the acknowledgment number, which is necessary for injecting data.

• The attacker sends spoofed ACK packets with guessed acknowledgment numbers to the server.
• The server's behavior here is simpler:
• If the guessed acknowledgment number is within the acceptable window of the connection, the server will respond with an ACK packet (typically 68 bytes due to the Timestamp option).
• If the guessed acknowledgment number is not in the acceptable window, the server will simply drop the packet and send no response.
• By observing the presence or absence of a response, the attacker can systematically search for the correct acknowledgment number.

Once all four randomized parameters (source IP, source port, sequence number, and acknowledgment number) are successfully inferred, the attacker possesses all the necessary information to hijack the TCP connection. They can then send a spoofed RST packet to the server to terminate the connection (DoS attack) or, if the connection is unencrypted (e.g., HTTP), inject malicious data packets into the stream. The precision of the attack relies entirely on the consistent and observable differences in encrypted Wi-Fi frame sizes (56, 68, and 80 bytes) triggered by specific TCP options and server responses.

Demo / Proof of Concept

▶ Watch: Detailed explanation: Inferring victim's sequence number (6:00)

The researchers conducted a comprehensive empirical study to demonstrate the practical viability and impact of their off-path TCP hijacking attack. Their proof-of-concept involved two distinct attack scenarios and extensive real-world testing.

Case Study 1: SSH Denial-of-Service (DoS)

In the first case study, the attacker targeted an active SSH connection, aiming to terminate it. SSH, being a secure shell protocol, encrypts its payload, meaning data injection is not feasible without breaking the cryptographic integrity. However, the attack successfully demonstrated a denial-of-service capability:

• The attacker was able to terminate the SSH connection with an impressive average success rate of 84%.
• The average attack time for achieving this DoS was approximately 19 seconds.
• Upon successful termination, the victim's SSH terminal would become stuck, rendering it unusable for a period, effectively disrupting the user's secure session.

Case Study 2: HTTP Data Injection

The second case study focused on an unencrypted HTTP connection. This scenario highlighted the more severe consequence of data injection, where an attacker could alter the content exchanged between the victim and the server.

• The attacker successfully injected malicious data into HTTP pages with an average success rate of 72%.
• The average attack time for HTTP injection was slightly longer, approximately 28 seconds.
• This demonstration underscores the risk of an attacker manipulating web content, redirecting users, or even serving malicious scripts on vulnerable unencrypted connections.

Real-World Validation

To underscore the widespread applicability, the researchers conducted experiments in 80 various real-world Wi-Fi networks. These environments included diverse public and semi-public spaces such as bookshops, coffee shops, restaurants, hotels, and university campuses.

• The results were striking: 74 out of the 80 Wi-Fi networks (74%) were found to be vulnerable to at least one of the demonstrated attacks (SSH DoS or HTTP injection). This high percentage indicates that the vulnerability is not theoretical but a practical threat in common Wi-Fi settings.
• The attack failed in five of the tested Wi-Fi networks. This failure was attributed to these networks having both API isolation and reverse path validation enabled. API isolation prevents direct client-to-client communication, making it harder for the attacker to communicate with the victim or spoof packets effectively. Reverse path validation checks if incoming packets arrive on the expected interface, further complicating spoofing attempts. The researchers noted that these configurations are typically found in more carefully administered networks, such as some university networks, suggesting that default settings on many consumer or public access points may lack these crucial protections.

The empirical studies unequivocally confirm that the encrypted Wi-Fi frame size side channel is a practical and potent threat, capable of enabling TCP hijacking in a vast majority of real-world Wi-Fi environments.

Defensive Implications

▶ Watch: Empirical study results and attack case studies (8:00)

The discovery of the encrypted Wi-Fi frame size side channel and its exploitation for off-path TCP hijacking presents significant defensive challenges, requiring a multi-layered approach spanning network configuration, application security, and fundamental protocol design.

Immediate and Practical Defenses for Network Administrators and Users:

1. Enable AP Isolation: As demonstrated by the empirical study, networks with AP isolation enabled were resistant to the attacks. AP isolation prevents direct communication between clients on the same Wi-Fi network, thereby hindering an insider attacker's ability to send spoofed packets that appear to originate from the victim or to directly interact with other clients. Network administrators should enable this feature on access points, especially in public or shared Wi-Fi environments.
2. Enable Reverse Path Validation (RPV): The other key defense observed in the resistant networks was Reverse Path Validation. RPV checks if an incoming packet's source IP address is reachable via the interface it arrived on. This helps prevent IP spoofing, which is central to the described attack. Implementing RPV on routers and firewalls can significantly mitigate the threat.
3. Mandate HTTPS/TLS for all Sensitive Traffic: While the attack can terminate any TCP connection (DoS), its ability to inject malicious data is limited to unencrypted connections (like HTTP). For all sensitive web traffic, users and developers should prioritize and enforce HTTPS or other TLS/SSL protected protocols. This end-to-end encryption ensures data integrity and confidentiality, even if the underlying TCP connection is compromised via side channels. Even if an attacker successfully hijacks the TCP session, they cannot decrypt or meaningfully alter the encrypted payload without the session keys.
4. VPN Usage: Users in untrusted Wi-Fi environments should consider using a Virtual Private Network (VPN). A VPN encrypts all traffic from the client to a trusted VPN server, effectively creating a secure tunnel that bypasses local network vulnerabilities and prevents local attackers from observing or manipulating traffic, regardless of Wi-Fi encryption status.

Proposed Long-Term Solutions and Standard Revisions:

The researchers propose two fundamental changes to address the root causes of the vulnerability:

1. Revise Wi-Fi Standard for Random Frame Padding: The most direct mitigation for the side channel itself is to eliminate the information leakage. The researchers have reported the vulnerability and the potential for abuse of the side channel to the Wi-Fi Alliance. Their suggestion is to modify the Wi-Fi standard (e.g., WPA3 and future iterations) to incorporate random padding for encrypted Wi-Fi frame sizes. By adding random, non-functional data to frames, their observable size would become inconsistent and uncorrelated with the actual TCP packet size, thereby obscuring the side channel. This would require a concerted effort from the Wi-Fi Alliance and hardware manufacturers.
2. Modify TCP Protocol Stack for Consistent Responses: The attack heavily relies on the server's varying TCP responses based on options (Timestamp, SACK) and the Challenge-ACK mechanism. A more robust defense at the transport layer would involve modifying the TCP protocol stack to ensure consistent responses to different types of TCP packets, particularly those with out-of-window sequence numbers. If all Challenge-ACKs, SACK-ACKs, and standard ACKs were padded to a uniform size, or if their options were handled in a way that didn't reveal size differences, the information leakage would be prevented. This would require updates to operating system TCP/IP stacks and server implementations.

These proposed long-term solutions highlight that addressing this vulnerability effectively requires coordinated efforts across different layers of the networking stack, from the Wi-Fi physical/link layer to the TCP transport layer.

Key Takeaways

• Encrypted Wi-Fi frame size is a critical side channel: Despite WPA2/WPA3 encryption, the observable size of Wi-Fi frames leaks information about the encapsulated TCP packet's options, enabling off-path attacks.
• Off-path TCP hijacking is practical in Wi-Fi networks: An insider attacker on the same Wi-Fi network can infer randomized TCP parameters (source port, sequence number, acknowledgment number) to terminate connections or inject data.
• TCP options and Challenge-ACK are key enablers: The attack leverages the varying sizes introduced by TCP Timestamp and SACK options, and the Challenge-ACK mechanism, to trigger distinct, observable Wi-Fi frame sizes (e.g., 56, 68, 80 bytes).
• Widespread real-world vulnerability: The attack was successful in 74% of 80 diverse real-world Wi-Fi networks, demonstrating its pervasive threat in public and shared environments.
• Existing network configurations offer partial defense: Enabling both AP isolation and Reverse Path Validation can mitigate the attack, as evidenced by its failure in 5 protected networks.
• Long-term solutions require fundamental changes: Effective, universal defense necessitates revisions to the Wi-Fi standard (random frame padding) and modifications to TCP protocol stacks (consistent responses) to eliminate the side channel at its source.

About the Speaker(s)

The talk "Off-Path TCP Hijacking in Wi-Fi Networks: A Packet-Size Side Channel Attack" was presented by Ziqiang Wang. The speaker introduced the work as a collaborative effort involving researchers from Tsinghua University, George Mason University, and Southeast University, specifically mentioning Yan Yang from Tsinghua University in the introduction. The research focuses on uncovering novel side channels in network protocols and their implications for security, particularly in Wi-Fi environments and TCP/IP communications. Their work contributes to understanding and mitigating sophisticated off-path attacks that exploit subtle information leakages.