对TunnelCrack漏洞披露的回应

针对 “TunnelCrack” 漏洞披露的回应

2023年8月9日 隐私 应用程序

Mullvad 在很大程度上不受TunnelCrack VPN 漏洞的影响。以下是我们对最近披露的一系列针对 VPN 的攻击向量的回应。

LocalNet 攻击

简而言之：在 Windows、Linux、macOS 和 Android 系统上，我们不容易受到 LocalNet 攻击的影响。我们从不向 VPN 隧道之外的公共 IP 漏泄流量。然而，在 iOS 上，我们确实受到这一攻击向量的影响。

在 Windows、Linux、macOS 和 Android 系统上，我们的 本地网络共享 设置默认是关闭的。这意味着，默认情况下，所有隧道外的流量都会被阻止。当 本地网络共享 设置被启用时，我们的应用不会让流量任意通过 DHCP 服务器广告的或在路由表中设置为本地网络的所有网络。我们只允许流量通过已知的标准本地网络范围。这些 IP 地址只能存在于本地网络上，且不是有效的公共 IP。如果你想了解更详细的信息，可查看 [这里的列表，这是我们应用源代码中允许的本地 IP 网络范围。]

桌面端

这意味着如果有恶意的 AP 向受害者设备虚假广告一些公共 IP 范围作为本地网络范围，我们的应用会阻止流量向这些 IP 的发送。这些流量不会进出隧道，而是会被完全阻止离开设备。

即使在桌面端的 LocalNet 并不是流量泄露，仍然可以将其归类为拒绝服务攻击。攻击者可以阻止受害者与某些 IP 范围的通信。TunnelCrack 文献在第 412 节中概述了这一点。文中声称这可能构成安全风险，因为它可能会阻碍安全摄像头和软件安全更新。

我们在 Mullvad 一直对此保持警惕，但未将其视为 VPN 应用需要修复的实际或重要攻击向量。如果攻击者控制了路由器或 AP，他们能够以某种方式阻止受害者设备的任何流量。因此，我们不认为能够针对某些 IP 范围的选择性封堵有任何实质性变化。任何配置为连接到未经认证唯一能被这样伪造的类型WiFi 接入点的设备都有遭受拒绝服务攻击的风险。

安卓

在安卓设备连接 VPN 时，VPN 应用决定哪些 IP 网络可以在隧道内外传输。这些 VPN 应用的规则会优先于本地路由表。这意味着，在安卓设备上，即使启用本地网络共享，并且恶意 AP 虚假广告公共 IP 网络作为本地网络，所有流量仍会被发送到隧道内。

我们不认同 TunnelCrack 文献中的结论，认为 Mullvad VPN 安卓应用是带有黑色勾选标记的“默认安全的本地访问设置”。我们认为我们的应用应该有一个绿色勾选标记。我们没有找到触发流量泄漏或被阻挡的方式。

iOS

在 iOS 上，我们遗憾地未提供任何 本地网络共享 设置，目前版本的应用始终允许本地网络。这在我们应用源代码的 功能表中 有说明。然而，我们承认，我们可以让这一说明做得更明显一些，以便用户更容易发现。我们确实需要改善这方面。

这意味着设备将始终将任何网络流量发送到隧道外的本地网络，包括恶意 AP 广告的公共 IP。

我们所知的防止在 iOS 上泄露的唯一解决方案是启用一个名为 includeAllNetworks 的标志，属于 iOS VPN 术语。我们早已意识到这个标志，并一直想要启用它。问题在于我们和其他大多数在 iOS 上使用的 WireGuard 应用所用的底层隧道实现 wireguardgo，根本不兼容 includeAllNetworks。我们目前正在更换 wireguardgo，以便启用这个安全特性。实际上，我们已经在这一方面工作了相当一段时间，但这项工作规模庞大，目前仍在进行中。

ServerIP 攻击

简而言之：Mullvad 的应用在任何平台上都不易受到 Server IP 攻击向量的影响。

诱使 VPN 客户端使用错误的服务器 IP

这一部分的攻击是关于诱使 VPN 客户端使用攻击者控制的 IP 作为 VPN 服务器 IP。

Mullvad VPN 应用在获取 VPN 服务器 IP 时不使用 DNS。我们的应用通过自己的 API 获取 VPN 服务器 IP 列表。我们同样不使用 DNS 查找 API 服务器的 IP。所有 API 通信均使用 HTTPS (TLS 13) 加密，并采用证书钉扎。这意味着应用无法被诱导去与错误服务器进行通信或信任错误服务器的信息。这对于所有平台都是如此。

将流量发送到 VPN 服务器 IP 以外的隧道

这一部分的攻击涉及泄露流量到 VPN 服务器的 IP 地址，而不通过 VPN 隧道。这种攻击在许多 VPN 客户端中是可能的，因为它们通常会在 VPN 隧道之外路由并允许所有流量到 VPN 服务器 IP。

我们的客户端从未允许所有流量到 VPN 服务器 IP。我们的防火墙规则从一开始就设计为只允许通过 VPN 隧道发送到 VPN 服务器 IP、端口和协议的组合，而不是任何其他端口或协议。

在 2020 年的安全审计中，Cure53 在我们的应用中发现了一个与 TunnelCrack 描述的 ServerIP 攻击非常相似的漏洞命名为 MUL02002 WP2。然而，这是该攻击的特殊情况。这种攻击在防火墙仅允许特定端口和协议流量时也可能发生。我们对此进行了修复，以使我们的防火墙规则更加严格。我们的应用现在只允许来自 Linux 和 macOS 的 root 用户以及 Windows 上的 mullvaddaemonexe 进程的流量，以发往 VPN 服务器的 IP端口协议。这有效地阻止了 ServerIP 攻击和 Cure53 发现的攻击，自应用版本 20205 起已一直如此。

两个移动平台都不受 ServerIP 攻击向量的影响。这是因为它们不使用路由表来排除 VPN 隧道内的 VPN 流量。相反，它们提供更加细致的机制，以允许 VPN 应用排除被回送到 VPN 自身的加密流量。