曝光：安卓最新窃密活动与技术【Meta/Yandex跨应用追踪用户隐私】

曝光：通过 Android 上的 Localhost 进行隐蔽的 Web 到应用跟踪

安卓本地端口监听漏洞：Meta/Yandex跨应用追踪用户隐私

Meta与Yandex利用安卓系统漏洞，通过Facebook Pixel和Yandex Metrica脚本，在用户访问网站时通过本地端口（UDP 12580-12585/TCP 29009等）将网页cookie发送至旗下应用（如Facebook、Instagram、Yandex地图），关联设备ID与账户身份。此行为绕过无痕模式、清cookie等防护，致数十亿用户浏览数据泄露。披露后（2025年6月3日），两家公司紧急停用该技术，Chrome等浏览器已封堵端口。

文章精华：

1. 手段
   
   ：网页脚本→本地端口→安卓应用（传cookie/设备ID）
2. 危害
   
   ：跨域关联身份、历史记录泄露、绕过隐私防护
3. 现状
   
   ：涉事公司已停用，主流浏览器修复漏洞。

这是如何运作的？

虽然 Meta 和 Yandex 在连接 Web 和移动上下文及标识符的方式上存在细微差别，但它们本质上都滥用了未经审查的本地主机套接字访问权限。Android 操作系统允许任何已安装且拥有 INTERNET 权限的应用在环回接口 (127.0.0.1) 上打开监听套接字。在同一设备上运行的浏览器也可以在未经用户同意或平台中介的情况下访问此接口。这使得嵌入在网页上的 JavaScript 能够与原生 Android 应用通信，并 共享标识符和浏览习惯，从而使用标准 Web API 将临时 Web 标识符与长期有效的移动应用 ID 连接起来。

Meta/Facebook Pixel 从网络向 Meta Android 应用共享 _fbp cookie

Meta (Facebook) Pixel JavaScript 在 Android 移动网络浏览器中加载时，会使用 WebRTC 将第一方_fbp cookie 传输到 UDP 端口 12580-12585，并发送给设备上任何监听这些端口的应用。我们发现，Meta 旗下的 Android 应用 Facebook（包括 515.0.0.23.90 版本）和 Instagram（包括 382.0.0.43.84 版本）在 Google Play 商店中提供，它们正在监听这些端口范围。

Meta Pixel 使用一种称为 SDP Munging的技术，将_fbp cookie 内容插入到 SDP 的“ice-ufrag”字段中，从而向环回地址发送绑定请求 STUN 消息，如下图所示。使用 Chrome 的常规调试工具（例如 DevTools）无法观察到此数据流。

_fbp cookie从web到native再到服务端的整个流程如下：

1. 用户打开原生的 Facebook 或 Instagram 应用，该应用最终会被发送到后台，并创建一个后台服务来监听 TCP 端口（12387 或 12388）和 UDP 端口（12580-12585 中第一个未占用的端口）上的传入流量。用户必须使用其凭证登录应用。
2. 用户打开浏览器并访问集成 Meta Pixel 的网站。
3. 在此阶段，网站可能会根据网站和访问者的位置征求同意。
4. Meta Pixel 脚本通过 WebRTC (STUN) SDP Munging 将_fbp cookie发送 到原生 Instagram 或 Facebook 应用程序。
5. Meta Pixel 脚本还将 _fbp 值连同其他参数（如页面 URL（dl）、网站和浏览器元数据以及 事件类型（ev）（例如，PageView、AddToCart、Donate、Purchase））一起发送到 https://www.facebook.com/tr。
6. Facebook 或 Instagram 应用程序从浏览器上运行的 Meta Pixel JavaScript 接收 _fbp cookie。这些应用程序将 _fbp 作为 GraphQL 变更传输到 (https://graph[.]facebook[.]com/graphql)，以及其他持久用户标识符，从而将用户的 fbp ID（网页访问）与其 Facebook 或 Instagram 帐户关联起来。

大约在 5 月 17 日，Meta Pixel 在其脚本中添加了一种新方法，该方法使用WebRTC TURN而非 STUN 发送 _fbp cookie。新的 TURN 方法避免了 SDP Munging（在我们披露漏洞后，Chrome 开发者已公开宣布禁用该功能）。截至 2025 年 6 月 2 日，我们尚未观察到 Facebook 或 Instagram 应用程序主动监听这些新端口。

关于 _fbp cookie

根据 Meta 的 Cookie 政策， _fbp Cookie用于识别浏览器，以提供广告和网站分析服务，有效期为 90 天。 根据 Web Almanac 2024 的数据，在全球前一百万个网站中，约有 25% 的网站使用了该 Cookie，使其成为网络上第三大最常见的第一方 Cookie。

第一方 Cookie 意味着它无法用于跨网站追踪用户，因为它是在网站域名下设置的。这意味着同一个用户在不同网站上拥有不同的 _fbp Cookie。然而，我们披露的方法允许将不同的 _fbp Cookie 关联到同一个用户，这绕过了现有的保护措施，违背了用户的预期。

Yandex 自 2017 年起使用本地主机通信

Yandex Metrica 脚本通过特定的 TCP 端口 29009、29010、30102 和 30103 向本地主机发起包含长且不透明参数的 HTTP 请求。我们的调查显示，Yandex 旗下的应用程序（例如 Yandex 地图、Yandex Navigator、Yandex 搜索和 Yandex 浏览器）会主动监听这些端口。此外，我们的分析表明，域名 yandexmetrica[.]com 解析到环回地址 127.0.0.1，并且 Yandex Metrica 脚本通过 HTTPS 协议将数据传输到本地端口 29010 和 30103。这种设计混淆了数据泄露过程，从而使传统的检测机制更加复杂。

Yandex 应用会联系 Yandex 域名（startup[.]mobile[.]yandex[.]net 或类似域名）来检索要监听的端口列表。该端点返回一个 JSON 格式的数据，其中包含本地端口（例如 30102、29009）以及一个“first_delay_seconds”参数，我们认为该参数用于延迟服务的启动。在我们的一台测试设备上，first_delay_seconds 大致相当于 Yandex 应用开始监听本地端口所需的秒数（约 3 天）。

在收到来自 Yandex Metrica 脚本的本地主机 HTTP 请求后，移动应用会以 Base64 编码的二进制有效负载进行响应，该负载嵌入并桥接Android 广告 ID (AAID)以及其他可通过 Java API 访问的标识符，例如 Google 的广告 ID 和 UUID，这些标识符可能特定于 Yandex。与 Meta 的 Pixel 案例不同，所有这些信息都是由运行在网络浏览器上的 JavaScript 代码（而非原生应用）汇总并上传到 Yandex Metrica 服务器（例如 mc[.]yango[.]com）。在 Yandex 的案例中，原生应用充当代理，收集原生 Android 特定标识符，并通过本地主机套接字将其传输到浏览器上下文。

Yandex从网页到原生再到服务器的整个通信流程如下：

1. 用户打开一个原生 Yandex 应用程序，该应用程序最终被发送到后台并创建一个后台服务来监听两个 HTTP 端口（29009 和 30102）和两个 HTTPS 端口（29010 和 30103）上的传入流量。
2. 用户打开浏览器并访问集成 Yandex Metrica 脚本的网站。
3. Yandex 脚本向其服务器发送请求以获取混淆的参数。
4. 这些混淆的参数通过 HTTP 和 HTTPS 发送到本地主机。这种情况发生在直接包含 IP 地址 127.0.0.1 的 URL 上，或者解析为 yandexmetrica[.]com 域名的 URL 上。
5. 应用程序中的 Yandex Metrica SDK 接收这些参数，并使用包含加密设备 ID 的 200 OK 响应来响应网站上的 Yandex Metrica 脚本。
6. 网站上的 Yandex Metrica 脚本接收这些 ID，并将它们与混淆的参数一起发送到他们的服务器。

下表列出了我们发现的在本地主机端口监听的 Yandex 旗下应用。对于每个应用，我们还列出了其唯一的软件包名称以及用于测试的版本。

额外风险：浏览历史记录泄露

使用 HTTP 请求进行 Web 到原生 ID 共享（即非 WebRTC STUN 或 TURN）可能会将用户浏览历史记录暴露给第三方。如果恶意第三方 Android 应用程序也监听上述端口，则可以通过监控 Origin HTTP 标头来拦截 Yandex Metrica 脚本以及第一个（目前尚未使用的）Meta 通信通道实现发送的 HTTP 请求。

我们开发了一个概念验证应用程序，以证明恶意第三方应用程序收集浏览历史记录的可行性。我们发现，Chrome、Firefox 和 Edge 等浏览器在默认和隐私浏览模式下都容易受到这种浏览历史记录泄露的影响。Brave 浏览器由于其黑名单和对本地主机请求的阻止而未受此问题影响；而 DuckDuckGo 则仅受到轻微影响，因为其黑名单中缺少域名。

虽然其他应用程序有可能监听这些端口，但我们没有观察到任何其他不属于 Meta 或 Yandex 的应用程序监听这些端口。

由于 Yandex 使用 HTTP 请求进行本地主机通信，任何监听所需端口的应用都可以使用这些跟踪功能监控用户访问的网站，如上方视频所示。我们首先打开我们的概念验证应用，它会监听 Yandex 使用的端口，并将其发送到后台。接下来，我们使用不同的浏览器访问五个网站。之后，我们可以在应用中看到这五个网站的 URL 列表。

受影响的站点

根据追踪网络技术采用情况的网站 BuiltWith 的数据，Meta Pixel嵌入在超过 580 万个网站上。而 Yandex Metrica 则出现在近 300 万个网站上。根据 HTTP Archive（一个每月抓取约 1600 万个网站的开放公共数据集）的数据，Meta Pixel 和 Yandex Metrica 分别出现在 240 万个和 575,448 个网站上。

排名前 10 万的首页抓取：我们从位于法兰克福和纽约的服务器对排名前 10 万的网站（基于CrUX 排名）进行了两次网页抓取，以衡量本地主机套接字在各个网站上的使用范围。下表显示了每种情况下受影响的网站数量。每个地区的第一列显示了在接受所有 Cookie 同意表单的情况下嵌入这些跟踪器的网站数量。第二列（标记为“未同意”）报告了在用户将本地主机通信加载到浏览器后立即主动尝试执行本地主机通信的网站数量，即可能未经用户同意。

带有 Meta Pixel 的网站

Facebook/Meta 像素脚本尝试使用 WebRTC 与其 Android 应用共享 _fbp ID 的网站。该表显示了该网站的 URL 和 CrUX 排名，以及它们是否在欧盟或美国抓取中被发现。

URL：受影响网站的 URL。排名：由 CrUX 排名确定的排名箱（1000、5000、10000、50000 或 100000）欧盟和美国：

• 是：在此区域观察到 ID 共享。
• 否：此区域未观察到 ID 共享。
• ⚠️：在获得任何同意或网站没有同意书之前共享_fbp ID。

使用 Yandex Metrica 的网站

Yandex 脚本向 localhost 端口发送 HTTP 请求的网站。该表显示了网站的 URL 和 CrUX 排名，以及我们是否在欧盟或美国抓取中观察到了对 localhost 的请求。

URL：受影响网站的 URL。排名：CrUX 排名 bin；表示受欢迎程度（前 1000、5000、10000、50000 或 100000）欧盟和美国：

• 是：在此区域观察到 ID 共享。
• 否：此区域未观察到 ID 共享。
• ⚠️：在获得任何同意之前或网站没有同意书的情况下共享 ID。

我们想指出的是，本次抓取活动并非详尽无遗，也并非完整无缺。其目的是评估这些行为在代表性网站样本中的普遍性。 因此，某个网站未出现在此列表中并不一定意味着该网站未集成这些跟踪功能。

爬取方法： 访问网站时，我们的爬虫程序会等待页面加载，然后接受网站上的所有 Cookie（如有）。之后，它会再等待十秒，同时收集访问期间发出的所有 HTTP 请求、WebSocket 帧和 WebRTC 函数调用。通过分析这些数据，我们发现 Meta 的像素在 15,677 个从欧盟访问的网站和 17,223 个从美国访问的网站中发送到本地主机。在 1,260 个从欧盟访问的网站和 1,312 个从美国访问的网站中分别发现了 Yandex metrica。

为了评估这些追踪行为是否在未经潜在用户同意的情况下发生，我们进行了第二次抓取活动，但未与 Cookie 同意窗口（如果向用户显示任何窗口）进行交互。即使没有主动同意这些网站（即不接受任何 Cookie 或没有同意窗口），Meta Pixel 仍会在未经用户同意的情况下，分别向 11,890 个和 13,468 个从欧盟和美国访问的网站上的 localhost 发送 fbp cookie。对于 Yandex，它分别在未经用户同意的情况下，向 1,064 个和 1,095 个来自欧盟和美国的网站上触发了 localhost 请求。

这是什么时候开始的？

下表显示了 Yandex 和 Meta 使用的方法随时间的变化，列出了根据历史 HTTP 存档数据首次观察到每种方法的日期。

• *：Meta Pixel 脚本最后一次通过 HTTP 发送是在 2024 年 10 月，但 Facebook 和 Instagram 应用至今仍在监听此端口。它们也监听 12388 端口的 HTTP 请求，但我们尚未发现任何向 12388 端口发送的脚本。
• **：Meta Pixel 脚本会向这些端口发送数据，但 Meta 应用尚未监听这些端口（目前为止？）。我们推测，这种情况可能是由于应用部署缓慢/渐进造成的。

被动受害媒介

这种新颖的追踪方法利用了 Android 平台（包括大多数 Android 浏览器）上对本地主机套接字的无限制访问。正如我们所展示的，这些追踪器在用户不知情的情况下执行了这种操作，因为当前的隐私控制措施（例如，沙盒方法、移动平台和浏览器权限、Web 同意模型、隐身模式、重置移动广告 ID或清除 Cookie）不足以控制和缓解这种威胁。

我们注意到，本地主机通信可能用于合法用途，例如 Web 开发。然而，研究社区担心 本地主机套接字可能会成为数据泄露和持久跟踪的潜在载体。据我们所知，在我们披露之前，尚未发现任何证据表明该漏洞在现实世界中被滥用于跨平台的持久用户跟踪。

披露

我们负责任地向主要的 Android 浏览器供应商披露了问题，并已发布了多个补丁程序试图缓解此问题；其中一些已经部署，其他一些仍在开发中。我们感谢所有参与的供应商（Chrome、Mozilla、DuckDuckGo 和 Brave）在整个过程中的积极配合和建设性参与。其他基于 Chromium 的浏览器也应关注上游代码变更，并针对自身产品进行补丁。

然而，除了这些短期修复措施之外，要彻底解决这个问题还需要采取更广泛的措施，因为这些措施并未涵盖平台沙盒方法和策略的根本限制。这些措施包括：面向用户的控制措施，用于提醒用户注意本地主机访问；更强大的平台策略，并伴随一致且严格的执行措施，以主动防止滥用；以及增强 Android 进程间通信 (IPC) 机制（尤其是依赖本地主机连接的机制）的安全性。

该表显示了我们的浏览器测试的概述。

1. SDP 混合 ICE 凭证已被阻止，但与 TURN 端口的 UDP 通信尚未被阻止（将在 v138 中被阻止）。我们测试的 Meta 应用在发布时尚未监听 TURN 端口，但 Meta Pixel 脚本已向 TURN 端口发送消息。
2. DuckDuckGo 的黑名单中缺失了三个 Yandex 域名，但这些域名出现在极少数网站上（每 10 万个中只有 31 个）。DuckDuckGo 迅速修改了黑名单，弥补了这一盲点。
3. 基于黑名单的保护。
4. 阻止本地主机对“127.0.0.1”和“localhost”的请求。

网站所有者是否意识到了这一点？

我们没有找到任何 Meta 的公开文档或 Yandex 的官方文档来描述此方法及其用途。对于 Meta Pixel，我们在 Facebook 开发者论坛上发现了一些疑惑不解的网站所有者的投诉，他们质疑 Meta Pixel 为何在 2024 年 9 月之前会与 localhost 进行通信：

• Facebook SDK 配置文件调用本地主机
• 为什么我的 Pixel Javascript 在 Android 上的嵌入式 Web 视图中访问 http://localhost

这些投诉来自世界各地。Meta 官方代表并未对这些帖子做出任何回应。一位开发者在 2024 年 9 月表示： Meta 对此完全没有回应。我向他们提出的支持请求只得到了一个笼统的回复，之后就被忽略了。很遗憾，Meta 竟然没有追究责任，我们依赖这些工具才能正常工作，我们无法控制它们，所以至少应该得到一个解释，说明到底出了什么问题。

最终用户知道吗？

浏览互联网并访问集成 Yandex 和 Meta ID 桥接功能的网站的用户可能并未完全意识到这种行为。事实上，即使用户出现以下情况，这种新颖的追踪方法仍然有效：

1. 未在移动浏览器上登录 Facebook、Instagram 或 Yandex
2. 使用隐身模式
3. 清除他们的 cookies 或其他浏览数据

这种跟踪方法破坏了 Android 基于分区、沙盒或清除客户端状态的进程间隔离和跟踪保护。

初步结果表明，这些做法可能在未设置明确且适当的 Cookie 同意表单的网站上实施。如果网站在用户同意使用相应 Cookie 之前加载 Facebook 或 Yandex 脚本，则仍会触发此行为。

☝️ 问答

问：为什么 Facebook 在你们公开发布消息的当天就停止使用这种技术了？

答：我们不知道 ¯_(ツ)_/¯，但我们很高兴看到，在我们披露之后（目前），Android 用户不再受到此类滥用的影响。

问：这项研究经过同行评审吗？

答：我们的研究结果已得到我们披露的某些机构的确认，但该研究尚未经过同行评审。鉴于该研究的严重性，我们决定不推迟到出版周期才进行公开披露。

问：Meta 或 Yandex 是否在其文档中披露了这种方法？

答：我们没有找到 Meta 或 Yandex 公开的技术文档来描述这种基于 localhost 的通信技术。在 Facebook 的开发者论坛上，有人 提出了Pixel 脚本连接 localhost 的担忧，但没有得到任何解释。

问：这只影响 Android 用户吗？iOS 或其他平台的用户会受影响吗？

答：我们仅获得了这种 Web 到原生 ID 桥接的 Meta 和 Yandex Web 脚本的经验证据，这些脚本专门针对 Android 移动用户。在我们测试的 iOS 浏览器和应用中，尚未发现任何滥用的证据。即便如此，iOS 浏览器和原生应用之间类似的数据共享在技术上是可行的。所有基于 WebKit 的 iOS 浏览器都 允许开发者以编程方式建立本地主机连接，应用也可以监听本地端口。在后台运行原生应用的技术和政策限制，或许可以解释为什么 iOS 用户没有成为这些追踪器的目标。然而，我们注意到，我们对 iOS 的分析仍处于初步阶段，这种行为可能也违反了 PlayStore 的政策。除了移动平台之外，Web 到原生 ID 桥接也可能对桌面操作系统和智能电视平台 构成威胁，但我们尚未对这些平台进行调查。

原文始发于微信公众号（OSINT研习社）：曝光：安卓最新窃密活动与技术【Meta/Yandex跨应用追踪用户隐私】