利用Wi-Fi帧长实施TCP劫持攻击

今天为大家介绍一篇在Wi-Fi网络中利用加密帧大小劫持TCP链接的工作，该工作由清华大学计算机系徐恪老师团队完成，目前已被NDSS 2025录用。

文章链接：

https://arxiv.org/pdf/2402.12716

Wi-Fi网络为人们的生活提供了方便快捷的无线网络接入，作为一种重要的互联网接入方式，其安全机制在不断优化，从WEP演进到WPA3，以抵御各种密码破解攻击。对现代Wi-Fi网络来说，一个off-path的攻击者（即不在通信路径上）很难从加密的Wi-Fi帧中获得有用的信息（例如，TCP连接中随机的序列和确认号）。此外，Wi-Fi网络还衍生出了一些安全策略（如AP隔离、流氓AP检测等）来对抗ARP投毒和流氓AP攻击。这使得off-path的攻击者很难检测并劫持Wi-Fi网络中其他用户的流量。

然而，我们发现公共Wi-Fi信道中的加密帧大小可以被攻击者利用，推测并劫持受害者的TCP链接。该攻击的威胁模型如图1所示。攻击者和受害者在同一Wi-Fi网络中访问互联网（例如，用户连接到咖啡店的Wi-Fi网络）。攻击者是一个普通用户，没有AP管理权限，也不知道受害者与AP之间的会话秘钥。攻击者设备具备多个无线网卡，其中一个连接到AP，其他的用于嗅探公共Wi-Fi信道中的加密帧。攻击者可以检测并劫持受害者与常用服务器（比如流行网站、邮箱服务器等）的TCP链接。

图1 威胁模型

我们的攻击主要利用了两个特性，第一个是TCP协议栈对于不同TCP报文的响应不一致，并且这些响应由于携带不同的TCP报头选项导致其报文大小不同，如表1所示。第二个是Wi-Fi网络的加密算法不改变密文长度，并且加密的Wi-Fi帧在公共信道中传输。off-path的攻击者可以嗅探受害者的加密帧，并且通过分析加密帧大小推测服务器响应报文类型，进而推测受害者的TCP链接信息。

表1 TCP报文大小分析

为了实施TCP劫持攻击，攻击者需要推测出TCP链接的四元组（即服务器IP和端口号，客户端IP与端口号）、序列号和确认号。攻击者可以通过dig命令（比如"dig www.example.com"）获取服务器IP地址，并通过访问服务器来确认服务器的端口号。因此攻击者还需要推测出客户端的IP和端口号、序列号和确认号来实施TCP劫持攻击。攻击步骤如图2所示。

图2 攻击步骤

步骤1

识别受害者。攻击者在Wi-Fi网络中进行ARP扫描以寻找潜在的受害者。在这一步中，攻击者识别受害者的< MAC,IP >地址对，以监控其加密帧。对于启用AP隔离的Wi-Fi网络，攻击者可以利用DHCP机制获取受害者的< MAC,IP >地址对（技术细节请参见原文）。

步骤2

检测TCP连接。攻击者在检测到WLAN中的受害者后，伪装成受害者，以受害者的局域网IP为源地址，向服务器发送伪造的SYN/ACK报文。同时，攻击者在Wi-Fi信道中监控受害者的加密帧。通过观察受害者是否有接收68字节大小的加密帧，攻击者可以判断受害者与服务器之间是否存在TCP连接。

步骤3

推断序列号。攻击者在检测到受害者的TCP连接后，向服务器发送伪造的带有猜测序列号的TCP数据包。这些伪造的TCP数据包会触发服务器响应SACK-ACK，当它们在Wi-Fi信道中传输时，攻击者会观察到AP向受害者传输了80字节大小的加密帧。通过监控受害者的加密帧，攻击者可以推测出目标TCP连接的正确序列号。

步骤4

推断确认号。利用步骤3测出的序列号，攻击者继续向服务器发送伪造的ACK报文。这些伪造报文会触发服务器响应挑战ACK，挑战ACK在Wi-Fi网络中会被封装为68字节的加密帧发送给受害者。利用挑战ACK，攻击者可以定位服务器的ACK窗口并推测出可接收的确认号。

一旦攻击者推测出受害TCP连接的四元组、序列号和确认号，就可以发起TCP劫持攻击。TCP协议是互联网的重要基础协议，承载着诸多上层应用协议（比如SSH、HTTP等）。因此，TCP劫持攻击可以应用于多种场景，比如实施SSH拒绝服务攻击、HTTP缓存污染等。

1）端到端验证

利用Wi-Fi加密帧，攻击者可以在19秒内实施SSH拒绝服务攻击，在28秒内实施HTTP数据投毒攻击。SSH拒绝服务攻击的经验性时间分布如图3所示，图4展示了攻击者污染受害者HTTP页面的攻击效果。

图3 SSH拒绝服务攻击时间消耗分布

图4 受害者的HTTP页面被篡改

2）真实世界Wi-Fi网络评估

我们在80个真实世界的Wi-Fi网络中进行了广泛评估，被评估的Wi-Fi网络包括咖啡店、餐馆、酒店、电影院等典型场景。评估结果如图4所示，在评估的80个Wi-Fi网络中，有75个（93.75%）Wi-Fi容易受到我们攻击的影响。

图4 真实世界Wi-Fi网络评估结果

我们向Wi-Fi联盟报告了这一问题并得到了他们的确认。我们攻击的根本原因可以归结为两个具体条件的结合。第一个是服务器对不同TCP报文的响应不一致，第二个是上层应用信息通过链路层的加密Wi-Fi帧大小泄露。因此，我们提出了两种对策来缓解该漏洞：

1）调整802.11标准，使AP和Wi-Fi设备能够动态地填充加密帧大小，防止上层应用信息的泄露。

2）修改TCP规范，混淆不同类型TCP报文(如RST、ACK和SACK-ACK)的大小，并调整挑战ACK的触发条件。

此项工作的代码已在本实验室代码仓库中开源，代码链接：

https://github.com/Internet-Architecture-and-Security/Packet-Size-Side-Channel-Attack