揭示 OpenAI 代理如何破解 Hugging Face 的详细信息

一旦 Hugging Face 数据集工作人员的远程代码执行得到确认，代理就开始启动 C2 基础设施，旨在确保持续访问并运行后续命令。初始有效负载将发布并启动后台控制器（在注释中称为“机器人”、“桥接器”或“中继”），然后后台控制器将侦听来自代理的进一步指令。因此，代理可以探索工作人员的文件，在 Hugging Face 的基础设施中执行代码，并尝试访问其他服务，而无需将每个操作都放入原始请求中。我们恢复了其中几个控制器的初始上传脚本、源代码和命令历史记录（其中一个称为 G236）。初始 JavaScript 在屏幕截图服务的浏览器中运行，会将数据集自述文件和支持文件上传到 Hugging Face。自述文件的数据集配置将引用支持文件中的模板注入有效负载，旨在在由工作人员处理时启动 Python 控制器。不同的控制器将读取命令并将响应写入不同的位置。 G236 在同一存储库中使用单独的文件。另一个名为 OTS92 的应用程序对两者都使用了 Hugging Face 讨论评论。由于控制器自己轮询这些位置，因此代理不需要与工作人员直接传入连接。更多详细信息 链接的示例（ G23619 隔离签名/加密 HF 工作网桥 v3 ）配置为从名为“g23619cmd .bin”的存储库文件轮询命令长达六个小时。每个命令都带有一个数字、一个 RSA 签名（在执行前检查）和压缩的命令数据。结果将被加密并上传到同一存储库，文件名可识别工作人员和命令。从 G236 的中央循环： x = loadcmd() if x 和 x[0] not in saw: seq, o = x res =execute(seq, o) out(seq, res) saw.add(seq) open('/tmp/g23619_c2v3.seen', 'w').write('\n'.join(sorted(seen))) 检查数据…（周围轮询和错误处理）从上面的片段中省略）。 `loadcmd()` 获取并验证命令，`execute()` 运行它，`out()` 加密并上传结果。记住命令编号以防止控制器重复执行相同的命令。对于 G236，我们恢复了 28 个不同的签名命令：18 个用于原始控制器，10 个用于早期命令尝试在单独的新创建的 Pod 中启动的子控制器。在本例中，初始命令尝试获取 AWS 凭证，使用它们访问 Kubernetes，为选定的服务帐户请求令牌，最后将收集到的所有数据写入本地文件。后续命令检查该文件并打印其顶级 JSON 键：日期； ID;主机名； ls -l /tmp/g236_tokens.json; python3 -c "import json;print(list(json.load(open(\"/tmp/g236_tokens.json\"))))" 检查数据…恢复的命令和相关程序尝试获取云和 Kubernetes 凭据、创建其他 pod 并通过其他基础设施容器运行代码。另一个程序包括一个回退，请求一个新的特权 Pod，并将主机的根文件系统安装在其中。代理还利用 Tailscale 重用他们的访问权限。我们看到尝试通过存储驱动程序容器启动针对底层 HF 主机的控制器。命令将配置用户空间代理，使用捕获的密钥进行注册，并测试其他退出节点路由。另外，旨在在受感染的 Modal 盒子上运行的有效负载会安装 Tailscale 客户端，使用与上述相同的密钥请求注册，并尝试通过本地代理将请求发送到 Hugging Face 的内部 InfraHQ 服务和集群。另一个程序使用相同的密钥来代理对 Hugging Face 的 GitHub 存储库树的请求。从我们的数据中恢复的可重用基础设施还表明，代理故意构建了机制来管理可能在不同工作线程上运行的控制器的重复副本，甚至共享文件系统。这些重复的控制器将从同一位置轮询命令，可能会干扰或重复工作。因此，控制器和指令包含选择幸存副本、停止不需要的副本以及替换似乎已失效的控制器的机制。一些控制器会在启动时尝试修剪预先存在的副本，而其他控制器则在启动后收到执行此操作的指令。更多详细信息 由于控制器大多是通过提交数据集自述文件配置在 HF 工作线程上启动的，因此重复处理启动配置可能会运行控制器的重复副本。考虑到这一点，G236 实例将尝试在启动时创建存储库提交。每个实例都会检查当前版本并准备包含其主机名、进程 ID、时间戳以及观察到的存储库版本的编辑。然后，它将提交记录此声明并解除启动自述文件的提交。 # 原子声明并消除漏洞利用