揭秘 TunnelVision (CVE-2024-3661)：利用 DHCP Option 121 绕过 VPN 流量加密

CVE-2024-3661 (TunnelVision) 漏洞原理深度分析

CVE-2024-3661，通常被称为 "TunnelVision"，是一种针对 VPN 流量加密的协议级漏洞利用技术。该漏洞的核心机制并非源于 VPN 协议本身的加密算法缺陷（如 OpenVPN、WireGuard 或 IPsec），而是源于操作系统对 DHCP（动态主机配置协议）中 Option 121（Classless Static Route，无类别静态路由）的处理逻辑。通过利用这一机制，局域网内的攻击者（Local Network Adversary）可以在受害者建立 VPN 连接的情况下，强制将受害者的流量重定向到本地网关，从而绕过加密隧道，实现流量的明文窃听与监控。

DHCP Option 121 与操作系统路由优先级

DHCP Option 121 在 RFC 3442 中定义，允许 DHCP 服务器在分配 IP 地址的同时，向客户端推送一组静态路由条目。其设计初衷是为了方便复杂的局域网环境（例如具有多个子网的企业内部网络）能够引导客户端访问特定的内部资源。然而，在当前的操作系统路由决策算法中，存在一个基础原则：最长前缀匹配（Longest Prefix Match, LPM）。

当 VPN 客户端连接成功后，它通常会创建一个虚拟网络接口，并向操作系统的路由表中添加一条默认路由（Default Route），通常表现为 0.0.0.0/0。这意味着所有未指定具体路径的流量都应通过该加密隧道。但是，如果攻击者控制了受害者连接的 DHCP 服务器（或通过 ARP 欺骗模拟 DHCP 响应），他们可以利用 Option 121 推送更具体的路由，例如：

• 0.0.0.0/1
• 128.0.0.0/1

根据 LPM 原则，这两条掩码长度为 1 的路由优先级均高于 VPN 创建的 0.0.0.0/0 路由。由于这两条路由合起来覆盖了整个 IPv4 地址空间，受害者的系统会认为所有目的地流量都应该通过本地局域网网关发送，而不是加密隧道。虽然用户依赖 VPNWG 提供的加密服务来保护数据隐私，但 TunnelVision 暴露了底层操作系统路由机制中的这种信任缺陷，导致 VPN 的“全隧道”（Full Tunnel）保护名存实亡。

攻击场景与实施技术路径

要成功实施 TunnelVision 攻击，攻击者必须位于受害者的局域网内。以下是攻击者的典型技术路径：

1. 部署伪造 DHCP 服务器：攻击者在公共 Wi-Fi 或受损的公司网络中运行一个恶意的 DHCP 服务器。当目标设备尝试获取 IP 地址时，恶意服务器会抢先响应。

2. 注入 Option 121 路由：在 DHCP 响应中，恶意服务器不仅提供 IP 地址，还包含精心构造的 Option 121 字段。这些路由条目将受害者的流量引导至攻击者的 IP 地址，作为网关转发。

# ISC DHCP Server 配置示例（恶意注入 Option 121）
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

# 将流量分割为两个 /1 子网，强制绕过 0.0.0.0/0
option rfc3442-classless-static-routes 1, 0, 192, 168, 1, 1,  # 0.0.0.0/1 -> 192.168.1.1
                                       1, 128, 192, 168, 1, 1; # 128.0.0.0/1 -> 192.168.1.1

3. 流量转发与解密：此时，受害者的 VPN 客户端显示连接正常，虚拟网卡依然处于激活状态，且可能仍然存在心跳包流量。然而，所有的用户应用程序流量（浏览器、邮件、IM 软件）都通过物理网卡明文流向攻击者的设备。攻击者可以使用抓包工具捕获这些数据，或者进一步进行 DNS 劫持。

各操作系统对 CVE-2024-3661 的受影响情况

由于该漏洞源于对 RFC 标准的实现差异，不同的操作系统表现各异。下表展示了主要系统平台在面对 Option 121 注入时的安全性表现：

深度解析：为什么 VPN Kill Switch 无法防御？

传统的 VPN "Kill Switch"（终止开关）通常基于防火墙规则（如 iptables 或 Windows Filtering Platform）。它们的作用是：如果 VPN 接口掉线，则禁止流量通过物理网口。然而，在 TunnelVision 攻击中，VPN 连接并未掉线。加密隧道在逻辑上仍然是开启的，加密进程仍在运行，虚拟网卡也未消失。攻击是通过修改路由表的“偏好”来诱导操作系统选择错误的路径。从操作系统的角度看，发往 0.0.0.0/1 的流量是合法的本地路由行为，因此防火墙规则可能认为这是预期的本地子网通信，从而放行流量。

在评估企业网络边界安全性时，使用 Secably 等工具对 DHCP 配置和潜在的中间人攻击风险进行漏洞扫描至关重要。此类工具可以帮助识别网络内是否存在非法 DHCP 服务器或异常的路由配置，从而预警此类针对 VPN 的侧向攻击。

缓解措施与防御方案

由于 CVE-2024-3661 是一个底层架构层面的缺陷，单纯升级 VPN 软件可能无法完全解决问题。以下是目前推荐的几种缓解策略：

1. 禁用 DHCP Option 121 解析

这是最直接的修复方法。在 Linux 系统中，可以配置 DHCP 客户端（如 dhclient）忽略 Option 121。在 /etc/dhcp/dhclient.conf 中，移除 rfc3442-classless-static-routes 的请求项：

# 修改 dhclient.conf 示例
# request subnet-mask, broadcast-address, time-offset, routers,
#         domain-name, domain-name-servers, host-name,
#         rfc3442-classless-static-routes; # 注释掉此行

2. 利用网络命名空间 (Network Namespaces)

对于高级 Linux 用户，建议在独立的网络命名空间中运行 VPN 和受保护的应用程序。这种物理层面的隔离可以确保应用程序只能看到 VPN 的虚拟网口，而无法感知由物理网口的 DHCP 服务器推送的恶意路由表。这不仅能防御 TunnelVision，还能防止大多数侧信道泄露。

3. 强制执行防火墙严格策略

重新定义防火墙规则，使其不仅仅根据“接口状态”拦截流量，而是根据“目标地址范围”强制流量。如果流量的目标地址不是本地局域网段（例如 192.168.1.0/24），则必须强制路由至 VPN 接口，拒绝任何发往物理网关的非本地流量。这种“白名单”路由模式能够有效对抗 Option 121 的重定向。此外，在日常的渗透测试和资产发现过程中，安全研究人员可以利用 Zondex 对外部暴露的服务进行扫描，确保没有内网管理接口因路由配置错误而暴露在公网环境下。

4. 采用 IPv6 迁移

由于 TunnelVision 攻击目前主要针对 IPv4 的 DHCP 选项，启用纯 IPv6 环境可以在一定程度上规避此类基于 Option 121 的攻击。然而，这也要求整个网络基础设施（包括 VPN 供应商）对 IPv6 有完善的支持和正确的路由优先级配置。

技术总结：信任模型的重新评估

TunnelVision 的发现意味着，即使拥有强加密的通信渠道，底层的网络协商过程（DHCP）如果不受信任，上层的隐私防护依然脆弱。对于高度敏感的环境，不再建议依赖操作系统的默认 DHCP 配置。通过静态 IP 分配或严格的本地防火墙路由锁定，是目前对抗此类复杂路由劫持攻击的必要手段。安全从业者在审计 VPN 部署时，必须将 DHCP 响应的安全性纳入整体风险评估模型。