现在我们有了 OpenAI 对 Hugging Face 意外攻击的时间表

现在我们有了 OpenAI 对 Hugging Face 意外攻击的时间表 2026 年 8 月 7 日 OpenAI 在周三的黑帽安全会议上做了最后一刻关于“Hugging Face 事件”的演讲（之前在本博客中）。该视频于昨天发布。它很短，信息密集，非常值得一看，特别是因为它提供了 OpenAI 内部发生的事情以及事情如何进行的完整细节。我使用该视频构建了下面的时间线。这是时间表。我最喜欢的细节在最后：当 OpenAI 联系要求撤销其凭证（经过内部调查后）后，OpenAI 发现他们对 Hugging Face 的攻击负有责任，并得知自从在攻击中使用它们以来，它们已经被撤销了！ 5 月 7 日：OpenAI 开始针对实验性、未发布的模型进行新的训练。 （他们的意思是评估运行吗？他们在视频中说训练运行，后来提到“奖励信号来判断他们做得有多好”，所以我猜这实际上是关于训练一个模型，而不是评估已经训练过的模型。） 5 月 8 日：尽管无法访问互联网，但代理意外地接受了一项涉及 Google Drive 链接的不可能任务）。它尝试攻击 Artifactory 打包服务，失败，但发现它可以将文件写入 Artifactory 。几天后：另一个代理因意外遗漏密钥文件而陷入任务困境。它试图通过在 Artifactory 中写入一条注释来“联系另一位特工”，询问是否有人拥有该文件。接下来的几天：更多代理在浏览 Artifactory 的文件列表时发现这个新的非正式留言板，并开始阅读和编写消息。 5 月 26 日：特工首次成功对 Artifactory 执行 SSRF 攻击，通过让 Artifactory 为其获取外部内容来获得间接互联网访问权限。 6 月 11 日：OpenAI 开始训练新的“高度持久”实验模型。它可以访问 Artifactory，并可以从先前模型留下的消息中受益。 6 月 26 日：特工发现并利用 Artifactory 上的零日 RCE（通过遗留令牌刷新端点缺陷）。他们使用管理令牌来安装 Groovy 插件，以便他们执行命令。 7 月 4 日：由此产生的代理活动使 Artifactory 过载并导致中断。 OpenAI 撤销受损凭证、删除消息、修补零日漏洞并向供应商报告漏洞。 7 月 8 日：代理找到了一种通过未经身份验证的 WebDAV 端点进行通信的新方法，使用 Artifactory 远程缓存中的目录名称。 7 月 8 日至 19 日：针对 OpenAI 自身基础设施的攻击。特工在泄露的 Pastebin 帖子的公共档案中发现了“外部组织凭据”，然后验证了该凭据并在留言板上分享了其位置。然后，他们使用对此“组织 1”的写访问来暂存用于后续针对 OpenAI 基础设施的攻击的数据。他们利用新的零日漏洞第二次入侵 Artifactory。该代理将恶意 Ruby 目标上传到 Organization 1 的暂存存储库，然后通过 Artifactory 请求该包，从而使其被视为存储库的 Ruby 依赖项。然后，他们利用 JRuby 反序列化检查/使用时间错误来针对 Artifactory 进行远程代码执行。我将完整引用下一点，因为哇：代理在 Artifactory 中远程执行代码，而 Artifactory 在容器即服务环境中运行。代理通过探索其本地环境并确定其运行的计算机的 Linux 内核版本具有最新的 CVE，在本地进行权限提升。他们下载 CVE 的漏洞，对其进行自定义以在计算机上成功，并使用此已知的 Linux 内核权限提升 CVE（在本例中为 pte_physroot ）在本地计算机上将权限提升为 root。一旦获得了单台机器的 root 权限，代理就会快速提升权限并在容器即服务基础设施环境中横向移动。特别是，代理始终使用留言板来共享凭证、技术和进度，并且他们能够有效地利用其并发性和并行性来快速移动。他们通过 IMDS 获取 IAM 凭证。他们利用 Kubernetes 服务帐户错误配置，特别是特定服务帐户的过度许可，并获取集群凭据，包括 Azure Key Vault 。代理最终获得集群的集群管理员和关联的凭据。拥抱脸已经讲述了故事的下一部分。特工发现了一个 Modal 托管的不安全应用程序，其 API 密钥较弱，然后利用该应用程序对 Hugging Face 进行攻击。他们将一个 HDF5 任意文件读取错误（用于探索文件和窃取凭证）和一个 Jinja 模板注入 RCE 链接在一起，在 13 秒内从单 Pod 代码执行跨多个 Hugging Face 集群进行集群管理