Exploiting Sequence Number Leakage: TCP Hijacking in NAT-Enabled Wi-Fi Networks

Exploiting Sequence Number Leakage: TCP Hijacking in NAT-Enabled Wi-Fi Networks

Speakers: Yuxiang Yang

Conference: NDSS Symposium

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

Overview

This talk, presented by Yuxiang Yang at the NDSS Symposium, uncovers a novel and potent off-path TCP hijacking attack targeting Wi-Fi networks that employ Network Address Translation (NAT). The research meticulously details a critical side-channel vulnerability arising from the combination of common NAT port preservation strategies, insufficient Reverse Path Validation (RPV) in routers, and the widespread practice of disabling strict TCP window tracking. This confluence of factors allows an attacker connected to the same Wi-Fi network to infer active TCP connections, manipulate NAT mappings, and ultimately hijack established TCP sessions between other clients and external servers.

The significance of this research cannot be overstated. Unlike many prior Wi-Fi attacks that rely on specific operating system vulnerabilities, ARP poisoning, or creating rogue access points, this new method operates at a fundamental network layer, exploiting router behavior rather than client-side flaws. It is particularly concerning because it demonstrates the ability to bypass common defenses such as AP isolation and ARP prevention, and it impacts enterprise-grade networks as well as home and public Wi-Fi. The widespread nature of the vulnerability, confirmed by an extensive empirical study across 67 router models and 93 real-world networks, underscores a significant and pervasive threat to user privacy and data integrity.

The talk not only outlines the technical specifics of the attack, including methods for TCP Denial-of-Service (DoS), full TCP hijacking, and HTTP injection, but also provides concrete countermeasures. Responsible vulnerability disclosure has led to patches and acknowledgments from numerous vendors, highlighting the critical impact and the collaborative effort to enhance Wi-Fi security. This work serves as a stark reminder that even seemingly secure network configurations can harbor subtle side-channel vulnerabilities that, when chained together, can lead to devastating attacks.

Background

▶ Watch: Introduction to NAT-enabled Wi-Fi vulnerabilities and attack overview (0:00)

Network Address Translation (NAT) is a cornerstone technology for IPv4 address conservation and for abstracting internal network topologies from external entities. When an internal client initiates a connection to an external server, the router translates the client's private IP address and source port to its external (public) IP address and an external port. This translation is recorded in a NAT mapping table, which tracks the internal and external IP addresses and ports, the protocol (e.g., TCP), the session state, and a timeout value. This mapping is crucial for ensuring that reply packets from the Internet are correctly routed back to the originating internal client.

The RFCs do not mandate a fixed strategy for source port translation, leading to diverse implementations. The most prevalent strategy observed is port preservation, where the NAT device attempts to retain the client's original source port. If a collision occurs (i.e., another internal client is already using the same source port to the same external host), the router typically resolves this by selecting a new, often random, unused port. Other less common strategies include random selection, sequential selection, and port overloading. Crucially, NAT mappings have associated timeouts; while ESTABLISHED connections often have long timeouts (e.g., 2 hours 4 minutes), connections in the CLOSE state (e.g., after receiving a RST packet) can have much shorter timeouts, sometimes as low as 1 or 10 seconds, which is a critical enabler for this attack.

Another key vulnerability stems from how routers handle TCP window tracking and Reverse Path Validation (RPV). For performance reasons, many routers do not strictly track TCP window information, meaning they do not rigorously check the sequence and acknowledgment numbers of incoming TCP packets. Open-source router operating systems like OpenWrt and AsusWrt often disable strict TCP window tracking by default using options like nf_conntrack_tcp_no_window_check and ip_conntrack_tcp_be_liberal. While some routers (e.g., AsusWrt-based) might check if the sequence number is within a 2G space, many do not check them at all. This relaxed validation allows an off-path attacker to clear NAT mappings using forged RST packets with arbitrary sequence numbers.

Reverse Path Validation (RPV), proposed by RFC 2827 and RFC 3704, is designed to prevent IP spoofing by verifying that incoming packets could be routed back via the interface they arrived on. Linux systems control RPV via the rp_filter kernel variable, offering disabled (0), strict (1), and loose (2) modes. Despite recommendations for strict mode (1), many real-world routers do not adopt it, often failing to drop packets with spoofed source addresses, especially if they match an existing NAT mapping. This allows an off-path attacker to send spoofed SYN/ACK packets (with the server's IP as source) to infer source ports and forged RST packets (with the server's IP as source) to mistakenly change NAT mapping states to CLOSE, both critical for the attack.

The threat model for this attack involves an off-path attacker who is a malicious client connected to the same Wi-Fi network as the victim but has no direct control over the router. The attacker targets a vulnerable router that acts as the gateway for internal clients to a remote server with which a victim client is communicating. Unlike many prior attacks, this method evades common defenses like AP isolation and ARP prevention and does not rely on specific OS versions or applications. The attacker initially does not know the victim's source port, sequence number, or acknowledgment number—these are the very pieces of information the attack aims to discover. Key requirements for the attack are identifying the router's external IP address, understanding AP isolation status (which affects injection but not DoS/hijacking), and knowing the target server the victim is communicating with.

Key Findings

▶ Watch: Explaining NAT port allocation strategies, especially port preservation (2:30)

The core discovery of this research is a novel side-channel vulnerability that effectively allows an off-path attacker to infer, manipulate, and hijack TCP connections within NAT-enabled Wi-Fi networks. This vulnerability is not a single flaw but a critical chain reaction enabled by three widely prevalent, yet individually seemingly benign, router behaviors: the NAT port preservation strategy, insufficient Reverse Path Validation (RPV), and disabled TCP window tracking.

The research demonstrates that by exploiting this combination, an attacker can:

• Infer the presence of TCP connections: By systematically guessing source ports and observing whether forged SYN/ACK packets are reflected back to the attacker or silently forwarded to a victim, the attacker can precisely identify the victim's active source port (m).
• Evict existing NAT mappings: Forged TCP RST packets, spoofed from the remote server's IP and directed to the router's external IP and the inferred port m, can bypass the router's lax RPV and disabled TCP window tracking. This forces the victim's NAT mapping into a CLOSE state, leading to its rapid clearance (often within 1-10 seconds).
• Reconstruct new NAT mappings and obtain precise sequence/acknowledgment numbers: Immediately after eviction, the attacker sends a forged TCP data packet (with PUSH/ACK flags) to the remote server, using the router's external IP and the inferred port m as the source. The server, interpreting this as coming from the legitimate client, responds with an ACK packet containing the exact current sequence and acknowledgment numbers. This ACK is then routed by the vulnerable NAT to the attacker, who has successfully taken over the mapping.

A critical contribution of this work is the extensive empirical validation of the vulnerability's widespread nature. Laboratory tests on 67 mainstream router models from 30 vendors revealed that a staggering 52 models (from 24 vendors) were vulnerable. Furthermore, real-world evaluations across 93 diverse Wi-Fi networks (including WPA2-Personal, WPA2-Enterprise, and WPA3-Personal) over six months confirmed that 75 networks (81%) were fully vulnerable to the attack.

The practical impact was demonstrated through three attack types:

• SSH DoS Attack: Successfully terminated SSH connections in an average of 17.5 seconds with an 87.4% success rate.
• FTP Hijacking Attack: Enabled attackers to download private files from FTP servers in an average of 19.4 seconds with an 82.6% success rate.
• HTTP Injection Attack: Allowed manipulation of web traffic, such as falsifying stock index data, in an average of 54.5 seconds with a 76.1% success rate.

Crucially, the research highlighted that the SSH DoS and FTP hijacking attacks remain effective even when AP isolation is enabled, a defense often believed to protect clients from each other in enterprise Wi-Fi networks. This distinguishes the attack from many prior insider threats like ARP poisoning, which AP isolation effectively mitigates. The responsible disclosure of these vulnerabilities led to positive feedback, including 10 CVE numbers being assigned, and acknowledgments and repair efforts from seven major vendors (TP-Link, Huawei, Xiaomi, 360, Mercury, Ubiquiti, Linksys), as well as patches from the OpenWrt community. This demonstrates the significant real-world impact and the commitment to improving network security based on these findings.

Technical Deep Dive

▶ Watch: Short NAT mapping timeouts for CLOSE state are critical (3:50)

The attack unfolds in three meticulously crafted phases, leveraging the identified vulnerabilities in NAT, RPV, and TCP window tracking.

Phase 1: Probing the Network

The initial phase focuses on reconnaissance, preparing the attacker by identifying critical network parameters.

1. AP Isolation Status: The attacker first determines if AP isolation is enabled using network scanning tools like Nmap 36 or MacStealer 32. While AP isolation thwarts the TCP injection attack (by preventing communication between local clients), it does not impede the DoS or hijacking attacks. If disabled, the attacker can scan for potential victim clients, which is useful for later injection attempts.
2. Router's External IP Address: Obtaining the router's public or carrier-grade NAT IP is crucial. Two methods are employed:

• Traceroute and RECORD_ROUTE Option: The attacker performs a traceroute to a well-known external host (e.g., 8.8.8.8) to identify gateways. They then ping the second gateway with the RECORD_ROUTE option 41. The returned route information includes the router's external IP address (e.g., 100.64.129.73 in the talk's example).
• Subnet Scanning (Fallback): If RECORD_ROUTE fails, the attacker scans the subnet of the second gateway to find live hosts, then pings them with RECORD_ROUTE. Alternatively, attempting to access web GUIs via HTTP can confirm the router's external IP.

Phase 2: Making Inferences about Active Connections

This is the core of the side-channel attack, where the attacker identifies the victim's active TCP source port (m) without direct observation.

1. Attacker Sends SYN Packet: The attacker sends a SYN packet to the target remote server. The source IP is the attacker's private IP, and the source port is a guessed port n. To avoid detection by server-side NIDS, the TTL is set to a small value (e.g., 2), ensuring it's dropped by intermediate routers.
2. Router's NAT Behavior:

• Case 1 (Port n is NOT active, n != m): The router, employing port preservation, creates a new NAT mapping for the attacker's connection, translating attacker's private IP:port n to router's external IP:port n.
• Case 2 (Port n IS active, n == m): A collision occurs because the victim client already uses port m to the same server. Due to port preservation, the router maintains the victim's mapping. For the attacker's SYN, the router resolves the collision by assigning a different source port, say m', for the attacker's new NAT mapping.

1. Attacker Sends Forged SYN/ACK: The attacker then impersonates the server and sends a forged SYN/ACK packet. The source IP is the remote server's IP, the destination IP is the router's external IP, and the destination port is the guessed port n.
2. Router's RPV Behavior:

• Case 1 (Port n is NOT active): If the router does not strictly enforce RPV (a common vulnerability), it processes the forged SYN/ACK. Since there's an active NAT mapping (router external IP:port n to attacker private IP:port n), the router forwards this forged SYN/ACK directly to the attacker.
• Case 2 (Port n IS active): When the forged SYN/ACK packet with destination port m arrives, the router finds the victim's existing NAT mapping for port m. The router forwards this forged SYN/ACK packet to the victim, not the attacker.

1. Inference: By observing whether it receives its own forged SYN/ACK back, the attacker can infer if the guessed port n is currently in use by a victim client. The attacker systematically iterates through common source port ranges until the victim's active port m is identified.

Phase 3: Hijacking Active Connections

With the victim's source port m identified, the attacker proceeds to hijack the connection.

1. Evict Original NAT Mapping: The attacker sends one or two spoofed TCP RST packets. The source IP is the remote server's IP, the destination IP is the router's external IP, and the destination port is the inferred port m.

• For routers that don't check sequence numbers at all (Type 1), an arbitrary sequence number is sufficient.
• For routers checking within a 2G space (Type 2), two RST packets with sequence numbers x and (x + 2G) % 4G are sent to bypass the check.
• Due to disabled RPV and lax TCP window tracking, the router processes these forged RSTs, transitioning the victim's NAT mapping from ESTABLISHED to CLOSE. After a short timeout (1 or 10 seconds), the mapping is cleared.

1. Construct New NAT Mapping and Intercept SEQ/ACK: In the brief window after the original mapping is cleared, the attacker constructs a new mapping to intercept server responses.

• The attacker sends a forged TCP data packet (with PUSH/ACK flags) to the remote server. The source port is m, and the source IP is the attacker's private IP. The sequence and acknowledgment numbers can be arbitrary.
• The router translates the attacker's private IP but preserves source port m (no collision now). The packet reaches the server.
• The server, receiving a packet from the public IP and port m, believes it's from the legitimate client but with incorrect SEQ/ACK. According to TCP specifications, it responds with an ACK packet containing the exact current sequence and acknowledgment numbers of the victim connection.
• This ACK packet, destined for router external IP:port m, matches the attacker's newly created NAT mapping. The router forwards the ACK packet directly to the attacker. The attacker now possesses the precise SEQ/ACK numbers.

Attack Follow-up Procedures

Once SEQ/ACK numbers are obtained, various malicious activities are possible:

1. TCP DoS Attack: The simplest form. The attacker sends forged TCP RST packets to the server using the obtained SEQ/ACK numbers, causing the server to terminate the victim's connection. This works regardless of AP isolation and is effective for encrypted traffic like SSH or HTTPS.
2. TCP Hijacking Attack: The attacker fully impersonates the victim, sending arbitrary requests to the server using the obtained SEQ/ACK numbers. This can lead to unauthorized access (e.g., downloading private files from an FTP server) and privacy leakage. This also works irrespective of AP isolation.
3. TCP Injection Attack: To poison plaintext traffic (e.g., HTTP responses), the attacker needs to inject forged data and restore the victim's original NAT mapping to maintain client communication.

• The attacker first clears their own temporary NAT mapping.
• To restore the victim's mapping (since the attacker doesn't know the victim's private IP directly), the attacker sends forged ACK packets (source: server, destination port m) to all local hosts identified during Phase 1. When the victim receives this, it responds with its own ACK to the server, which re-establishes the victim's original NAT mapping at the router.
• With the victim's mapping restored, the attacker can inject forged responses by sending crafted data packets to the router's external IP, abusing disabled RPV.
• This attack is thwarted by AP isolation (as the attacker cannot send packets to other local hosts) and by traffic encryption (HTTPS).

Extended Attack Model: Remote TCP DoS Attack

The research also explores an extended model where a remote attacker, not on the same Wi-Fi network, can launch a DoS attack. This model assumes the attacker can spoof source IP addresses, which is feasible as approximately a quarter of autonomous systems still lack source address validation (SAV) according to the Spoofer project 27.

1. Broad RST Packet Flood: The remote attacker sends forged TCP RST packets, covering the entire space of possible source ports, to the public IP address of the vulnerable router.
2. NAT Mapping Clearance: Due to disabled TCP window tracking and RPV, these RST packets clear any NAT mapping for the victim connection.
3. Forged Data Packet Flood: The attacker then sends forged TCP data packets to the server, again spoofing the router's public IP and covering all possible source ports.
4. Connection Termination: The server responds with an ACK packet to the router. However, lacking a corresponding NAT mapping, the router sends an RST packet back to the server, terminating the connection from the server side. The client will then receive an RST from the server.

This remote DoS attack can target millions of potentially vulnerable routers indexed by search engines like FOFA 13 and Shodan 50.

Demo / Proof of Concept

▶ Watch: Routers' relaxed TCP window tracking enables forged RST attacks (4:10)

The talk's empirical study served as a comprehensive proof of concept and demonstration of the attack's real-world feasibility and impact. Rather than a live demo, the research meticulously evaluated the attack across 93 real-world Wi-Fi networks and 67 router models, providing concrete, quantifiable results for each attack type.

For the SSH DoS attack, the proof of concept involved establishing an SSH connection between a victim client (running Windows, Linux, Mac, iOS, or Android) and an SSH server (Ubuntu 22.04, OpenSSH 8.9, OpenSSL 3.0.2). The attacker successfully terminated these connections in an average of 17.5 seconds across vulnerable networks, achieving an 87.4% success rate. This demonstrated the ability to disrupt secure, encrypted communication channels.

The FTP Hijacking attack was demonstrated by setting up an FTP server (Ubuntu 22.04, vsftpd 3.0.3) with a victim client. The attacker successfully intercepted the victim's session, obtained credentials (or bypassed authentication by taking over the session), and downloaded private files belonging to the victim. This was achieved in an average of 19.4 seconds with an 82.6% success rate, showcasing a direct privacy and data integrity breach.

The most complex demonstration was the HTTP Injection attack. Here, the victim client was configured to access a finance website (anonymized as www.ANONYMOUS.com), maintaining a long-lived TCP connection and periodically retrieving data updates. The attacker successfully injected forged HTTP responses, causing the client's web page to display falsified data, such as changing a stock index (HSI) from 19,319 to 20,000 (as depicted in Figure 4 of the original paper). This attack required an average of 54.5 seconds with a 76.1% success rate, illustrating the ability to manipulate plaintext web content.

These experimental results, gathered from diverse operating systems and network environments, unequivocally served as a compelling proof of concept, validating the attack's effectiveness and the widespread nature of the underlying vulnerabilities. The detailed metrics on time costs and success rates underscore the practical threat posed to everyday Wi-Fi users.

Defensive Implications

▶ Watch: Many routers fail to adopt strict Reverse Path Validation (5:15)

The detailed analysis of this novel TCP hijacking attack provides clear guidance for defenders and router manufacturers to enhance Wi-Fi network security. Implementing the proposed countermeasures would effectively break the attack chain.

1. Random Port Allocation: Routers should move away from the widespread port preservation strategy and adopt a random selection strategy when creating new NAT mappings. If the router assigns a random port from a pool of available ports, the attacker cannot infer whether a specific port is in use by an internal host, thereby thwarting Phase 2 (port inference) of the attack. While this might impact some TCP punch-through schemes that rely on port prediction, alternative solutions like TURN relaying 16 exist.

1. Strict Reverse Path Validation (RPV): Routers must strictly adhere to RFC 3704 recommendations and enable strict RPV mode. This would filter out forged packets (e.g., SYN/ACK and RST packets spoofed from the server's IP), preventing the router from processing malicious traffic. This is a critical defense against the attack's ability to manipulate NAT mappings and connection states. Notably, some vendors like ASUS, Netgear, ZTE, Aruba, Cisco Meraki, and newer TP-LINK, Mercury, and Huawei models already implement this. While strict RPV can introduce performance overhead and potentially affect applications like OpenVPN 38, the security benefits often outweigh these concerns, especially given modern hardware capabilities.

1. Strict TCP Window Tracking: Routers, as middle devices, should strictly check the sequence and acknowledgment numbers of all received TCP packets. Historically, this was often disabled for performance reasons. However, the OpenWrt community has actively implemented this mitigation, asserting that the performance impact on contemporary hardware is minimal. Re-enabling strict TCP window tracking would prevent attackers from clearing NAT mappings with forged RST packets and directly obtaining accurate SEQ/ACK numbers, thereby neutralizing Phase 3 of the attack.

1. AP Isolation Awareness: Defenders should understand the nuanced impact of AP isolation. While it effectively thwarts the HTTP injection attack (by preventing the attacker from communicating with local hosts to restore the victim's NAT mapping), it does not protect against TCP DoS or TCP hijacking attacks. For enterprise environments where AP isolation is often deployed, relying solely on it for insider threat mitigation is insufficient against this particular attack vector.

1. Prompt Patching and Updates: Given the responsible vulnerability disclosure and the assignment of 10 CVE numbers, network administrators should prioritize applying firmware updates released by vendors. Manufacturers (e.g., TP-Link, Huawei, Xiaomi, 360, Mercury, Ubiquiti, Linksys, and OpenWrt) that have acknowledged and are working on repairs or have already released patches should be actively monitored. Regular firmware updates are crucial to patch these fundamental network-layer vulnerabilities.

By adopting these countermeasures, the necessary conditions for the attack to succeed are broken, significantly enhancing the security posture of Wi-Fi networks and protecting users from sophisticated off-path TCP hijacking attempts.

Key Takeaways

• A novel off-path TCP hijacking attack leverages a critical combination of NAT port preservation, insufficient Reverse Path Validation (RPV), and disabled TCP window tracking in Wi-Fi routers.
• The attack allows an insider to infer active TCP connections, evict NAT mappings, reconstruct new ones, and obtain precise sequence/acknowledgment numbers, leading to DoS, full hijacking, or data injection.
• The vulnerability is widespread, affecting 52 out of 67 router models from 24 vendors in lab tests, and 81% of 93 real-world Wi-Fi networks.
• The attack is highly effective and fast, with average times ranging from 17.5 seconds for SSH DoS to 54.5 seconds for HTTP injection, demonstrating significant real-world impact.
• Crucially, AP isolation does not prevent TCP DoS or hijacking attacks, making this a potent threat even in enterprise Wi-Fi networks where other insider threats are typically mitigated.
• Responsible disclosure efforts led to 10 CVEs and vendor acknowledgments, with concrete mitigation strategies proposed: random port allocation, strict RPV, and strict TCP window tracking.

About the Speaker(s)

The talk "Exploiting Sequence Number Leakage: TCP Hijacking in NAT-Enabled Wi-Fi Networks" was presented by Yuxiang Yang. The provided transcript and metadata do not include further details about Yuxiang Yang's title or affiliation, but their research presented at the NDSS Symposium demonstrates expertise in network security and vulnerability analysis.