Wi-Fi网络下的恶意TCP劫持攻击

为大家介绍清华大学计算机系徐恪老师团队一篇发表于NDSS 2024的文章，其发现了路由器固件中 NAT 映射处理存在的安全漏洞，可被攻击者利用构造发起 TCP劫持攻击，劫持 Wi-Fi 下的 TCP 流量。

背景及威胁模型

Wi-Fi已成为提供互联网接入的最受欢迎的技术之一，许多工作研究了Wi-Fi网络中的会话劫持的可能性，例如，利用WPA2实现漏洞注入伪造的无线帧[1]，通过无线路由器VPN隧道中的侧信道拦截数据包[2]，创建网络流氓克隆[3]，或者发动ARP中毒攻击。随着无线安全机制（如WPA2/WPA3）的部署和其他保护策略（如AP隔离、ARP防护、流氓AP检测）的采用，off-path攻击者（即无法控制路由器）越来越难以获得同一Wi-Fi网络中的其他客户端与外部服务器之间的通信信息。

然而，我们发现路由器固件中的NAT机制存在安全缺陷，可被攻击者利用绕过 TCP 的内置随机化安全保护，从而发动off-path TCP 劫持攻击。威胁模型如图1所示，攻击者和受害者客户端连接到同一Wi-Fi网络访问互联网（例如，陌生人连接到咖啡店的Wi-Fi）。在TCP劫持攻击中[4，5]，攻击者可以选择那些提供常见服务的对象，例如，著名的服务器、网络搜索引擎或社交网站。如果受害者正在访问该服务器，即二者之前存在TCP 连接，为了发动TCP劫持攻击，攻击者需要推断出该TCP连接的客户端源端口，以及双方通信的序列号和确认号。

图1. 威胁模型

推断客户端源端口

图2. 推断客户端源端口

我们发现路由器往往采用 NAT 端口保留策略以及存在缺乏反向路径验证漏洞，使得攻击者可以推断出其他客户端连接的源端口，假设为m。攻击者在遍历整个源端口空间的过程中，可能存在图2中的两种情况：

攻击者测试的端口未被客户端使用，假设为n。首先，攻击者向服务器发送一个 SYN 报文，使用自身 IP 和端口 n 作为源。由于 n 不等于 m，路由器将保留源端口 n 创建一个 NAT 映射，记录此 TCP 连接。然后，攻击者冒充服务器发送一个伪造的 SYN/ACK 报文，其目的地是路由器的外部 IP地址，目的端口是n。由于许多路由器未遵守RFC规范而不检查数据包的反向路径，将直接根据新NAT 映射将该SYN/ACK转发给攻击者。
攻击者测试的端口已经被客户端使用，即为m。当 SYN 包到达路由器时，路由器会因端口冲突而将新映射的源端口m转换为另一个随机端口 m’。之后，当伪造的 SYN/ACK 到达路由器时，因为其中指定的端口是 m 而不是 m’，路由器将根据m对应的原NAT 映射转发给客户端。

攻击者重复上述过程，即更改伪造的 SYN 和 SYN/ACK 包中指定的源端口，然后观察是否可以接收到自己发送的SYN/ACK，直到识别出正确的源端口 m，用于随后的攻击。

获取序列号SEQ和确认号ACK

图3. 获取连接序列号和应答号

图3显示了攻击者获取受害者客户端和服务器之间正常 TCP 连接的序列号和确认号的过程。

首先，攻击者发送伪造的TCP RST报文来清除受害者连接的路由器 NAT 映射，由于大多数路由器出于性能考虑而不会严格检查TCP报文的序列号，然而，这也引入了严重的安全漏洞。在收到伪造的RST报文后，路由器会错误地将NAT表中该TCP连接的 NAT 映射清除。

然后，攻击者使用其私有IP作为源IP地址及端口 m 作为源端口向服务器发送带有 PA 标志的数据报文，在路由器上构建新的映射来替换受害者客户端，并触发服务器返回具有准确序列号和确认号的ACK报文。当ACK报文到达路由器时，它将被路由到攻击者处，攻击者由此直接获取受害者连接的序列号和确认号。

发动TCP连接操纵攻击

一旦攻击者获得了客户端连接使用的源端口、序列号和确认号，就可以发起TCP连接操纵攻击。TCP协议是互联网的重要基础协议，承载着SSH、HTTP、FTP等重要的网络应用协议。因此，针对TCP的劫持攻击可以应用于多种场景。例如，SSH拒绝服务攻击、FTP私有文件下载、HTTP缓存污染等。图 4 展示了攻击者污染受害者HTTP网页的攻击效果。

图4. 受害者网页内容被篡改

实验验证

我们对30家厂商的67款主流路由器进行了测试，包括360、Aruba、ASUS、Amazon、Cisco Meraki、中国移动、Comfast、D-Link、GL.iNet、Google、H3C、华为、IP-COM、iKuai、JdCloud、Linksys、Mercury、Netgear、Netcore、锐捷、创维、腾达、TP-Link、Ubiquiti、Volans、Wavlink、WiMaster、小米、中兴通讯、pfSense等多家厂商的多款路由器，发现其中来自24家厂商的52款路由器容易受到该攻击的影响。

表1. 部分路由器测试结果

此外，我们对93个真实世界的Wi-Fi网络进行了广泛的测量研究，发现75个（81%）真实Wi-Fi网络容易遭受该攻击影响。我们的案例研究表明，终止SSH连接、从FTP服务器下载私人文件和注入虚假HTTP响应包平均需要17.5、19.4和54.5秒，成功率分别为87.4%、82.6%和76.1%。

表2. Wi-Fi网络测试结果

漏洞披露和缓解措施

漏洞披露

我们已通过提交漏洞报告并通过电子邮件联系来向受影响的制造商报告该问题。截至目前，我们已收到 OpenWrt 社区的积极回应，证实了我们的发现并已发布补丁来修复该漏洞，以及七家路由器供应商（即 TP-Link、华为、小米、360、Mercury、Ubiquiti 、Linksys）都已承认我们的报告并正在尝试修复他们的产品。此外，我们还被分配了针对不同供应商的10个CVE编号，其他供应商仍在调查该漏洞。

缓解措施

随机端口分配：路由器在创建新的 NAT 映射时使用随机选择策略。具体来说，路由器可以从可用端口池中选择一个随机端口，并在分配新映射时记录端口转换。
反向路径验证：根据RFC 3704 要求，使用严格模式来过滤伪造的数据包。在我们的测试中，ASUS、Netgear、ZTE、Aruba、Cisco Meraki以及TP-LINK、Mercury、华为某些型号的路由器默认采用此建议，从而能够防御我们的攻击。
TCP 窗口检查：我们认为路由器应该严格检查收到的数据包的序列号和确认号。在披露漏洞后，OpenWrt 已经实施了这种缓解措施。