Facebook 和 Yandex 被发现进行用户恶意跟踪。这让今天看起来就像一个普通的星期五，但这次却有些特别。这次是Local Mess 。好吧，这是一种名字很傻的攻击，但手段却非常高明。简而言之，网站可以打开到本地主机的连接。而在 Android 上，应用程序可以监听这些端口，从而允许网页与应用程序通信。
这听起来可能不算太糟，但有几点需要注意。首先，Android（和 iOS）应用都经过沙盒处理——这故意让应用之间难以通信，除非采用操作系统制造商批准的方式。浏览器也同样经过沙盒处理，与应用隔离开来。这是一个安全边界，尤其是在用户处于隐身模式时，这是一个非常重要的安全边界。
这里有必要解释一下追踪像素 (Pixel)。这是一段代码，它会在网站上放置一张不可见的图片，从而允许追踪器在该网站上下文中，在您的浏览器中运行 JavaScript。Facebook 以此闻名，但并非唯一一家以这种方式追踪用户的广告服务商。如果您在一个网站上搜索了某个商品，然后突然在其他网站上看到大量该商品的广告，那么您就被像素追踪了。
这在用户登录时最有用，但在移动设备上，用户更有可能登录应用程序而不是浏览器。对更多更好数据的持续需求导致了一种新颖且完全不道德的解决方案。在Android上，有权访问互联网的应用程序可以在localhost（127.0.0.1）的非特权端口（即1024以上的端口）上监听。
Facebook 滥用了这一漏洞，通过向 localhost（Facebook 应用正在监听的端口之一）发起 WebRTC 连接。这会触发与 localhost 的 SDP 连接，该连接首先发送一个 STUN 数据包（一种用于 NAT 穿越的 UDP 工具）。该 STUN 数据包中包含 Facebook Cookie 的内容，Facebook 应用会将其转发给 Facebook。浏览器在加载像素时也会将该 Cookie 发送给 Facebook，这样 Facebook 就能知道你正在访问哪个网站了。即使你没有登录或开启了隐身模式。
Yandex 自 2017 年以来一直在做类似的事情，尽管采用了一种不同的、更简单的机制。Yandex 不是直接调用 localhost，而是为此预留了yandexmetrica.com ，域名指向127.0.0.1 。这只是用来打开与原生 Yandex 应用的 HTTP 连接，原生应用会通过 HTTPS 将数据传递给 Yandex。元应用最早在 2024 年 9 月被发现使用这种技巧，尽管它很可能更早就被使用了。
自该报告发布以来，两家公司都已停止运营。有趣的是，这公然违反了《GDPR》和《CCPA》，很可能会导致创纪录的罚款，至少对 Facebook 而言是如此。
你的电话号码是多少？
在一项实验中，谷歌网站在禁用 JavaScript 的情况下仍能正常工作，这带来了一个有趣的发现：如何绕过速率限制，找到任何谷歌用户的电话号码。谷歌已经部署了防御性解决方案，以防止攻击者滥用accounts.google.com/signing/usernamerecovery等端点。该特定端点在没有 JavaScript 的情况下仍然可以工作，但仍然可以检测到多次尝试，并向任何试图暴力破解它的人抛出验证码。
这项技术旨在通过浏览器中的 JS 执行少量工作量证明计算，然后发送一个bgRequest令牌来实现。在非 JavaScript 版本的网站上，该字段被设置为js_disabled 。如果您直接获取有效令牌并将其塞入请求中，会发生什么？利润！这种意想不到的组合绕过了速率限制，意味着只需通过用户的姓氏和名字就能轻松获取电话号码。这个问题在短短一个多月内就得到了缓解，[brutecat] 也因此获得了 5000 美元的丰厚回报。
捕捉反射
有一种经典的 Active Directory 攻击，即反射攻击，可以诱骗服务器向你发送身份验证信息，然后将该身份验证数据直接发回源服务器。在 2008 年之前，这种攻击在 AD 服务器上确实有效。RedTeam Pentesting 团队利用 Kerberos 协议重新实现了这种攻击。
这并非一次简单的攻击，仅仅强制远程服务器打开与攻击控制位置的 SMB 连接就已经是一个令人印象深刻的漏洞。其中的诀窍在于，攻击者的有效主机名中包含目标名称和 base64 编码的CREDENTIAL_TARGET_INFORMATIONW字符。这会混淆远程服务器，使其看起来像是在进行自我身份验证。强制使用 Kerberos 身份验证（而不是 NTLM 身份验证）就完成了攻击者的“魔法”，尽管还有一个秘密在等着他们。
攻击开始时，攻击者拥有一个低权限的计算机帐户。攻击结束时，访问权限将达到目标计算机的系统级别。目前尚不清楚具体原因，但研究人员推测，旨在阻止此类权限提升的缓解措施是导致攻击发生的原因。
X 和果汁盒
X 推出了一款全新的端到端加密聊天解决方案 XChat。它旨在对上一代产品进行重大升级， 但并非所有人都对其印象深刻。真正的端到端加密很难大规模推广，原因之一是用户不善于管理加密密钥。通常的解决方案是让服务提供商代为存储密钥。但是，如果密钥掌握在公司手中，端到端加密的意义何在？虽然目前还没有完全解决这个问题的方案，但有一个非常巧妙的缓解方案： Juicebox 。
Juicebox 允许用户设置一个简短的 PIN 码，并用它来生成实际的加密密钥，然后将密钥拆分成多个部分，分别保存在不同的服务器上，并承诺如果 PIN 码被猜错次数过多，就会删除密钥。这就是 X 正在使用的解决方案。听起来很棒，对吧？但这个描述中有两个陷阱。首先是服务器不同：这只有在这些服务器并非由同一家公司运营的情况下才有用。其次是删除密钥的承诺。这在加密方面并没有保证。
有迹象表明，X 在其 Juicebox 系统中运行了一对硬件安全模块 (HSM)，这极大地帮助解决了这两个问题，但目前系统透明度还不够。目前，大家一致认为 Signal 仍然是最安全的平台。
位和字节
本周我们关于 Bits 的内容比较少，所以你只能勉强接受“安全启动攻击已公开”的报告了。这是 DT Research 推出的一款固件更新工具，由微软的 UEFI 密钥签名。该工具存在一个漏洞，允许攻击者突破其预期用途并运行任意代码。这个漏洞已被修补，但在微软签名的 IGEL 内核镜像中还存在另一个类似的问题，允许运行任意根文件系统 (rootfs)。对于我们普通用户来说，这并非什么大问题，但持续不断的被盗用、签名的 UEFI 启动镜像，对于安全启动作为一项安全措施的长期成功而言，并非好兆头。
原文： https://hackaday.com/2025/06/13/this-week-in-security-the-localhost-bypass-reflections-and-x/