chatGPT账户接管漏洞详细

    我怎么成功攻击任何ChatGPT帐户，包括已保存的对话、帐户状态、聊天记录等等，4 个 ChatGPT 漏洞的详细我可以公开了，因为OpenAI团队已经确认它已完全修复。

    在OpenAI修复了由@naglinagli，有一行引起了我的注意：“..指示缓存服务器不要通过regex捕获端点（这是@OpenAI选择修复方法描述）”。看描述我猜测修复可能有问题，所以决定详细测试下。

    我更深入地研究了并分析测试了 Auth API……但没有成功。 我以为缓存欺骗是固定的。但是在 Auth API 上失败的绕过尝试在另一个 API 上起作用，这个api允许访问用户的所有对话标题。

    到这里，我能找到的漏洞只是一种绕过读取某人对话标题。虽然漏洞已经很糟糕，但还是想进一步尝试接管账号。

    为了解释上图，我们正在获取 API 请求（不是静态文件）的“HIT”缓存状态。这意味着“API”请求被缓存，因为 Cloudflare 认为这是一个需要缓存的静态文件请求。因此，可以伪造基于 URL 的漏洞，例如：

GET /backend-api/conversations%0A%0D-testtest.css?offset=0&limit=20

    将其发送给受害者，并在访问它时，他自己的“API”响应将被缓存，如果这时重新访问相同的 URL（即获取受害者的缓存响应），就能够看到受害者的 HTTP 响应，其中包含对话的标题。

    这称为缓存欺骗攻击。有了这个发现，我决定将其报告给 OpenAI 团队并得到以下回复：（更多详情https://omergil.blogspot.com/2017/02/web-cache-deception-attack.html）

    然后我回去重新开始寻找。让我有点困扰的是我无法绕过那个 Auth API，我报告的只是阅读用户的对话标题。

    现在进入有趣的部分之一。我找到了一个新的向量来绕过原始帐户接管攻击的修复。我认为 %0A%0D 有效负载也适用于 Auth API，但事实并非如此：

    因此，我认为 CRLF 字符正在针对 Auth 会话 API 进行转义，但我怀疑它们能够捕获其他字符。我知道正则表达式在捕获编码的空白字符方面很糟糕，尤其是当它在不同的跃点之间转发时。

    所以我附加了制表的 URL 编码表示形式 (t) – %09，以及有效payload (%0A%0D%09)，我能够使用新的有效载荷绕过 OpenAI 对原始帐户接管问题的修复，从而使这个问题重现——接管任何用户帐户

    有了这个，我就可以绕过 OpenAI 对原始帐户接管问题的修复，使用新的有效负载，使这个问题重现：接管任何用户帐户，但这只是我接下来要展示的其他发现之一：

    这并没有就此停止。我认为所有的 chat[.].openai[.]com API 都容易受到相同的绕过负载的攻击。

获取某人的完整对话：

获取用户对话标题：

获取他们的账户状态：

    使用 OpenAI 进行修复：我前几天深夜和 OpenAI 团队进行了几次讨论，帮助他们解决了这四个问题。在遇到几个网络缓存欺骗问题并修复它们之后，我向 OpenAI 团队发送了明确的说明，说明如何正确修复它并避免再次绕过它：

同类问题的修复建议：

    使用正则表达式修复此问题并不是最好的。对于那些对 OpenAI 实施的新修复感兴趣的人：您需要将 Content-Type 与 URL 文件扩展名进行比较，Cloudflare 上有一个名为“Cache Deception Armor”的模块可以做到这一点

可以参考：https://developers.cloudflare.com/cache/about/cache-deception-armor/

原文始发于微信公众号（军机故阁）：chatGPT账户接管漏洞详细