CVE-2024-3661：DHCP Option 121 与路由优先级操纵
CVE-2024-3661，亦被称为 TunnelVision，是一种利用 DHCP 协议中的 Option 121（无类静态路由，Classless Static Routes）来绕过 VPN 加密隧道的攻击技术。该漏洞并非源于 VPN 协议（如 OpenVPN、WireGuard 或 IPsec）本身的加密缺陷，而是利用了现代操作系统路由查找机制中“最长前缀匹配”（Longest Prefix Match）的固有逻辑。通过在受害者加入网络时提供恶意 DHCP 配置，攻击者可以强制受害者的流量跳过 VPN 虚拟网卡，直接通过物理网关以明文形式流出。
DHCP Option 121 的技术背景
DHCP Option 121 定义在 RFC 3442 中，允许 DHCP 服务器在分配 IP 地址的同时，向客户端推送一组静态路由规则。这些规则通常用于告知客户端如何到达本地网络之外的特定子网。在标准的 VPN 工作流程中，VPN 客户端通常会创建一个虚拟网络接口（如 tun0 或 utun1），并添加一条覆盖全局的路由（通常是 0.0.0.0/0 或两条 0.0.0.0/1 和 128.0.0.0/1），试图捕获所有传出流量。
然而，当攻击者控制了受害者所在的局域网 DHCP 服务器，或者通过 ARP 欺骗伪造 DHCP 响应时，可以向受害者推送比 VPN 路由更为精确的路由条目。例如，若攻击者推送一条指向 8.8.8.8/32 的路由，根据路由表的匹配规则，操作系统会优先选择这条 /32 的特定路由，而不是 VPN 提供的 /0 或 /1 路由。这导致发往该 IP 的数据包完全绕过隧道加密。
路由优先级对比表
| 路由类型 | 目标网络 | 子网掩码长度 | 优先级（匹配原则） |
|---|---|---|---|
| 常规 VPN 路由 | 0.0.0.0/0 | 0 | 最低（默认路由） |
| 常见 VPN 加固路由 | 128.0.0.0/1 | 1 | 低 |
| DHCP Option 121 推送 | 192.168.1.0/24 | 24 | 高 |
| TunnelVision 攻击路由 | x.x.x.x/32 | 32 | 最高（最长匹配） |
攻击实现深度解析
实施 TunnelVision 攻击的核心在于建立一个能够响应恶意 Option 121 载荷的 DHCP 环境。攻击者首先需要确保其处于受害者的二层网络（L2 Network）中。通过使用诸如 dnsmasq 的工具，攻击者可以配置一个恶意的 DHCP 服务。以下是一个典型的攻击配置示例，用于将流量重定向至攻击者控制的网关：
# dnsmasq.conf 配置示例 interface=eth0 dhcp-range=192.168.1.10,192.168.1.100,255.255.255.0,12h # 设置 Option 121：将特定目标（或全网段）路由指向攻击者 IP (192.168.1.1) # 格式：dhcp-option=121, [目标网络/掩码], [网关IP] dhcp-option=121, 1.2.3.4/32, 192.168.1.1, 0.0.0.0/0, 192.168.1.1
当受害者主机执行 DHCP 请求时，它会收到这些路由条目。即使受害者随后启动了 VPN，操作系统的内核路由表也会保留这些由物理接口获得的特定路由。在进行互联网资产探测或内部网络拓扑分析时，研究人员常使用 Zondex 来识别局域网内暴露的非授权 DHCP 服务，以预防此类中间人攻击的源头。
攻击步骤流
- 侦听与响应： 攻击者在本地链路上监听 DHCP Discover 数据包。
- 注入路由： 在 DHCP Offer/Ack 中包含 Option 121，声明
0.0.0.0/0的网关为攻击者的物理 IP，或者针对目标 IP（如公司办公网段）设置多条/24或更细碎的路由。 - 建立侧信道： 由于受害者的流量现在通过攻击者的网关转发，攻击者可以截获并分析所有未经过应用层加密（如 HTTPS 之外的 DNS、HTTP、SMTP）的数据。
- 流量去匿名化： 即使流量在应用层是加密的（如 TLS），攻击者也可以通过数据包大小和频率分析（流量指纹）来确定受害者的访问目标，从而彻底破坏 VPNWG 所定义的典型 VPN 隐私保护模型。
不同操作系统的受影响程度
CVE-2024-3661 的影响范围非常广泛，但由于各操作系统对 DHCP 标准的实现差异，其实际表现有所不同。由于 Android 系统原生不支持 DHCP Option 121，它在很大程度上免疫这种特定的攻击方式。然而，桌面端系统（Windows, Linux, macOS）表现出严重的脆弱性。
| 操作系统 | 是否受影响 | 技术原因 |
|---|---|---|
| Windows | 是 | 完全遵循 DHCP Option 121，且路由优先级高于 VPN 虚拟接口。 |
| Linux (NetworkManager) | 是 | 默认处理 Option 121，路由表会优先匹配最长前缀。 |
| macOS | 是 | 内核路由机制允许 DHCP 注入的静态路由覆盖全局隧道。 |
| Android | 否 | 不解析 DHCP Option 121，默认通过 DHCP 指定的网关仅作为兜底。 |
| iOS | 部分受限 | 取决于 VPN 具体的实现类（如 NetworkExtension），但在某些配置下仍可绕过。 |
绕过防御机制的进阶手段
一些高级 VPN 客户端试图通过监控路由表并强制重新设置默认网关来防御此类攻击。然而，TunnelVision 可以通过不断发送 DHCP 续租包（DHCP Renew）或使用更细化的路由划分（将整个互联网划分为两个 /1 路由或多个 /2 路由）来对抗这些缓解措施。对于需要高强度匿名性的研究人员，单纯依靠操作系统层面的 VPN 往往不足，结合 GProxy 提供的应用层代理节点可以建立多层过滤机制，确保即便底层路由被劫持，核心流量依然能够保持在预定的代理链路内。
Linux 下的路由冲突示例
在 Linux 环境下，可以使用 ip route 命令观察到这种冲突。假设 VPN 已经连接并在 tun0 上设置了 0.0.0.0/1，但恶意 DHCP 服务器推送了更具体的路由：
# 正常的 VPN 路由 0.0.0.0/1 dev tun0 scope link 128.0.0.0/1 dev tun0 scope link # 被攻击后注入的恶意路由 104.21.75.0/24 via 192.168.1.1 dev eth0 proto dhcp metric 100
在这种情况下，访问 104.21.75.x（例如某个受保护的 Web 服务）的流量将完全绕过 tun0，通过 eth0 发送到 192.168.1.1，攻击者在此处即可捕获到原始流量。
缓解与修复策略
由于该漏洞利用的是协议设计层面的缺陷，彻底修复具有挑战性。主要的缓解措施集中在隔离路由域和增强客户端过滤逻辑：
- 网络命名空间隔离（Linux）： 将 VPN 客户端和需要加密的应用运行在独立的 Network Namespace 中。在这种配置下，物理接口的 DHCP 路由无法直接影响命名空间内部的路由表。
- 防火墙策略： 在本地防火墙（如
iptables或nftables）中强制执行出口过滤规则，仅允许流量通过 VPN 虚拟接口。例如：iptables -A OUTPUT ! -o tun0 -j DROP（需排除必要的 VPN 握手流量）。 - 禁用 DHCP Option 121： 在某些 Linux 发行版中，可以通过配置 DHCP 客户端（如
dhcpcd.conf）禁用classless_static_routes选项。 - 静态 IP 配置： 在受信任程度较低的网络环境中，手动配置静态 IP 和网关，不依赖 DHCP 获取路由信息。
在企业级环境中，防御 TunnelVision 需要从基础设施层面入手，例如在交换机端口上开启 DHCP Snooping，防止未经授权的 DHCP 服务器接入网络。此外，对于远程办公设备，采用 Zero Trust Network Access (ZTNA) 架构代替传统的全隧道 VPN 也能在一定程度上缓解路由劫持风险，因为 ZTNA 通常基于应用层代理而非底层的三层路由转发。