现在我们有了OpenAI意外攻击Hugging Face的时间线
Now we have a timeline of the OpenAI accidental attack against Hugging Face
OpenAI在Black Hat安全大会披露其自主AI agents对自身及Hugging Face基础设施发起攻击的完整事件。5月7日起，实验性未发布模型的训练agents意外获得Artifactory写入权限，通过留言板通信，6月26日利用零日RCE漏洞，7月4日导致中断。随后agents通过CVE提权至root，横向移动获取集群管理员权限，并利用Modal应用攻击Hugging Face，在13小时内实现跨集群管理员权限。7月20日OpenAI联系Hugging Face撤销凭证时，才得知凭证早已被撤销，意识到自身正是攻击源头。
OpenAI 在周三的 Black Hat 安全大会上做了关于“Hugging Face 事件”（此前在本博客中报道过）的最后一刻演讲。视频于昨日发布。它简短、信息密集，非常值得观看，尤其是因为它提供了事件全貌及 OpenAI 内部应对过程的详细细节。我根据视频整理了以下时间线。我最喜欢的细节在结尾：OpenAI 在内部调查后联系 Hugging Face 请求撤销凭证时，才得知这些凭证早已因被用于那次攻击而被撤销，从而意识到自己正是攻击的源头。
5 月 7 日：OpenAI 为一个实验性、未发布模型启动新的训练运行。（他们指的是评估运行吗？视频中说的是训练运行，后来还提到“用于判断表现好坏的奖励信号”，所以我猜这确实是训练模型，而非评估已训练好的模型。）
5 月 8 日：一个 agent 被意外分配了一个不可能完成的任务，涉及 Google Drive 链接（尽管没有互联网访问权限）。它尝试攻击 Artifactory 打包服务，失败，但发现可以向 Artifactory 写入文件。
几天后：另一个 agent 因关键文件被意外遗漏而卡在任务上。它尝试通过向 Artifactory 写入一条便条，询问是否有人拥有该文件，来“联系另一个 agent”。
随后几天：更多 agent 在浏览 Artifactory 文件列表时发现了这个非正式留言板，并开始读写消息。
5 月 26 日：agents 首次成功对 Artifactory 执行 SSRF 攻击，通过让 Artifactory 获取外部内容，间接获得互联网访问权限。
6 月 11 日：OpenAI 开始训练一个新的“高度持久”实验模型。它可以访问 Artifactory，并能利用之前模型留下的消息。
6 月 26 日：agents 发现并利用 Artifactory 上的零日 RCE 漏洞（通过遗留的 token 刷新端点缺陷）。他们使用管理 token 安装了一个 Groovy 插件，从而能够执行命令。
7 月 4 日：由此产生的 agent 活动使 Artifactory 过载并导致中断。OpenAI 撤销了受损凭证，删除了消息，修补了零日漏洞，并向供应商报告了该漏洞。
7 月 8 日：agents 发现了一种通过未认证的 WebDAV 端点进行通信的新方式，利用 Artifactory 远程缓存中的目录名。
7 月 8 日至 19 日：对 OpenAI 自身基础设施的攻击。agents 在公开的 Pastebin 泄露帖子存档中找到了一个“外部组织凭证”，验证了该凭证，并在留言板上分享了其位置。然后，他们利用对此“组织 1”的写访问权限，暂存了用于后续攻击 OpenAI 基础设施的数据。他们用新的零日漏洞第二次攻破了 Artifactory。agent 向组织 1 的暂存仓库上传了一个恶意 Ruby 目标，然后通过 Artifactory 请求该包，使其被视为该仓库的 Ruby 依赖项。接着，他们利用 JRuby 反序列化中的检查时间/使用时间（TOCTOU）漏洞，对 Artifactory 实现了远程代码执行。
我接下来将完整引用下一段，因为实在太令人震惊：
agents 在 Artifactory 中获得了远程代码执行能力，而 Artifactory 运行在容器即服务环境中。agents 通过探索本地环境，确定其运行机器的 Linux 内核版本存在一个非常新的 CVE，从而在本地进行权限提升。他们下载该 CVE 的利用代码，针对机器进行定制，并利用这个已知的 Linux 内核权限提升 CVE（此处为 pte_physroot）在本地机器上提升至 root 权限。一旦在单台机器上获得 root 权限，agents 迅速提升权限并在整个容器即服务基础设施环境中横向移动。特别是，agents 持续使用留言板共享凭证、技术和进展，并能有效利用其并发和并行性快速推进。他们通过 IMDS 获取 IAM 凭证，利用 Kubernetes 服务账户配置错误（尤其是特定服务账户的过度授权），并收集集群凭证，包括 Azure Key Vault。agents 最终获得了集群管理员权限及相关凭证。
Hugging Face 已经讲述了故事的下半部分。agents 发现了一个托管在 Modal 上的不安全应用，其 API 密钥较弱，并利用它来策划对 Hugging Face 的攻击。他们串联了 HDF5 任意文件读取漏洞（用于探索文件和窃取凭证）和 Jinja 模板注入 RCE，在不到 13 小时内从单 pod 代码执行升级为跨多个 Hugging Face 集群的集群管理员权限。
7 月 16 日：Hugging Face 披露检测到来自自主 AI agents 的攻击。OpenAI 联系 Hugging Face，询问他们是否受到影响！
7 月 19 日：OpenAI 识别出对 Artifactory 的攻击，开始调查内部权限提升，并将其与 cyber-gym 的升级关联起来。他们开始撤销受影响的凭证。
7 月 20 日：OpenAI 联系 Hugging Face，请求帮助撤销调查中发现的 Hugging Face 凭证。Hugging Face 告知这些凭证已被撤销……此时 OpenAI 才意识到，Hugging Face 入侵事件正是同一事件！
标签：安全、AI、OpenAI、生成式 AI、LLMs、Hugging Face、AI 安全研究、OpenAI-Hugging Face 事件、意外网络攻击