Off-Path TCP Hijacking in Wi-Fi Packet-Size Side Channel

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

· 5 min · 1,147 words

topic/papercomputer science/securitycomputer science/networkingcomputer science/side channels

Paper Summary | NDSS 2025 | Generated by Hermes Agent

Executive Summary: This paper unveils a fundamental side channel in all Wi-Fi networks: the observable size of encrypted wireless frames. Despite WPA2/WPA3 encryption, an off-path attacker can infer TCP sequence and acknowledgment numbers by analyzing frame sizes (56/68/80 bytes for RST/ACK/SACK-ACK respectively), enabling full TCP connection hijacking. The attack terminates SSH sessions in 19 seconds and injects malicious web data in 28 seconds. Tested across 30 routers from 9 vendors (all vulnerable) and 80 real-world Wi-Fi networks (93.75% success rate). The authors disclosed to Wi-Fi Alliance and proposed padding-based mitigations.

1. High-Level Overview

This is arguably the flagship network side-channel paper of NDSS 2025. The core insight is devastatingly simple: even when Wi-Fi frames are encrypted (WPA2/WPA3), their sizes remain observable and are deterministically fixed for different TCP response types. This creates a reliable side channel that leaks TCP connection state to any attacker on the same Wi-Fi network.

The paper bridges a critical gap in Wi-Fi security: while crypto-cracking attacks have been addressed (WEP→WPA3) and implementation bugs patched (ARP poisoning, rogue APs, NAT manipulation), the physical-layer frame size was never considered a leak vector.

2. Problem Statement

Wi-Fi encryption protects frame contents but not frame metadata (size). TCP’s response behavior is inconsistent by design — different trigger conditions produce different response packets (RST, ACK, SACK-ACK), each with a distinct, predictable size due to TCP option fields (timestamp, SACK). An attacker sniffing the victim’s encrypted frames can:

  1. Detect TCP connections (by observing 68-byte challenge ACK responses)
  2. Infer the exact TCP sequence number (via binary search observing 80-byte SACK-ACK vs 68-byte ACK)
  3. Infer an acceptable acknowledgment number (by probing the challenge window)
  4. Hijack the connection (inject RST or malicious data)

3. Core Attack Mechanism (4 Steps)

Step 1: Identify Victim

  • Send ARP requests to discover alive supplicants in the WLAN
  • Obtain <MAC, IP> pairs of potential victims
  • Filter encrypted frames by MAC address in the 802.11 header

Step 2: Detect TCP Connections

  • Impersonate the victim and send forged SYN/ACK packets with guessed client ports to the server
  • If port is correct → server responds with challenge ACK → 68-byte encrypted frame observed
  • If port is wrong → server responds with RST → 56-byte encrypted frame observed
  • Iterate until the correct four-tuple [client IP, client port, server IP, server port] is found
  • Send forged TCP data packets with guessed sequence numbers
  • If seq < RCV.NXT - 1 → server responds with SACK-ACK → 80-byte frame
  • If seq > RCV.NXT + RCV.WND → server responds with ACK → 68-byte frame
  • Binary search within the 4G (2³²) sequence space to pinpoint exact RCV.NXT

Step 4: Infer Acknowledgment Number

  • Exploit RFC 5961 challenge ACK mechanism
  • Send forged ACK packets with guessed acknowledgment numbers
  • If ack falls in challenge window (SND.UNA - 2G, SND.UNA - SND.WND) → 68-byte frame observed
  • Add 2³¹ to the lower boundary to get an acceptable acknowledgment number

Key Size Table

Packet TypeTCP OptionsPacket SizeEncrypted Frame Size
RST—54 bytes56 bytes
ACKTimestamp66 bytes68 bytes
SACK-ACKTimestamp + SACK78 bytes80 bytes

4. Evaluation Results

Lab Experiments

  • Average execution time: 18.78 seconds
  • Average bandwidth: 75.76 KB/s
  • Success rate: 84% (failures due to wireless interference causing missed frames)

Router Testing

  • 30 routers from 9 vendors tested
  • 0 routers could protect victims — 100% vulnerable
  • All generations tested: 802.11n, 802.11ac, 802.11ax

Real-World Deployment

  • 80 real-world Wi-Fi networks (coffee shops, bookstores, enterprises, restaurants)
  • 75/80 (93.75%) successfully hijacked
  • 16 networks used open/WEP (trivial), 64 used WPA2/WPA3

Case Study 1: SSH DoS

  • Terminate victim’s SSH connection in 19 seconds
  • Send forged RST packet to server with correct sequence/ack numbers

Case Study 2: Web Traffic Manipulation

  • Inject malicious JavaScript into victim’s HTTP response in 28 seconds
  • Can modify webpage content, steal cookies, redirect traffic

5. Key Findings and Insights

  1. Frame size is a universal side channel — inherent to all 802.11 standards (a/b/g/n/ac/ax), not a specific implementation bug
  2. Encryption doesn’t help — WPA2/WPA3 protect content but not metadata; padding is not mandatory
  3. AP isolation is insufficient — attackers can still sniff frames via monitor-mode WNICs on shared channels
  4. The attack is off-path — attacker never needs to intercept, modify, or block any packets; purely passive observation
  5. 93.75% real-world success demonstrates this is not a lab curiosity but a practical threat

6. Limitations

  • Wireless interference can cause missed frames (primary failure mode at ~16%)
  • Frame aggregation (802.11ac/ax A-MPDU) can obscure individual frame sizes, though attack still works in many configurations
  • Attack requires the attacker to be on the same Wi-Fi network (not remote)
  • Requires monitor-mode WNIC and knowledge of the Wi-Fi password (for encrypted networks)

7. Countermeasures Proposed

  1. Dynamic frame padding — Modify 802.11 standards to mandate random padding of encrypted frames to a uniform size
  2. TCP specification revision — Make server responses consistent in size regardless of trigger conditions
  3. Channel switching — AP can evict the attacker by switching channels (requires multi-channel support)

8. Relationship to Prior Work

  • Extends prior work on off-path TCP attacks (Qian et al.) to the Wi-Fi domain
  • Differs from Yang et al. (NDSS 2024) which exploited sequence number leakage in NAT-enabled Wi-Fi — this paper’s frame-size side channel is more fundamental
  • The core challenge ACK exploitation is inspired by RFC 5961’s own defense mechanism being turned into an attack vector
  • This paper was later cited by the rejected USENIX Sec ‘26 submission “Off-Path Bitcoin Hijacking via MAC-Layer Side Channels” which applied the same technique to cryptocurrency hijacking

9. TL;DR

Encrypted Wi-Fi frame sizes form a reliable side channel that leaks TCP connection state. An off-path attacker can detect connections (68-byte ACK), infer sequence numbers (80-byte SACK-ACK vs 68-byte ACK binary search), infer acknowledgment numbers (challenge ACK probing), and fully hijack TCP connections — all within ~20 seconds, with 93.75% success across 80 real-world networks. 30/30 routers tested were vulnerable. Mitigation requires frame padding or TCP specification changes.

Sources

  1. NDSS 2025 Paper (DOI): https://dx.doi.org/10.14722/ndss.2025.230305
  2. Paper Page: https://www.ndss-symposium.org/ndss-paper/off-path-tcp-hijacking-in-wi-fi-networks-a-packet-size-side-channel-attack/
  3. PoC Code: https://github.com/Internet-Architecture-and-Security/Packet-Size-Side-Channel-Attack
  4. Authors: Ziqiang Wang (Southeast Univ), Xuewei Feng (Tsinghua), Qi Li (Tsinghua/Zhongguancun Lab), Kun Sun (George Mason), Yuxiang Yang (Tsinghua), Mengyuan Li (Univ of Toronto), Ganqiu Du (China Software Testing Center), Ke Xu (Tsinghua), Jianping Wu (Tsinghua)