ChatGPT-Next-Web漏洞利用分析（CVE-2023-49785）

合天网安实验室發表於2024-05-07
ChatGPTWeb

1. 漏洞介紹

日常網上衝浪，突然粗看以為是有關Chat-GPT的CVE披露出來了，但是仔細一看原來是ChatGPT-Next-Web的漏洞。漏洞描述大致如下：（如果有自己搭建了還沒更新的速速修復升級防止被人利用，2.11.3已經出來了）

NextChat，也稱為 ChatGPT-Next-Web，是與 ChatGPT 一起使用的跨平臺聊天使用者介面。 2.11.2 及之前的版本容易受到伺服器端請求偽造和跨站點指令碼攻擊的影響。2024年3月，網際網路上披露CVE-2023-49785,攻擊者可在無需登陸的情況下構造惡意請求造成SSRF，造成敏感資訊洩漏等。

2. 漏洞分析

定位到漏洞程式碼：app/api/cors/[...path]/route.ts：

也就是大致如下內容：

import { NextRequest, NextResponse } from "next/server";
​
async function handle(
  req: NextRequest,
  { params }: { params: { path: string[] } },
) {
  if (req.method === "OPTIONS") {
    return NextResponse.json({ body: "OK" }, { status: 200 });
  }
​
  const [protocol, ...subpath] = params.path;
  const targetUrl = `${protocol}://${subpath.join("/")}`;
​
  const method = req.headers.get("method") ?? undefined;
  const shouldNotHaveBody = ["get", "head"].includes(
    method?.toLowerCase() ?? "",
  );
​
  const fetchOptions: RequestInit = {
    headers: {
      authorization: req.headers.get("authorization") ?? "",
    },
    body: shouldNotHaveBody ? null : req.body,
    method,
    // @ts-ignore
    duplex: "half",
  };
​
  const fetchResult = await fetch(targetUrl, fetchOptions);
​
  console.log("[Any Proxy]", targetUrl, {
    status: fetchResult.status,
    statusText: fetchResult.statusText,
  });
​
  return fetchResult;
}

在這段程式碼中，這裡沒有做任何的安全防護。params.path 是透過請求引數傳入的，這意味著使用者可以控制請求的路徑部分。這個路徑部分會被直接拼接到一個新的 URL 中，並在後續的程式碼中被用於發起請求，以繞過訪問控制、訪問內部系統或執行其他攻擊。

舉個例子，當你訪問 /api/cors/https/baidu.com 時，請求將被路由到這段程式碼中。在這裡，protocol 將被設定為 https，subpath 將被設定為 ['baidu.com']。然後，這兩部分將被拼接成 https://baidu.com，作為目標 URL。接下來，根據程式碼的邏輯，將會使用 fetch 發起一個對 https://baidu.com 的請求。這個請求的方法和請求體等資訊將根據原始請求中的資訊進行配置，然後將響應返回給客戶端。

我們驗證一下，果然存在。

image-20240315211855871

至於披露著所說的反射型XSS，則完全是因為這裡是用的fetch發包，fetch方法也支援 data 協議,且對後續的引數沒有過濾限制導致的，所以我們透過引數拼接如下即可實現：

/api/cors/data:text%2fhtml;base64,PHNjcmlwdD5hbGVydCgiQ1ZFLTIwMjMtNDk3ODUiKTwvc2NyaXB0Pg==%23

image-20240315213402621

3. 總結

沒想到一個64.5k star 的專案之前居然對SSRF一點防護都沒有做。

/api/cors 端點作為一個開放代理的設計，允許未經身份驗證的使用者透過它傳送任意的 HTTP 請求。這個端點似乎是為了支援將客戶端聊天資料儲存到 WebDAV 伺服器而新增的。

【----幫助網安學習，以下所有學習資料免費領！加vx：dctintin，備註 “部落格園” 獲取！】

　① 網安學習成長路徑思維導圖
　② 60+網安經典常用工具包
　③ 100+SRC漏洞分析報告
　④ 150+網安攻防實戰技術電子書
　⑤ 最權威CISSP 認證考試指南+題庫
　⑥ 超1800頁CTF實戰技巧手冊
　⑦ 最新網安大廠面試題合集（含答案）
　⑧ APP客戶端安全檢測指南（安卓+IOS）

我檢視了最新的原始碼：

image-20240315215107502

具體的官方修復思路如下：

  1. 移除開放代理端點：最終修復方案中，移除了原始的開放代理端點/api/cors。

  2. 替換為特定用途的端點：取而代之的是新增了兩個新的端點/api/upstash和/api/webdav，這些端點具有特定的用途，分別用於與 Upstash 和 WebDAV 服務進行整合。這種替換的方式限制了端點的功能範圍，並提供了更專門化的功能，有助於減少系統的安全風險。

  3. 增加安全驗證和限制：

    1. /api/upstash

      1. 限制目標URL：修復程式碼首先透過檢查請求引數中的endpoint來限制目標URL。它要求目標URL必須是以.upstash.io結尾的有效URL，這樣就限制了請求只能傳送到特定的Upstash服務。

      2. 限制請求方法：修復程式碼還對請求中的操作型別進行了限制。它只允許get和set兩種操作型別的請求，如果請求的操作型別不是這兩種之一，則會返回403 Forbidden響應。

    2. /api/webdav

      1. 請求方法限制： 修復程式碼只允許特定的HTTP請求方法，包括MKCOL、GET和PUT。對於其他不允許的請求方法，如POST等，會返回403 Forbidden響應。

      2. 目標路徑驗證： 修復程式碼對於不同的請求方法，會對目標路徑進行不同的驗證：

        • 對於MKCOL請求，只允許請求目標路徑為指定的folder，如果請求的目標路徑不是以指定的folder結尾，則返回403 Forbidden響應。

        • 對於GET請求，只允許請求目標路徑為指定的fileName，如果請求的目標路徑不是以指定的fileName結尾，則返回403 Forbidden響應。

        • 對於PUT請求，同樣只允許請求目標路徑為指定的fileName，如果請求的目標路徑不是以指定的fileName結尾，則返回403 Forbidden響應。

更多網安技能的線上實操練習，請點選這裡>>

相關文章