白帽故事 · 2024年5月26日

AI黑客:ChatGPT中的高级API攻击

背景介绍

许多影响最大的漏洞是无法通过 Burp Suite 的默认规则集捕获,而需要手动测试,本文就是讲述了这样一个的案例。

发现异常

与往常一样,研究人员的调查首先在 Burp Suite 中捕获所有 ChatGPT 请求,然后启动’自动扫描‘来寻找 API 中值得探索的’有趣‘领域。

当使用 Burp Suite 的自动扫描针对 ChatGPT 等成熟 API 测试时,一般不会抱有发现漏洞的期望。更多的是通过寻找奇怪的响应或错误响应。

很多人在执行 API 测试时往往会忽略观察 Logger 中一闪而过的自动请求,在自动扫描期间观察Logger时,研究人员通常会查看两处主要细节:HTTP Status code和响应长度(Length),在查看 ChatGPT 的 API 上运行的定制化 Burp Suite 扫描时,出现了下面的奇怪请求:

这是一个 401 响应状态码,并且响应长度不是864字节,同时在 Query 列中还多了一串字符串。让我们看看这个请求包的具体样子:

左侧的请求是对 TE.CL HTTP 请求走私测试,右侧的响应是对单个请求的两个响应。

深入挖掘

简化PoC,以便能够更好地了解后端发生的情况:

这些请求中的每一个都使用准确的 Content-Length 标头,但未使用正常的双 rn 去正确终止。

看起来前端 CloudFlare 服务器仅根据内容长度而不是进一步的分隔符来解析多个请求,于是将分解的请求分别发送到了后端服务器。

这是 HTTP 请求走私吗?

这不太符合 HTTP 请求走私的传统定义,当攻击者发送PoC请求时,就会发生常规 HTTP 请求走私,该请求在前端服务器和后端服务器之间进行不同的解析,导致攻击者或应用程序的用户接收到他们不希望接收的数据。

看起来这好像是基于原始异常请求的 HTTP 请求走私,但经过深入研究,似乎更像是 HTTP 请求隧道。

HTTP 请求隧道能够发送打包在单个请求中的多个请求,并让后端单独解析它们。它本身并不是一个漏洞,但它是对正常代码路径的一个有用的偏离,通常会导致利用。

研究人员尝试了许多不同的方法来利用这一点,使用多个不同的授权令牌,添加新的标头,例如“openai-organization: openai”,更改主机标头以指向不同的域,在请求其他用户的数据时添加“please”和“thank you”,该架构的一个突出特点就是绕过了速率限制。

速率限制绕过

我们通常会使用 TurboIntruder 插件来测试速率限制绕过,该插件使用自己的自定义网络堆栈以极快的速度向服务器发送请求,但这无法绕过 text-davinci-edit-001 模型的 20 个请求/分钟限制。

使用 TurboIntruder 测试时,会发现立即收到了 20 个请求,然后收到 429 Rate Limit Exceeded HTTP 响应,这表明 API 速率限制按预期执行。

然而使用多个PoC请求叠加的自定义Repeater group中,可以在 50 秒内获得了 31 个响应:

Protect AI 几个月前通过漏洞赏金计划联系了 OpenAI,但 OpenAI 认为这不是漏洞。

并未结束

根据测试中对API的观察,研究人员坚定认为这不太可能是ChatGPT API 这个特定‘怪癖’中潜在可利用性的终结,并且在测试过程中出现了其他一些有趣的事情。

例如,并不是每次都会收到对所有拆分请求的响应,当在单个请求中包含 2 个拆分请求时,大约 90% 的情况下会收到两个响应,那么其他请求去了哪里?

它们是否正在被处理?或是被发送给了另一个用户?是否存在响应队列‘中毒’的可能性?此外,通过向服务器提供无效的授权令牌,可以显著增加服务器的响应时间,这可能有利于增加连接打开的时间并导致服务器的HTTP响应队列出现问题。

以上内容由骨哥翻译并整理。

原文:https://blog.huntr.com/advanced-api-attacks-in-chatgpt