Tailscale 并没有阻止 Hugging Face 的入侵

到目前为止，您可能已经听说过 AI 代理逃脱了安全评估并攻击了 LLM 市场 Hugging Face。该代理商认为 Hugging Face 可能拥有其基准测试的答案，因此它窃取了这些答案只是为了在考试中作弊。这是一个有趣的动机，但结果却很可怕。 Hugging Face 发布了入侵事件的详细重建。它涵盖了在四天半的时间里恢复的约 17,600 个操作，包括沙箱逃逸、代码执行、云凭证、临时命令和控制系统，以及最终使用 Tailscale 在整个组织中传播。但 Tailscale 是一个零信任网络！零信任的全部目的是防止攻击者在您的公司内横向移动。出了什么问题？ Tailscale 中没有发现或利用任何“漏洞”，这可能会让我们更加不舒服。 Tailscale 在人工智能基础设施中随处可见：几乎每个人工智能公司都使用 Tailscale。因此，我们最终出现在人工智能事件报告中也就不足为奇了。但是，我们是一个安全工具。他们的入侵就是我们的入侵，我们的工作就是认真对待。与任何事后剖析一样，我们需要反思发生的事情以及我们可以采取哪些措施来防止它发生。当代理逃离沙箱并找到 Tailscale 时，它​​已经获得了生产工作进程内的代码执行权限，达到了 Kubernetes 节点的 root 访问权限，并读取了包含 136 个密钥的生产秘密存储。从某种意义上说，在我们到达现场之前，游戏就已经结束了。但这不是问题所在吗？让我们备份一两个级别。为什么任何人都可以访问长期密钥？但他们不应该这样。现在我们已经看到了一个很好的例子来说明原因。在过去，大多数入侵都是由人类以人类的速度完成的，因此凭证泄露缓解措施被视为“可有可无”。可以同时读取 136 个密钥的大型凭证存储是安全团队低优先级列表中的一项待办事项。现在，在流氓人工智能代理的世界中，大型凭证库就是奖品。已经不行了。我只知道长期凭证的两个主要解决方案。首先，您可以配置一个保管库，该保管库仅根据您插入一次且永远不会返还的长期信用来颁发短期信用。例如，HashiCorp Vault 可以做到这一点；他们称之为动态凭证。不幸的是，动态凭证的设置和维护工作量很大。当安全需要工作时，人们不会这样做。第二个选项是凭据注入代理。如果客户端C想要访问服务器S，则不要向C提供S的凭据；相反，让它通过强化代理 P 发送请求，该代理除了接收请求、插入凭据并将其传递之外什么也不做。由于现代基于网格的网络消除了大部分延迟，凭证注入越来越受欢迎。几个月前，我们收购了 Border0（“Tailscale PAM”），它是一个优雅且非常奇特的凭证注入代理，与 Tailscale 紧密集成。完全部署的 Border0 将阻止读取这 136 个密钥，并记录每次使用其中一个密钥的尝试。 （同样的凭证注入为 Aperture 连接器提供了动力。）但是，这个东西太新了。我们的大多数客户甚至还没有看过它。第三个额外选项：Tailscale 本身。在 Tailscale 中，您的节点密钥可以使用 TPM 进行机器绑定以防止导出，如果您是企业，那么您绝对应该这样做。遗憾的是，由于我们在某些用户的硬件上发现了 HSM 问题，我们不得不在 Linux 和 Windows 上默认关闭 TPM 存储。不管怎样，在今天的例子中，攻击是授予 Tailscale 访问权限的原因，所以我们来得太晚了。动态凭证和凭证注入代理都没有到位，因此 136 个密钥被泄露。下一道防线是什么？这 136 个凭证之一是可重复使用的 Tailscale 身份验证密钥，用于在其 tailnet 中创建新的 Tailscale CI（持续集成，用于自动化测试）节点。该代理将该密钥复制到一系列外部沙箱中，并使用它在几天内将总共 181 个节点注册到 Hugging Face 的尾网中。这些节点每个都收到一个 Tailscale 身份标签，授予 CI 节点将获得的所有访问权限。我们无法保存那 136 个密钥。但可重复使用的 Tailscale 钥匙并不需要在其中。我们针对此类情况构建了工作负载身份联合。它依赖于您的云提供商以从正在运行的虚拟机（或容器）云身份生成的短期信用的形式提供“环境权威”。 CI 作业可以向其云平台请求签名的 OIDC 令牌。 Tailscale 验证令牌，然后使用分配给该工作负载的标签和范围授予访问权限。巧妙的是，一旦启用，这就会自动发生：启动 CI 节点，Tailscale 获取身份，分配正确的标签。没有任何凭证可以泄漏，并且在仔细配置后，除了在 CI 中之外，无法在任何地方使用此凭证。这意味着你不能获取 CI 凭证，运行