WebRTC IP 泄漏：您还应该担心吗？

了解 WebRTC IP 泄漏的历史：一个新的 JavaScript 库如何无意中引入隐私问题、它是如何被利用的，以及这个问题得到了多大程度的解决。

在进入本文的精彩部分之前，您需要了解为什么 WebRTC 需要您的 IP 地址，以及这在技术上不是漏洞，而是 WebRTC 的一项功能。

我们将探索：

• 演示如何利用 WebRTC 的攻击向量
• 泄露的 IP 地址对隐私的影响
• 如何保护自己，甚至是否需要

为什么 WebRTC 需要我的 IP 地址？

IP（互联网协议）地址有助于在网络中路由数据。每个设备都分配有一个唯一的 IP 地址，可用于识别它。IP 地址可以是本地地址也可以是公共地址，本地地址用于与同一 LAN（局域网）上的本地设备通信，而公共地址用于通过 Internet 与设备通信。

WebRTC 的工作原理以及它如何确定连接两个或多个设备的最佳路由是相当复杂的。出于本文的目的，我们假设建立连接是在对等点之间交换连接信息（IP 地址）。此连接信息称为ICE（交互式连接建立）候选者，这是 WebRTC 中使用的NAT（网络地址转换）遍历的标准方法，它显示了对等方可以通过（直接或通过TURN服务器）进行通信的可用方法。

WebRTC 客户端尝试协商三种类型的地址：

• 本地 IP 地址
• 通过 STUN 服务器找到的公共 IP 地址
• 通过 TURN 服务器找到的公共 IP 地址。

对于建立最佳连接的对等点，需要此信息。例如，如果两台设备连接到同一本地网络，则它们需要访问彼此的本地 IP 地址。如果他们不在同一个网络上，他们将需要一个可访问的公共 IP。

随着现代浏览器的出现以及对访问设备网络摄像头和麦克风等资源的需求不断增长，需要一个易于使用的 API。这就是 WebRTC 的用武之地，这是一个内置于现代浏览器中并默认启用的 JavaScript 库。

它为开发人员提供了一个方便的 API 进行交互，并使在多个对等点之间创建媒体连接变得容易。这种易用性的一部分需要一种方法来检索本地设备的 ICE 候选者，因为该信息必须与任何其他对等方共享以创建连接。因此，WebRTC 提供了一种访问 ICE 候选人的便捷方式，并间接提供了一种访问设备本地和公共 IP 地址的简便方法。

NAT：私有和公共 IP 地址

IPv4 于 1983 年推出，其 32 位格式仅允许约 43 亿个唯一地址。今天，我们连接到 Internet 的唯一设备的数量超过了这个数量，这意味着每台设备都不能拥有唯一的公共 IP 地址。

NAT是防火墙和路由器采用的一种方法，将多个本地私有IPv4地址映射到一个公有IPv4地址，然后再传递信息，从而保存合法注册的公有IPv4地址。

这意味着当您将手机或笔记本电脑连接到 Internet 时，您不会获得唯一的公共 IPv4 地址；相反，您使用的是路由器的公共地址或您的 ISP（互联网服务提供商）。

IPv4 的后继者是 IPv6，随着 IPv6 的引入，将不再需要 NAT（出于其初衷），因为每台设备都可以拥有唯一的 IP 地址。

由于 IPv6 较新且未被完全采用，本文将讨论在 IPv4 上下文中实现 IP 泄漏，泄漏公共或私有 IPv4 地址有多大问题，以及如果同时泄漏这两个地址意味着什么。

通过 WebRTC JavaScript 访问 IP 信息

可以很容易地从 ICE 候选人中提取本地 IP 地址：

const pc = new RTCPeerConnection();
pc.onicecandidate = e => {
    if (e.candidate) {
        console.log(e.candidate.candidate.split(" ")[4]);
    }
}
pc.createOffer({offerToReceiveAudio: true})
    .then(offer => pc.setLocalDescription(offer));

需要注意的是，上面的代码可以在任何网站上执行，只要没有在浏览器中手动禁用 WebRTC（默认启用），它就会起作用。更重要的是，上面的代码没有任何提示；这可以执行并且对用户不可见。

但是，如果你在 2022 年运行上面的命令，你可能会注意到它实际上并没有打印出你的本地 IP 地址。相反，它看起来像这样：

e6d4675b-0c93-43d1-b4be-f8ae4d050721.local

这是一个mDNS地址，解决了通过WebRTC泄露本地IP地址的问题。

什么是 mDNS（Multicast DNS）

域名系统 (DNS)用于将域名（例如https://google.com ）解析为 IP 地址。同样，mDNS协议将主机名解析为不包含本地名称服务器的小型网络中的 IP 地址。

但是，它的工作方式略有不同，因为没有注册表来检查主机名和 IP 地址之间的匹配。不是查询名称服务器，而是直接寻址网络中的所有参与者。当客户端想知道具有给定名称（例如gordon.local）的设备在本地网络中的 IP 地址时，它会向网络发送Multicast DNS并询问哪个网络参与者与主机名匹配。本地网络中的所有设备都会收到请求，然后具有正确名称的设备可以通过多播返回其 IP 地址。

本地网络上的所有设备都会收到响应，现在可以缓存该信息以供将来使用。

WebRTC 如何使用 mDNS

如前所述，WebRTC 尝试以最佳方式连接对等点。为了最大化直接点对点连接的可能性，客户端私有 IP 地址包含在 ICE 候选集合中，例如，当两个设备位于同一本地网络并需要连接时。

但是，将本地 IP 地址暴露给在浏览器中运行的任何恶意 JavaScript 可能会对隐私产生影响——而且，正如我们稍后将看到的，也可以用于更高级的攻击。

这就是 WebRTC 现在使用 mDNS 的原因。本地 IP 地址隐藏在动态生成的 mDNS 名称中。这是自动为您处理的——如果 WebRTC 需要共享一个它认为私有的本地 IP 地址，它将使用 mDNS 地址代替。如果没有 mDNS 地址，它将生成一个随机地址并注册到本地网络。

该随机地址将在所有 SDP 和 ICE 消息否定中用作本地 IP 地址的替代。这确保本地 IP 地址不会暴露给 JavaScript，此外，本地 IP 地址不会暴露给信令或其他服务器。

滥用 WebRTC 库

著名的是，早在 2015 年，纽约时报网站就使用了 WebRTC，但没有任何合法用途。文章出来批评该网站收集 IP 地址。据推测，这是为了点击欺诈跟踪和机器人识别。这只是无数其他例子中的一个。

通过Chrome Platform Status查看来自 Chrome 的 Google 匿名使用统计数据，可以得出有趣的观察结果。

查看 WebRTC 初始化的页面加载百分比，这个数字相当大~6-8%：

此图RTCPeerConnection显示了Chrome 页面加载时调用的百分比。

这仅显示正在初始化且未使用的 WebRTC。这可能有合理的原因，也可能是所有页面加载的 6-8% 是视频通话，或者只是不必要地使用 API 的错误代码。

作者认为有趣的是，Covid 似乎并未显着影响需要 WebRTC 连接的页面加载数量。如果有的话，自 Covid 开始以来它一直在稳步下降。

更有趣的数据是查看对 的调用setLocalDescription，我们之前看到它可用于访问设备的本地 IP（对于使用 mDNS 的最新浏览器来说不是那么重要）。

该图遵循与我们之前看到的相似的模式。但是，使用率接近 ~2-4%。为什么与构造函数的用法相比会有如此大的差异？这还不清楚，也许这只是错误的代码。

不过，为了完成这幅图，我们还需要看一下对 的调用setRemoteDescription，因为 WebRTC 需要它来建立对等连接，并且可以被视为“合法”使用。

这张图是迄今为止最有趣的。这与我们之前看到的情况有显着差异，与其他调用相比，使用率只是一小部分，大约占所有页面加载的 0.01-0.04%。有趣的是，在这里我们可以看到它与我们对 Covid 大流行的预期非常相似，随着人们返回办公室或学校，视频通话数量增加，然后稳步减少。

本文并不试图根据这些数据做出任何假设。它只是出于好奇而分享，并注意到很大一部分RTCPeerConnection调用可能用于 WebRTC 设计目的以外的目的。

真实世界的攻击向量

一种名为NAT Slipstreaming并由 Samy Kamkar 发现的有趣攻击允许攻击者远程访问绑定到受害者 NAT 后面任何系统的任何 TCP/UDP 服务，只需访问一个网站即可绕过受害者的 NAT/防火墙。

本文不会详细介绍攻击的原理。然而，这种攻击是一个很好的例子，可以说明暴露 IP 地址的一些危险。此攻击的 PoC 依赖于 WebRTC 来检索受害者的本地 IP 地址。如果无法通过 WebRTC 检索私有地址，则采用其他技术。该攻击还利用 WebRTC 和 TURN 协议的其他行为使其能够在其他情况下工作。

隐私问题：隐藏您的身份

您可能已经看到所有 VPN（虚拟专用网络）广告都在鼓励您“保持安全”并隐藏您的身份。一般的想法是您不想在浏览互联网时共享您的公共 IP 地址。您可能想要使用 VPN 的原因有很多：

• 访问只能通过 VPN 访问的公司内部资源
• 隐藏来自您的 ISP 的流量
• 避免基于您的 IP 的个性化广告和 Google 搜索结果
• 添加安全/加密
• 欺骗网站以为您来自不同地区（例如，访问区域锁定的 Netflix 内容）

但这引出了一个问题，泄露你的公共 IP 真的那么糟糕吗？VPN 真的提供额外的安全性吗？

答案是：这取决于。在大多数情况下，使用 VPN 会掩盖来自 ISP 的流量，并为您提供不同的 IP 地址。但是，现在您只需更改具有控制权的实体。如果您信任您所连接的 VPN 而不是您的 ISP，那么这可能是一笔不错的交易。但是，ISP 和 VPN 需要遵守当地法律和司法管辖区。它需要研究来确定信任谁，并将取决于您居住的地方和您使用的服务。

一些要点：

• 您的公共 IP（很可能）被许多人共享。可能是您的家庭路由器直接连接到 Internet 并且可以通过公共 IP 地址访问，但您很可能在 ISP 层位于额外的 NAT 后面。
• 您可能有一个滚动 IP 地址，这意味着它会经常更改。
• 扫描整个 IPv4 子集不会花费攻击者很长时间，如果他们想扫描整个范围内的路由器安全问题，他们可以，并且无论如何都可以发现您的 IP。
• 与您连接的 IP 相比，您更有可能通过社交媒体泄露敏感信息。

总而言之，隐藏您的 IP 地址仍然有正当理由。

VPN 可以保护您免受 WebRTC IP 泄漏吗？

这个问题的答案也是：视情况而定。这里要看实际的VPN和你有没有安装浏览器扩展。您应该研究您的 VPN 提供商，以确定他们是否使用技术来从 WebRTC 中隐藏您的“真实”IP 地址，并测试它是否有效。

本文讨论 WebRTC 如何在使用 VPN 时泄露您的 IP。该文章还提到了您可以执行的测试，以查看您的 VPN 是否正确隐藏了您的 IP。

如何保护自己

或者更大的问题：你需要隐藏你的公共 IP 吗？

这最终由您决定更信任谁：VPN、ISP 或替代解决方案，例如TOR。

有几件事需要考虑：

• 您的 VPN 可能不会掩盖您的真实 IP，并可能通过 WebRTC 或其他方式泄露它。
• 您的 VPN 可能会像您的 ISP 一样记录您的流量并将其出售给广告商。
• 需要考虑您所在国家/地区的法律。
• 可以在所有浏览器上禁用 WebRTC（在 Chrome 上不容易做到，需要安装扩展）。
• 可以说，掩盖在线身份的最安全方法是使用 TOR（使用禁用 WebRTC 的 TOR 浏览器）。这暴露了其他需要考虑的风险。

确保研究、了解风险和权衡，并进行一些测试以确保您选择的解决方案按预期工作并满足您的互联网隐私需求。

作者：Gordon H.