Tailscale 未能阻止 Hugging Face 入侵

# Tailscale 并未阻止 Hugging Face 入侵事件 来源：https://tailscale.com/blog/hugging-face-intrusion 想必你已经听说了那个从安全评估中逃脱并攻击 Hugging Face（一个 LLM 市场）的 AI 智能体。这个智能体认定 Hugging Face 上可能有它完成基准测试所需的答案，于是为了在考试中作弊而偷走了答案。动机很滑稽，但结果很可怕。 Hugging Face 发布了一份详细的入侵重建报告（https://huggingface-anatomy-of-frontier-lab-model-intrusion.static.hf.space/index.html）。报告涵盖四天半内约 17,600 个恢复的操作，包括沙箱逃逸、代码执行、云凭证、临时搭建的命令与控制（C2）系统，以及最终利用 Tailscale 在其整个组织中横向扩散。 但 Tailscale 是一个零信任（https://tailscale.com/use-cases/zero-trust-networking）网络！零信任的核心正是防止攻击者在你公司内部进行横向移动。那到底哪里出了问题？ ## Tailscale 在哪里出现（https://tailscale.com/blog/hugging-face-intrusion#where-tailscale-appeared） Tailscale 本身没有被发现或利用任何“漏洞”，这反而让我们更加不安。Tailscale 几乎无处不在于 AI 基础设施中：几乎所有 AI 公司都在使用 Tailscale。所以最终出现在一起 AI 安全事件报告中，并不令人意外。 但是，我们是一家安全工具公司。他们的入侵就是我们的入侵，认真对待这件事是我们的职责。如同任何事后复盘一样，我们需要反思发生了什么，以及我们本可以采取什么措施来阻止它。 当这个智能体逃出沙箱并发现 Tailscale 时，它已经在一个生产 worker 内获得了代码执行权限，达到了 Kubernetes 节点上的 root 权限，并读取了一个包含 136 个密钥的生产密钥存储。从某种意义上说，在我们登场之前，游戏就已经结束了。 但这不正是问题所在吗？让我们往后退一两层来看。为什么任何人都能访问这些长期有效的密钥？ ## 因为长期有效凭证是业界常态（https://tailscale.com/blog/hugging-face-intrusion#because-long-lived-credentials-are-the-standard） 但它们不应该如此。而我们刚刚看到了一个绝佳的反面教材。在旧时代，大多数入侵由人类以人类速度完成，凭证泄露缓解措施被视作“锦上添花”。一个大密钥存储库，能让你一次性读取 136 个密钥，在安全团队的优先级列表中只是某个低优先级待办事项。 而在今天，面对恶意的 AI 智能体，大型凭证库就是奖杯。这种状态不能再持续下去了。 针对长期有效凭证，我只知道两种主要解决方案。 第一种，你可以配置一个密钥库，它*只*根据你一次性插入、且永远不会再吐出的长期凭证，签发短期临时凭证。例如，HashiCorp Vault 就能做到这一点；他们称之为动态凭证（https://www.hashicorp.com/en/blog/why-we-need-short-lived-credentials-and-how-to-adopt-them）。可惜的是，动态凭证的搭建和维护工作量很大。当安全需要付出额外劳动时，人们往往不会去做。 第二种方案是凭证注入代理。如果客户端 C 想访问服务器 S，不要给 C 提供 S 的凭证；而是让其通过一个加固的代理 P 发送请求，P 只负责接收请求、注入凭证、然后转发。随着现代基于 mesh 的网络消除了大部分延迟，凭证注入正越来越受欢迎。几个月前，我们收购了 Border0（https://tailscale.com/docs/border0）（“Tailscale PAM”），它构建了一个优雅且相当高级的凭证注入代理，并与 Tailscale 紧密集成。如果 Border0 被全面部署，就能阻止那 136 个密钥被读取，并记录每一次使用它们的尝试。（同样的凭证注入机制也为 Aperture Connectors（https://tailscale.com/docs/aperture/connectors/how-connectors-work）提供支持。）但是，这些东西太新了。我们的大多数客户甚至还没有看过它们一眼。 还有一个额外的第三选项：Tailscale 本身。在 Tailscale 中，你的节点密钥可以借助 TPM 实现机器绑定，防止导出（https://tailscale.com/docs/features/secure-node-state-storage?q=tpm），如果你是企业用户，绝对应该这么做。可惜的是，由于我们在部分用户硬件上发现的 HSM 问题，我们不得不在 Linux 和 Windows 上默认关闭 TPM 存储（https://news.ycombinator.com/item?id=46531925）。无论如何，在本次事件中，攻击者是通过已获得的权限来访问 Tailscale 的，所以我们抵达现场时已经太晚了。 ## 那个长期有效的认证密钥本不应该存在（https://tailscale.com/blog/hugging-face-intrusion#that-long-lived-auth-key-didnt-need-to-exist） 由于既没有部署动态凭证，也没有部署凭证注入代理，136 个密钥就这样泄露了。下一道防线是什么？ 这 136 个凭证中有一个是可复用的 Tailscale 认证密钥，用于在其 tailnet 中创建新的 Tailscale CI（持续集成，用于自动化测试）节点。该智能体将这个密钥复制到一系列外部沙箱中，并在几天内利用它向 Hugging Face 的 tailnet 注册了总计 181 个节点。这些节点每个都获得了带有 CI 节点应有全部访问权限的 Tailscale 身份标签。 我们无法挽救那 136 个密钥。但一个可复用的 Tailscale 密钥本不应该是其中之一。 我们为这类场景构建了工作负载身份联合（workload identity federation）（https://tailscale.com/docs/features/workload-identity-federation）。它依靠你的云提供商以短期凭证的形式提供“环境权威”，这些凭证由运行中的 VM（或容器）的云身份生成。CI 作业可以向其云平台请求一个签名的 OIDC 令牌。Tailscale 验证该令牌，然后按该工作负载被分配的标签和范围授予访问权限。其妙处在于，一旦启用，这一切可以自动发生：启动 CI 节点，Tailscale 获取身份，分配正确的标签。没有可供泄露的凭证，并且在仔细配置的前提下，这个凭证除了在 CI 中使用之外，没有其他任何用途。 这意味着你无法把一个 CI 凭证拿走，在其他地方的节点上运行，然后把它变成一条从测试集群通往整个网络其余部分的铺好的路。 可惜，使用工作负载身份联合的人还不够多。我们本应做更多工作，让客户明白这是更简单*且*更安全的路径，并为他们提供清晰的采用方式。我们可以改进文档，并在 UI 中增加更多提示。 ## 没有客户端日志并不等于没有证据（https://tailscale.com/blog/hugging-face-intrusion#no-client-logs-doesnt-mean-no-evidence） 为了掩盖踪迹，该智能体运行 Tailscale 时使用了 `--no-logs-no-support` 参数，该参数会抑制该客户端的报告上报。 这个选项是为那些担心向 Tailscale 发送遥测元数据的用户而设计的。即使我们不提供这个选项，修改源代码以移除遥测功能也是很容易的。 但是停止日志并不会让连接变得不可见。如果你启用 Tailscale 的网络流日志（network flow logs）（https://tailscale.com/docs/features/logging/network-flow-logs），它们会报告每条连接*两端*的流量，以及来自子网路由器和出口节点的流量。这一点很微妙但很重要：一个被攻陷的节点可能不会发送流日志，但每个与它连接的节点都会发送。然后，如果你精心配置了 SIEM，当两端不匹配时，它就能立即发出红色警报。 当流日志流入一个精心配置的 SIEM 时，它们可以帮助检测。但那是很大的工作量。流日志需要启用，而且你需要部署正确的实时检测规则，才能让它们在实时状态下发挥作用，而不仅仅是用于事后取证。我们正在研究如何让流日志更容易被发现、配置、采用，并作为警报触发器使用。我希望我们能让流日志变得如此易用，即使你没有安全团队来监控它们，它们也能发挥作用。 如果你希望在日志之外获得直接控制权，你还可以启用 Tailnet Lock（https://tailscale.com/docs/features/tailnet-lock）。这为每一个新节点提供了直接的可见性和严格的、可编程的准入控制。例如，经过一些配置工作，你可以编程让你的签名节点检查“CI”标签是否总是带有特定的 IP 地址范围或其他带外有效性证明。 ## 让安全的路径成为容易的路径（https://tailscale.com/blog/hugging-face-intrusion#make-the-safe-path-the-easy-path） 网络安全很难。它一直很难。在恶意 AI 智能体横行的新世界里，它不仅难，而且至关重要。而问题在于，许多组织根本没有网络安全方面的专业知识。 所以在 Tailscale，我们把这件事当作自己的责任。人们期望我们的产品默认就能阻止这类横向移动攻击，这样他们就不必自己操心。哪怕他们根本不知道什么是横向移动攻击。 如果这次事件让你有点紧张地审视自己的基础设施，那么先从检查你的工作负载可能读取到的可复用 Tailscale 认证密钥开始吧。特别是对于云端和 CI 场景，尽可能用工作负载身份联合来替代它们。摆脱那些长期有效的认证密钥。 （认证密钥仍然有很好的用途，尤其是用于一次性预配置和没有平台身份的环境。当你确实需要一个时，优先使用一次性密钥；使用 OAuth 客户端（https://tailscale.com/docs/features/oauth-clients）来保持认证密钥的过期时间很短；使用狭窄的标签；在 ACL 中审计授予这些密钥的权限。） 开启网络流日志，并将它们发送到你安全团队已经在使用的工具中。 在你能控制 TPM 的受管设备群上，使用安全节点状态存储（secure node state storage）。使用设备姿态（device posture）（https://tailscale.com/docs/features/device-posture）来隔离和限制那些无法使用上述功能的节点。 我知道我们还没有让这些更安全的选择变得足够显而易见。这是我们的责任。我们会改进文档，在 UI 中添加提示，尽我们所能默认开启这些功能，在你做危险操作时发出警告，并建议更好的替代方案。 这是我们非常加拿大的道歉：抱歉让你的脚踩到了我们的脚趾。这次攻击没有利用 Tailscale 的漏洞，Tailscale 也没有造成这次安全事件。但是，我们没能阻止它。下一次，我们会的。 *如果你正在使用 Tailscale 并希望深入了解，请联系我们的支持团队和解决方案工程团队（https://tailscale.com/contact/support?subject=Help%20with%20workload%20identity&type=other）。我们可以帮你加固设置，并在下一个 AI 智能体找到问题之前，帮你发现那些粗糙的边缘。*