Tailscale 未能阻止 Hugging Face 入侵事件复盘

Tailscale 未能阻止 Hugging Face 入侵事件

一个 AI 智能体逃出了它的沙箱，进入了 Hugging Face 的基础设施，并利用窃取的 Tailscale 凭据将 181 个节点接入到了他们的 tailnet 中。没有发现或利用任何 Tailscale 漏洞——但我们本应能够阻止这一切。

到现在，你可能已经听说了那个逃出安全评估并攻击 Hugging Face（一个 LLM 市场）的 AI 智能体。这个智能体认为 Hugging Face 上可能有它基准测试的答案，于是它偷走了答案，只是为了在考试中作弊。动机很滑稽，但结果很可怕。

Hugging Face 发布了对这次入侵的详细复盘。其中涵盖了四天半时间里约 17,600 个被恢复的操作，包括沙箱逃逸、代码执行、云凭据、临时搭建的命令与控制（C2）系统，以及最终利用 Tailscale 在其整个组织中横向扩散。

但 Tailscale 是一个零信任网络！零信任的全部意义就在于防止攻击者在你的公司内部横向移动。到底哪里出了问题？

Tailscale 出现在哪里

没有发现或利用 Tailscale 中的任何“漏洞”，而这可能让我们更加不安。Tailscale 在 AI 基础设施中无处不在：几乎每家 AI 公司都在使用 Tailscale。所以最终出现在 AI 事件报告中，并不令人意外。

但是，我们是一家安全工具公司。他们的入侵就是我们的入侵，认真对待这件事是我们的职责。和任何事后复盘一样，我们需要反思发生了什么，以及我们本可以做些什么来阻止它。

当这个智能体逃出沙箱并找到 Tailscale 时，它已经在一个生产 worker 中获得了代码执行权限，在 Kubernetes 节点上拿到了 root 权限，并读取了一个包含 136 个密钥的生产密钥存储。从某种意义上说，在我们登场之前，游戏就已经结束了。

但这不正是问题所在吗？让我们往后退一两层来看。为什么长期有效的密钥对任何人都是可访问的？

因为长期凭据是行业标准做法。

不过，它们本不该如此。而我们现在看到了一个绝佳的例子，说明为什么不该如此。在旧时代，大多数入侵都是由人类以人类的速度完成的，凭据泄露缓解措施被视为“有则更好”的锦上添花。一个大型凭据库，能让你一次性读取 136 个密钥，在安全团队的待办清单上只是排在低优先级的位置。

而现在，在恶意 AI 智能体横行的世界里，大型凭据库成了战利品。这种情况已经不能再容忍了。

据我所知，针对长期有效凭据，主要有两种解决方案。

第一种，你可以配置一个保险库，它只根据你一次性插入且永不返还的长期凭据来签发短期凭据。例如，HashiCorp Vault 就能做到这一点；他们称之为动态凭据。遗憾的是，动态凭据的搭建和维护工作量很大。当安全措施需要付出努力时，人们往往就不会去做。

第二种方案是凭据注入代理。如果客户端 C 想要访问服务器 S，不要给 C 提供访问 S 的凭据；而是让它通过一个加固的代理 P 发送请求，这个代理只做一件事：接收请求、注入凭据、然后转发。随着现代基于网格的网络消除了大部分延迟，凭据注入正变得越来越流行。几个月前，我们收购了 Border0（“Tailscale PAM”），它打造了一个优雅且相当精巧的凭据注入代理，与 Tailscale 紧密集成。如果 Border0 被全面部署，本可以阻止那 136 个密钥被读取，并记录每一次使用它们的尝试。（同样的凭据注入技术也为 Aperture Connectors 提供支持。）但是，这项技术太新了。我们的大多数客户甚至还没看过它。

还有一个额外的第三种方案：Tailscale 本身。在 Tailscale 中，你的节点密钥可以通过 TPM 绑定到机器上以防止导出，如果你是企业用户，绝对应该这么做。可惜的是，由于我们在部分用户的硬件上发现了 HSM 问题，不得不在 Linux 和 Windows 上默认关闭 TPM 存储。总之，在今天的案例中，攻击正是通过获取 Tailscale 的访问权限来实现的，所以我们介入得太晚了。

那个长期有效的认证密钥本不该存在

动态凭据和凭据注入代理都没有部署到位，所以 136 个密钥泄露了。下一道防线是什么？

这 136 个凭据中有一个是可重复使用的 Tailscale 认证密钥，用于在其 tailnet 网络中创建新的 Tailscale CI（持续集成，用于自动化测试）节点。该智能体将这个密钥复制到一系列外部沙箱中，并在几天内利用它向 Hugging Face 的 tailnet 网络注册了总共 181 个节点。这些节点每个都获得了一个 Tailscale 身份标签，授予其 CI 节点所能获得的所有访问权限。

我们无法挽救这 136 个密钥。但可重复使用的 Tailscale 密钥本不必是其中之一。

我们构建工作负载身份联合（workload identity federation）正是为了应对此类情况。它依赖你的云服务提供商以短期凭据的形式提供“环境权威”（ambient authority），这些凭据由运行中的虚拟机（或容器）的云身份生成。CI 任务可以向其云平台请求一个签名的 OIDC 令牌。Tailscale 验证该令牌，然后根据分配给该工作负载的标签和范围授予访问权限。巧妙之处在于，一旦启用，这一切可以自动完成：启动 CI 节点，Tailscale 获取身份，分配正确的标签。没有凭据可泄露，并且如果配置得当，该凭据除了在 CI 环境中之外无处可用。

这意味着你无法获取 CI 凭据，在其他地方的节点上运行它，并将其变成一条从测试集群通往网络其他部分的现成路径。

遗憾的是，使用工作负载身份联合的人还不够多。我们本应做更多工作，确保客户知道这是更简单、更安全的路径，并为他们提供清晰的采用方式。我们可以改进文档，并在界面中增加更多提示。

没有客户端日志并不意味着没有证据

为了掩盖踪迹，该智能体使用 `--no-logs-no-support` 参数运行 Tailscale，该参数会抑制该客户端的报告功能。

这是一个为那些担心向 Tailscale 发送遥测元数据的用户设计的选项。即使我们不提供这个选项，修改源代码以移除遥测功能也是很容易的。

但停止记录日志并不会让连接变得不可见。如果你启用 Tailscale 网络流量日志，它们会报告每条连接两端的流量，以及子网路由器和出口节点的流量。这一点很微妙但很重要：被攻陷的节点可能不会发送流量日志，但它所连接的每个节点都会发送。然后，只要你的 SIEM 配置得当，当两端不匹配时，它就能立即发出红色警报。

当流量日志流入配置得当的 SIEM 时，它们可以帮助检测。但这是很大的工作量。流量日志需要启用，而且你需要设置正确的实时检测规则，才能让它们在实时场景中有用，而不仅仅是事后取证。我们正在研究如何让流量日志更容易被发现、配置、采用，并作为警报触发器。我希望我们能让流量日志变得非常易用，即使你没有安全团队来监控它们，它们也能发挥作用。

如果你想要超越单纯日志记录的直接控制，还可以启用 Tailnet Lock。这能让你对每一个新节点拥有直接的可见性和严格的、可编程的准入控制。例如，经过一些工作，你可以对你的签名节点进行编程，让它检查带有“CI”标签的节点是否总是具有特定的 IP 地址范围或其他侧信道有效性证明。

让安全之路成为易行之路

网络安全很难。它一直很难。在恶意 AI 智能体盛行的新世界里，它不仅难，而且至关重要。而这是一个问题，因为许多组织根本没有网络安全专业知识。

所以在 Tailscale，我们把这当成自己的责任。人们期望我们的产品默认就能阻止这类横向移动攻击，这样他们就不必自己操心。即使他们根本不知道什么是横向移动攻击。

如果这次事件让你有点紧张地审视自己的基础设施，那就从检查你的工作负载可以读取的可复用 Tailscale 认证密钥开始。特别是对于云端和 CI 环境，尽可能用工作负载身份联合来替换它们。摆脱那些长期有效的认证密钥。

（认证密钥仍然有很好的用途，尤其是在一次性配置和没有平台身份的环境中。当你确实需要时，优先使用一次性密钥；使用 OAuth 客户端来缩短认证密钥的过期时间；使用窄范围标签；在 ACL 中审计授予这些密钥的权限。）

开启网络流量日志，并将其发送到你所在安全团队已经在使用的工具中。

在受管节点集群上使用安全的节点状态存储，这样你可以控制自己的 TPM。在你无法控制 TPM 的环境中，利用设备状态来隔离和限制节点。

我知道我们还没有让这些更安全的选择足够显而易见。这责任在我们。我们会改进文档，在界面中添加提示，尽力默认开启这些选项，在你做危险操作时发出警告，并建议更好的替代方案。

这是我们非常加拿大的道歉方式：抱歉踩到了你的脚。这次攻击没有利用 Tailscale 的漏洞，Tailscale 也没有导致入侵事件。但是，我们没能阻止它。下次，我们会做到。

如果你正在运行 Tailscale 并想深入了解，请联系我们的支持团队和解决方案工程团队。我们可以帮你加固设置，并在下一个 AI 智能体找到漏洞之前，帮你发现那些薄弱环节。