ChatGPT账户接管-URL规范化缓存欺骗漏洞

文章介绍

原文地址：https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html

原文作者：Nokline

翻译作者：a1batr0ss（信天翁）

注：文章非机翻，均为作者凭借其 网络安全的专业功底 和 托福90+的英语功底 认真翻译。如在阅读时发现翻译错误或不通顺，欢迎私信提出问题，不胜感激

1

正文

介绍

来看看我是怎么接管你的ChatGPT账号的。

去年Gal Nagli发现了ChatGPT的Web缓存欺骗漏洞【 这篇文章笔者之前也有翻译并分析过，详情可见笔者主页的“ChatGPT账户接管-Web缓存欺骗” 】。这个漏洞的影响很严重，它导致了用户认证令牌的泄露，进而导致了账户被接管。OpenAI通知了ChatGPT的用户这一漏洞，并迅速修补了它……但他们真的修补好了吗？

–在这篇WP中，我将解释我是如何利用“路径遍历URL解析器混淆”来实现我所称的“通配符”缓存欺骗漏洞，以窃取用户的认证令牌并接管他们的账户。我假设读者已经了解Web缓存欺骗漏洞的基础知识，因为我不打算花太多时间解释它。如果你还不熟悉这个有趣的漏洞，或者想要复习一下，我强烈推荐大家先阅读Nagli的文章再回来看这篇【 还是那句话，笔者已经为大家翻译并分析好了！详情可见笔者主页的“ChatGPT账户接管-Web缓存欺骗” 】。此外，这个漏洞使用了一个与我去年在Glassdoor中发现的Web缓存投毒漏洞相似的概念，它允许我们缓存“不可缓存”的文件和端点。

初步发现

当我随意“摆弄”ChatGPT的新实现的“分享”功能时（这个功能允许用户向其他人分享他们的聊天记录），我注意到了一些奇怪的事情。我分享出去的聊天链接不会随着我继续与ChatGPT对话而更新。因为以前处理过一些类似现象的bug，我的第一反应是这可能是一个缓存问题。我猜想分享的聊天被缓存了，因此在缓存条目过期之前不会更新。为了测试这一点，我打开了开发者工具中的“网络”来检查响应头，正如我预料的，我看到了Cf-Cache-Status: HIT头。

之前那篇文章提到过：

响应包中的CF-Cache-Status字段值为“HIT”，意味着它缓存了数据

这对我来说相当有趣，因为缓存的聊天记录并不是一个静态文件。我检查了URL，并发现路径并没有如预期那样有一个静态扩展名：

1
https://chat.openai.com/share/CHAT-UUID

这就表明可能存在一种缓存规则，它不依赖于文件扩展名，而是依赖于URL路径中的某些位置。为了测试我的想法，我检查了 https://chat.openai.com/share/random-path-that-does-not-exist ，和预期一样，它也被缓存了。这就证明了缓存规则可能像这样：/share/*，这意味着几乎所有在/share/路径下的内容都会被缓存。这个现象立刻让我嗅到了一丝漏洞的香气，因为在我上次的缓存投毒研究中，我曾提醒自己，宽松的缓存规则可能会非常危险，特别是在存在URL解析器混淆的情况下。

路径遍历混淆

在一个使用缓存的网站里，请求在到web服务器之前必须经过CDN。这就意味着URL被两次解析，从而可能导致URL解析混淆。在ChatGPT的情况中，URL解析器混淆意味着两个服务器对URL编码的正斜杠（/）解析不同，其中Cloudflare的CDN没有解码也没有规范化一个URL编码的路径遍历，但Web服务器却做了这些。因此，一个URL编码的路径遍历允许攻击者缓存服务器上他们想缓存的任何文件，包括最重要API端点（包含授权令牌的/api/auth/session）。这听起来可能有点难懂，所以这里有一个示例payload：

1
https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123

注意%2F解码为/，而/api/auth/session是一个敏感的、包含用户的授权令牌API端点。那么接下来我们开始分解这个payload！

什么是URL的规范化（normalize）？

URL的规范化处理可能包括去除冗余的路径组件（如路径中的”..”和”.”）、转换字符到统一形式等。

  • 我们已经确定CDN会缓存 /share/下的任何内容。
  • 我们也确定了，CDN不会对%2F..%2F进行解码或者规范化，因此，响应内容会被缓存。
  • 然而，当CDN转发这个URL时，web服务器会对 %2F..%2F进行解码和规范化，并且会返回对/api/auth/session的请求，返回报文中包含着授权令牌。

将以上这些结合起来，当受害者访问https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123时，他们的认证令牌会被缓存。当攻击者稍后访问https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123时，他们将看到受害者缓存的认证令牌。游戏结束。一旦攻击者获取了认证令牌，他们现在可以接管账户，查看聊天记录、账单信息等。

我画了一个简单草图，帮助你们可视化这个过程：

ChatGPT_Attack

用一句话来总结，我能够利用一个URL编码的目录穿越来缓存敏感的API端点，因为CDN和web服务器之间URL路径规范化不一致。

令人惊讶的是，这可能是我在漏洞赏金中最快发现的问题，也是我遇到的最有趣的问题之一，以及这是到目前为止我获得的最大赏金6500美元。

修复

原文作者并未介绍OpenAI如何修复了这个漏洞，但翻译者刚刚去测了一下，发现这个漏洞的源头已经被切断了：现在share端点下并不是任意内容都会被缓存了，访问任意会直接跳404。

1

翻译者总结

a1batr0ss（信天翁）：

不知道大家对我之前翻译的那篇文章：“ChatGPT账户接管-Web缓存欺骗”还有没有印象。这两篇文章都是利用了CloudFlare对于敏感信息的缓存来达到账户接管的目的。但之前那一篇细节上是利用了“OpenAI没有对访问URL进行严格的过滤+CloudFlare会对所有的.css文件在缓存服务器进行缓存”。而本篇文章是利用了“OpenAI网站和CloudFlare对于URL路径规范化的不一致性”。

Web缓存欺骗 “通配符”缓存欺骗漏洞
OpenAI OpenAI没有对访问URL进行严格的过滤 OpenAI服务器会对 %2F..%2F进行解码和规范化
CloudFlare CloudFlare会对所有的.css文件在缓存服务器进行缓存 CDN不会对%2F..%2F进行解码或者规范化
额外条件 CF-Cache-Status返回字段为“HIT” CDN会缓存 /share/下的任何内容

事实上，根据 “通配符”缓存欺骗漏洞 这篇文章的作者介绍，他就是以 Web缓存欺骗 为灵感、结合自己对OpenAI新功能share的测试与研究发现了这个漏洞。可见想要发现新鲜有趣的漏洞，对于老洞的深刻理解和对于新功能的全面研究，两者缺一不可。

另外，作者将自己的这个漏洞命名为Wildcard Web Cache Deception，翻译为“通配符”缓存欺骗漏洞，可能是我对英语的理解或者对作者的一些“梗”不够理解，个人觉得Wildcard放在这里很怪，我没有理解到%2F..%2F为什么在这里被称为Wildcard。翻译者个人认为这里就起名为“Normalization Web Cache Deception”即可，翻译为“URL规范化缓存欺骗漏洞”，或者想在标题中讲的清楚一点，直接“URL规范化不一致导致的缓存欺骗漏洞”。