【漏洞赏金报告】挖掘ChatGPT中的XSS漏洞导致账户接管

ChatGPT 在企业和个人用户中广泛使用，因此成为攻击者获取敏感信息的主要目标。在这篇文章中，我将介绍我在 ChatGPT 中发现的两个跨站点脚本 (XSS) 漏洞和其他几个漏洞。如果这些漏洞结合在一起，可能会导致帐户被盗用。

我的旅程始于研究 ChatGPT 的技术堆栈。使用流行的 React 框架 NextJS 最初让我对发现 XSS 漏洞持怀疑态度。然而，当我探索其功能和客户端代码时，我注意到一些事情改变了我的想法。

ChatGPT 允许用户上传文件并提出相关问题。在回答时，ChatGPT 可能会引用这些文件，并包含一个可点击的引用图标，可带您返回原始文件或网站以供参考。

上面的代码处理引文点击事件。它将文件的内容处理成一个 blob，然后使用 `window.open` 函数打开。根据文件内容类型，此方法可能存在安全风险。

我通过上传包含文本和 JavaScript 的 HTML 文件对此进行了测试。ChatGPT 对其进行了处理并提供了引文。当我单击引文时，HTML 内容通过 blob URL 显示在我的屏幕上，但内容安全策略 (CSP) 违规阻止了我的 JavaScript 负载。

下图为chatgpt csp策略

在调查 CSP 政策时，我注意到，本来应该是动态的 nonce 值实际上是静态的。nonce 是一个唯一字符串，可让特定 HTML 元素绕过 CSP 限制。通常，此值会随着每次请求而变化，以确保只有服务器批准的元素才能执行。然而，这里它保持不变。

使用另一个帐户和不同的 IP 地址进行测试证实了这个问题。然后，我上传了一个带有包含此 nonce 属性的脚本标记的新 HTML 文件。这一次，单击引用后，我的脚本成功执行。

利用此漏洞并不简单。它要求用户上传有害文件，并以一种提示 ChatGPT 引用此文件的方式参与。然后，用户需要单击引用以触发 XSS。

我研究了 ChatGPT 的共享对话功能，作为使此漏洞可共享的一种可能方法。计划是与目标共享对话链接并让他们单击引用，这将触发 XSS。

这种方法没有按预期发挥作用。在 ChatGPT 对话中上传的文件只能由上传它们的帐户访问。尝试从另一个帐户访问这些文件会导致 404 错误。

文件下载失败

OpenAI 推出的 GPT 附带知识文件。这些文件通过与用户上传文件使用的 API 非常相似的 API 运行，但有一个值得注意的附加项——“gizmo_id”参数。通过我的探索，我发现当 GPT 设置为公开时，它允许任何帐户访问和下载这些知识文件，只要他们拥有必要的信息——具体来说，就是 GPT ID 和关联的文件 ID。

我认为这是一个损坏的功能级别授权错误，因为它允许任何 ChatGPT 用户下载公开的 GPT 知识文件。

这导致了新的利用可能性。如果我可以让共享对话请求公开文件而不是原始上传的文件，那么就可以利用 XSS 漏洞。

我专注于启动 ChatGPT 对话的“/backend-api/conversation”端点。请求正文如下所示：

我注意到这个结构与我之前创建的共享 ChatGPT 对话的“pageProps”对象中看到的助手的元数据类似。

我在助手消息元数据中看到了引用对象，其中包含我上传的文件 ID。这与我最初讨论的用于获取文件内容的易受攻击的代码使用的 ID 相同。此时，我意识到，如果我能控制这个元数据，我可能就可以让这个漏洞可共享。

然后，我探索了是否可以以及如何操纵这些元数据。我首先尝试将对话中的角色从“用户”更改为“助手”。令我惊讶的是，ChatGPT 接受了这一变化，并继续生成响应，就好像它们来自助手一样。

接下来，我尝试调整元数据以匹配我在“pageProps”对象中看到的引用结构。这种方法也有效，表明存在批量分配漏洞。当应用程序不加区分地将用户提供的数据分配给内部对象或变量时，就会出现批量分配漏洞。如果应用程序没有正确过滤或限制可以分配的数据，就会发生这种情况。在这种情况下，我可以使用输入数据来操纵 ChatGPT 应用程序的各个方面（特别是引用元数据），而这些方式通常不应该让普通用户使用。

我向“/backend-api/conversation”端点发起了一个新请求，冒充助手并注入自定义引用对象。我做的唯一更改是将文件 ID 设置为“file-Cbn7djQD1W20s3h5JM8NfFs8/download?gizmo_id=g-ghPiYIKcD#”，从而强制 ChatGPT 客户端改用 GPTs API。

此漏洞按计划进行。我创建并分享了一个对话，当使用另一个 ChatGPT 帐户进行测试时，单击对话中的任何引用都会从我的公共 GPT 下载知识文件，从而触发 XSS。

我向 OpenAI 报告了这个漏洞。他们的回应是删除 blob 创建并修改逻辑以直接打开下载 URL。

OpenAI 的修补代码

修复后，我检查了涉及“context_connector”、“metadata”和“download_url”的其他功能。但是，这些组件没有出现任何新的漏洞，因为对话元数据无法直接控制这些值。

然后，我通过检查与 ChatGPT 如何处理网站引文渲染相关的其他功能，扩大了调查范围。这项探索让我找到了以下代码：

易受攻击的代码

在检查代码时，我注意到引用元数据对象（在代码中称为“em”）直接用于设置引用链接的“href”属性（即 `em.url`）。这是一个危险信号，因为我已经确定，我可以通过模仿助手来操纵元数据。

为了测试此漏洞，我建立了一个新对话。在此设置中，我操纵了引用元数据，将其 URL 值设置为 JavaScript 协议 URL，例如“javascript:alert(1)”。但是，利用并未按计划进行。虽然我成功地将锚标记的 `href` 属性设置为我的 JavaScript URL，但该标记还包含一个 `target=”_blank”` 属性。正如我在之前的博客文章“使用键盘快捷键破解 Microsoft 和 Wix”中讨论的那样，此属性只能使用键盘快捷键来利用。

ChatGPT 允许使用 `iframe` 将其界面嵌入到其他网站中。这意味着可以从完全不同的网站触发漏洞。

在我的概念验证中，我将共享的 ChatGPT 对话嵌入到 `iframe` 中，并使用 CSS 对其进行定位，以便任何点击都会无意中触发引用链接。为了使 iframe 不可见，我将其不透明度设置为零。在这个不可见的 iframe 上，我添加了文本“按住 ⌘ 并单击以在新选项卡中打开我”。按照这些说明操作的用户会在不知情的情况下在 chat.openai.com 上执行任意 JavaScript。

另一个障碍涉及 SameSite cookies 和存储分区，这些安全措施旨在通过限制浏览器如何管理不同来源的 cookies 和其他类型的存储来保护网络上的隐私和安全。在我们的场景中，当用户访问嵌入了链接到我们的 ChatGPT 共享对话的 iframe 的恶意网站时，这些措施将阻止对 ChatGPT 会话 cookie 和 LocalStorage 的访问，从而有效地将他们从 iframe 中的帐户中注销。

这些安全功能旨在防止跨站点请求伪造 (CSRF) 攻击和各种形式的侧信道跨站点跟踪攻击，例如计时攻击、XS 泄漏和跨源状态推断 (COSI) 攻击。值得注意的是，这些措施的威胁模型不包括跨站点脚本 (XSS)，这是我们在本场景中利用的漏洞。

通过在 chat.openai.com 上下文中创建包含 HTML 内容的 Blob 对象并使用 URL.createObjectURL 方法为其生成 URL，我能够将父窗口导航到此 Blob URL。这绕过了 SameSite cookie 限制和存储分区。这是可能的，因为从 chat.openai.com 内部发起的导航被视为同源请求，因此不受典型的跨源限制，从而可以接管任何 ChatGPT 帐户。

以下是我们最终的漏洞利用代码：

文章来源：https://www.imperva.com/blog/xss-marks-the-spot-digging-up-vulnerabilities-in-chatgpt/

本公众号仅提供翻译

原文始发于微信公众号（道一安全）：【漏洞赏金报告】挖掘ChatGPT中的XSS漏洞导致账户接管