TunnelVision (CVE-2024-3661) 技术原理与 DHCP Option 121 路由泄露分析
TunnelVision(漏洞编号 CVE-2024-3661)是一种针对 VPN(虚拟专用网络)技术的严重设计缺陷漏洞,其核心在于利用 DHCP(动态主机配置协议)中的 Option 121 功能,强制客户端主机的流量绕过加密的 VPN 隧道。该漏洞由 Leviathan Security Group 的研究人员发现,影响了绝大多数支持 DHCP 标准的操作系统,包括 Windows、Linux、macOS 和 iOS。由于该技术利用的是网络协议的基础路由优先级规则而非代码逻辑错误,传统的 VPN“自杀开关”(Kill Switch)在多数情况下无法起到防御作用。
DHCP Option 121 与路由优先级机制
在典型的 TCP/IP 网络配置中,当客户端接入网络时,会通过 DHCP 协议向服务器请求 IP 地址及相关网络参数。DHCP Option 121(在 RFC 3442 中定义)允许 DHCP 服务器向客户端推送“无类静态路由”(Classless Static Routes)。这些路由信息被直接注入客户端的操作系统的路由表(Routing Table)中。
操作系统的路由决策遵循“最长前缀匹配”(Longest Prefix Match, LPM)原则。当存在多条可用路由时,系统会优先选择掩码最长(即范围最精确)的路径。VPN 客户端通常通过创建一个虚拟网卡并设置一个优先级较低的默认路由(如 0.0.0.0/0)来截获流量。然而,如果攻击者通过 DHCP Option 121 推送一条掩码更长(例如 128.0.0.0/1)或更具体的(如特定的目标 IP 地址 /32)路由,系统将优先从物理网卡流出,而不是经过加密的 VPN 隧道网卡。
攻击链路与技术实现
TunnelVision 的攻击场景通常发生在攻击者与目标位于同一局域网(LAN)的环境中。攻击者可以通过架设流氓 DHCP 服务器(Rogue DHCP Server)或通过中间人攻击(MITM)篡改合法的 DHCP 响应报文。攻击流程如下:
- 侦察阶段:攻击者接入公共 Wi-Fi 或企业内网,利用 Zondex 等工具扫描网络中的活跃主机与暴露的服务。
- 伪造响应:当目标主机发起 DHCP 请求(DISCOVER/REQUEST)时,攻击者抢先发送包含 Option 121 字段的 DHCP ACK 包。
- 注入路由:在 Option 121 字段中,攻击者指定具体的路由规则。例如,为了劫持所有流量,攻击者可以发送两条路由:128.0.0.0/1 和 0.0.0.0/1。这两条路由合起来覆盖了整个 IPv4 空间,且比 VPN 默认的 0.0.0.0/0 路由前缀更长。
- 流量旁路:客户端操作系统将这些路由条目的优先级置于 VPN 虚拟网卡之上。流量在离开主机时,不会被封装进 IPsec 或 OpenVPN 隧道,而是以明文形式直接发送到本地网关(即攻击者的设备)。
# 典型的攻击者构造的 DHCP Option 121 路由条目示例 # 目标: 1.2.3.4/32, 网关: 192.168.1.1 (攻击者 IP) Option 121 Data: 20 01 02 03 04 C0 A8 01 01 # 20 是十六进制,表示掩码长度 32 # 01 02 03 04 是目标 IP # C0 A8 01 01 是攻击者控制的网关地址
Kill Switch 的失效原因
许多 VPN 供应商提供的 Kill Switch 功能通过 Windows 过滤平台(WFP)或 Linux 的 iptables 设置规则,旨在禁止非隧道接口的外部流量。然而,TunnelVision 利用的是底层的路由决策逻辑。当操作系统判定某个特定 IP 属于“本地局域网路由”或“比隧道更优的特定路由”时,防火墙规则往往被配置为允许本地子网通信以维持基础网络连接(如 DHCP、ARP 等)。攻击者正是利用这一例外,将全球范围的 IP 伪装成通过本地物理接口访问的特定路由,从而规避了防火墙的拦截。
各操作系统受影响程度对比
不同操作系统对 DHCP Option 121 的实现方式不同,导致其对 TunnelVision 的免疫能力存在差异。下表展示了主要系统的易感性:
| 操作系统 | 受影响情况 | 技术表现 |
|---|---|---|
| Windows | 严重受影响 | 原生支持 Option 121,会自动根据 DHCP 推送的路由更新路由表,优先级极高。 |
| Linux | 受影响 | 取决于网络管理器(如 NetworkManager)。大多数主流发行版默认接受 DHCP 路由。 |
| macOS / iOS | 受影响 | 支持 Option 121。虽然 Apple 有一定的沙箱机制,但路由表依然会被修改。 |
| Android | 免疫 | Android 系统在设计之初就未实现对 DHCP Option 121 的支持,因此不受此漏洞影响。 |
深度检测与缓解措施
针对 CVE-2024-3661 的检测,安全研究人员建议在 VPN 建立连接后,定期检查主机的路由表。如果在路由表中发现了异常的、覆盖范围极大的静态路由(非 VPN 虚拟网段),则极有可能正在遭受 TunnelVision 攻击。企业安全团队可以使用 Secably 提供的漏洞扫描能力,评估内网环境中 DHCP 配置的安全性及其对已知 CVE 漏洞的防御水平。
在缓解策略上,最有效的手段是禁用操作系统的 DHCP Option 121 处理。在 Linux 系统中,可以通过修改 /etc/dhcp/dhclient.conf 移除 classless-static-routes 请求。在 Windows 上,目前尚无直接关闭该选项的系统开关,但可以通过以下方式防御:
防御配置建议
- 使用网络隔离(Network Namespaces):在 Linux 上,通过将 VPN 客户端和应用程序运行在独立的 Network Namespace 中,可以有效隔绝物理网卡的路由污染。
- 防火墙强化:配置严苛的防火墙规则,禁止除 VPN 网关 IP 以外的所有物理网卡流量。需要确保防火墙规则的优先级高于路由表决策。
- 静默 DHCP 路由:在受保护的环境中,通过 VPNWG 架构下的零信任安全接入方案,强制使用静态 IP 配置或由 VPN 客户端完全接管底层网络协议栈,拒绝来自本地 LAN 的不可信 DHCP 响应。
- IPv6 优先:虽然该漏洞主要针对 IPv4 的 DHCP 实现,但在全栈 IPv6 环境下,利用相似的邻居发现协议(NDP)重定向也可能存在风险,需同步开启 IPv6 防火墙保护。
# 在 Linux (NetworkManager) 中忽略 DHCP 推送的路由示例 nmcli connection modify "Wired connection 1" ipv4.ignore-auto-routes yes nmcli connection up "Wired connection 1"
由于 TunnelVision 属于协议级缺陷,其影响范围广且持续时间长。对于依赖公共网络环境(如咖啡厅、机场 Wi-Fi)进行办公的远程员工,仅依靠传统 VPN 加密已不足以保证数据安全。该漏洞的发现促使安全领域重新审视“加密隧道即安全”的盲目信任,转向更深层的网络流量完整性校验与接口隔离技术。