This post and paper were co-authored by Xuewei Feng, Qi Li, Kun Sun, Ziqiang Wang, and Ke Xu.
Wi-Fi has emerged as one of the most popular technologies for providing Internet access, but it is also frequently exploited by malicious actors to launch various attacks. With the deployment of wireless security mechanisms like WPA2/WPA3 and the adoption of other protective strategies such as Access Point (AP) isolation, Address Resolution Protocol (ARP) protection, and rogue AP detection, off-path attackers (those unable to control the router) are finding it increasingly difficult to obtain confidential information of Wi-Fi users.
Our recent discovery in router firmware exposes a security flaw in routers’ Network Address Translation (NAT) mapping handling, which can be exploited by attackers to bypass TCP’s built-in randomization. This facilitates off-path TCP hijacking attacks, intercepting Wi-Fi TCP traffic. Our research paper detailing the attack has been accepted by NDSS 2024,
Figure 1 illustrates the scenario where an attacker and a victim client are connected to the same Wi-Fi network to access Internet services (for example, consider strangers connecting to the same Wi-Fi network of a coffee shop). For the attacker to hijack the TCP connection between the victim and the server offering common services such as social media or online finance, the attacker must detect the existence of the TCP connection first. Upon confirmation, the attacker then proceeds to infer the sequence and acknowledgment numbers of the ongoing bidirectional communication.
Attack steps
We’ve observed that routers often employ port preservation strategies during NAT and lack reverse path validation as required by RFC 3704, enabling attackers to deduce the source ports of other client connections. In the first step, following the method illustrated in Figure 2, the attacker can deduce the source port of other clients by altering the source port numbers specified in the forged SYN and SYN/ACK packets, then observing if it can receive the SYN/ACK sent by itself until identifying the correct port used by the victim client for subsequent attacks.
We’ve found that most routers, for performance reasons, do not rigorously inspect the sequence numbers of TCP packets. Consequently, this introduces serious security vulnerabilities that attackers can exploit by crafting forged reset (RST) packets to maliciously clear NAT mappings in the router. In the second attack step, the attacker proceeds to steal the sequence number (SEQ) and acknowledgment number (ACK) of the normal TCP connection between the victim client and the server, as depicted in Figure 3.
Once the attacker has obtained the source port, sequence number, and acknowledgment number used by the client connection, it can initiate TCP connection manipulation attacks. The TCP protocol is a critical foundational protocol of the Internet, carrying important network application protocols such as SSH, HTTP, and FTP. Therefore, hijacking attacks targeting TCP can be applied across various scenarios. For instance, SSH denial of service attacks, FTP private file downloads, and HTTP cache pollution, among others. Figure 4 illustrates the effect of an attacker poisoning a victim’s HTTP webpage.
Empirical study
We conducted tests on 67 mainstream routers from 30 different manufacturers, including 360, Aruba, ASUS, Amazon, Cisco Meraki, China Mobile, Comfast, D-Link, GL.iNet, Google, H3C, Huawei, IP-COM, iKuai, JdCloud, Linksys, Mercury, Netgear, Netcore, Ruijie, Skyworth, Tenda, TP-Link, Ubiquiti, Volans, Wavlink, WiMaster, Xiaomi, ZTE, pfSense, and others. Among these, we found that 52 routers from 24 manufacturers were susceptible to this attack. The test results are illustrated in Table 1.
Additionally, we conducted measurement studies on 93 real-world Wi-Fi networks and found that 75 (81%) of them were susceptible to this attack. Our case studies indicate that terminating SSH connections, downloading private files from FTP servers, and injecting false HTTP response packets on average took 17.5, 19.4, and 54.5 seconds, respectively, with success rates of 87.4%, 82.6%, and 76.1%. The detailed experimental results are shown in the paper.
Mitigation
We have registered the issue to the affected manufacturers by submitting vulnerability reports and contacting them via email. As of now, we have received a positive response from the OpenWrt community, confirming our findings and releasing patches to fix the vulnerability. Additionally, seven router vendors (namely TP-Link, Huawei, Xiaomi, 360, Mercury, Ubiquiti, and Linksys) have acknowledged our report and are actively working to fix their products. Furthermore, we have been assigned 10 CVE identifiers for different vendors. Other vendors are still investigating the vulnerability.
To mitigate this attack, we suggest three countermeasures:
- Random port allocation: Routers should employ a random selection strategy when creating new NAT mappings.
- Reverse path validation: Following the recommendation of RFC 3704, strict mode is utilized to filter out spoofed packets. In our testing, routers from ASUS, Netgear, ZTE, Aruba, Cisco Meraki, TP-LINK, and Mercury default to this recommendation, thus enhancing defence against our attacks.
- TCP window checking: We advocate for routers to rigorously inspect the sequence and acknowledgment numbers of received packets. OpenWrt has already implemented this mitigation after our disclosure.
Yuxiang Yang is a PhD student. His research interests are network security and program analysis.
Xuewei Feng works on network security from a large-scale Internet measurements point of view.
Qi Li is an associate professor at Tsinghua University. His research interests are in network and system security.
Kun Sun is a professor at George Mason University. His research focuses on systems and network security.
Ziqiang Wang is a PhD student. His research focuses on network security.
Ke Xu is a professor at Tsinghua University. His research focuses on Internet architecture and network security.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Nice attack and write-up.
One nit: the last step in Figure 2 says “dst.ip=victim”, yet the arrow goes to the attacker. Based on previous messages it seems the text should say “dst.ip=attacker” for that last step.