摘要

這份報告探討了在 IDIS Cloud Manager (ICM) Viewer 中發現的一個嚴重 1-click 遠端程式碼執行 (RCE) 漏洞 (CVE-2025-12556)。該漏洞源於命令中參數分隔符未被正確過濾,使攻擊者能夠逃逸瀏覽器沙箱,並在主機上執行任意程式碼。我們分析了其架構、驗證流程以及 Argument Injection 的技術機制。此外,透過與其他 IoT 漏洞的比較分析,突顯了不安全設計中的常見主題與緩解策略。


一場關於「參數」的入侵:揭密 IDIS IoT 設備的 1-Click 漏洞 | 資訊安全新聞

1. 簡介

隨著雲端驅動(cloud-powered)的管理、分析與偵測功能的出現,影像監控領域發生了巨大變化。這種轉變將傳統的在地端網路錄影機 (NVR) 與本機儲存解決方案,轉化為互連的雲端中心化環境。雖然這些進步提供了更高的安全性和營運效率,但也引入了新的攻擊面與複雜性,需要嚴格的安全審查。這份報告聚焦於 IDIS Cloud Manager (ICM) Viewer 中發現的一個重大漏洞,該程式是監控領域的知名解決方案。該漏洞編號為 CVE-2025-12556,允許一鍵啟動遠端程式碼執行 (RCE),藉由繞過瀏覽器沙箱並在主機系統上執行任意程式碼,構成了實質性風險 [1] 。這項研究深入探討了該漏洞的技術細節、其架構環境以及對雲端 IoT 安全的更廣泛影響。

2. 系統架構

IDIS 雲端生態系統包含 IDIS 雲端平台、攝影機與 NVR 等各種設備,以及提供桌面和行動平台的 ICM Viewer。我們的分析特別針對 Windows 作業系統上的桌面版 ICM Viewer (Web Client)。桌面版 IDIS Web Client 由兩個主要的獨立組件組成:

  • ICM Web Portal: 一個網頁介面,提供儀表板以管理與配置雲端連接的設備。
  • ICM Viewer: 一個僅限 Windows 的應用程式,負責即時監控、影片搜尋與備份功能。它具有基於 Chromium 的使用者介面。
  • CWGService.exe (ICMViewer Launcher): 一個作為本機接聽程式運作於 localhost:16140 的 Windows 服務。其主要功能是接收指令以啟動帶有特定參數的 ICM Viewer,包含用於授權的 JSON Web Token 和語言設定。

這些組件之間的互動對於理解該漏洞至關重要。ICM Web Portal 透過 WebSocket 連線與 CWGService.exe 通訊,藉此啟動 ICM Viewer。這個本機通訊管道是該漏洞利用的核心。

2.1. 架構圖

以下圖說明了 IDIS Cloud Manager 的高階架構,突顯了其關鍵組件之間的互動:




sequenceDiagram
actor User
participant WebPortal as ICM Web Portal
participant Browser as User's Browser
participant CWGService as CWGService.exe (localhost:16140)
participant WCMViewer as WCMViewer.exe (ICM Viewer)
participant IDISCloud as IDIS Cloud Platform


User->>WebPortal: Login (username, password)
WebPortal->>IDISCloud: Authenticate
IDISCloud-->>WebPortal: JWT Token, AES Key
User->>WebPortal: Click "Run Viewer"
WebPortal->>Browser: Initiate WebSocket connection to CWGService
Browser->>CWGService: WebSocket Connect (localhost:16140)
Browser->>CWGService: Encrypted Message (version check)
CWGService-->>Browser: Response (versions correct)
Browser->>CWGService: Encrypted Message (Launch WCMViewer command with JWT)
CWGService->>WCMViewer: Launch WCMViewer.exe with arguments (--url, --token, --mode, --language)
WCMViewer->>IDISCloud: Connect and Authorize (using JWT)
IDISCloud-->>WCMViewer: Video Feeds, Recordings
WCMViewer-->>User: Display Surveillance Data



3. 驗證與連線流程

使用者登入網頁入口網站並隨後啟動 ICM Viewer 的程序包含多個步驟,這對於理解攻擊向量至關重要 [1]

最初,使用者向 ICM Web Portal 提供認證。接著瀏覽器會產生一組 RSA 金鑰對,使用固定金鑰加密登入資料(使用者名稱、密碼、RSA 公鑰),並將其傳送到伺服器。驗證成功後,伺服器會回傳一個 AES 金鑰(以 RSA 公鑰加密)、一個用於與雲端伺服器通訊的加密 JWT Token,以及其他加密的帳戶資料。

通過驗證後,使用者可以存取儀表板來管理設備。若要觀看即時影像,使用者需點擊「執行 Viewer」按鈕。此動作會觸發網頁用戶端與接聽在 localhost:16140 CWGService.exe 建立 WebSocket 連線。網頁用戶端會傳送一則加密訊息,其中包含 CWGService 與 ICM Viewer 的預期版本。如果版本相容,網頁用戶端接著會傳送另一則加密訊息,即啟動 ICM Viewer 的命令。

透過 WebSocket 傳送以啟動 ICM Viewer 的解密訊息結構如下:

  1. OEM:1
  2. DATATYPE:2
  3. EXECUTECMD: {
  4. "title": "ICM Viewer",
  5. "url": "icm.idisglobal.com",
  6. "protocol": "https:",
  7. "serverAddress": "https://icm.idisglobal.com",
  8. "xAccessToken": "base64(JWT.Token)",
  9. "viewerMode": "LIVE",
  10. "viewerLanguage": "en-USA",
  11. "viewerHashX86": "B75...7D8",
  12. "viewerHashX64": "748...6E9"
  13. }

收到此訊息後, CWGService.exe 會執行 WCMViewer.exe ,並帶有直接從 WebSocket 訊息衍生的各種命令列參數。此執行指令的範例如下:

WCMViewer.exe --url="https://icm.idisglobal.com" --token=base64(JWT.Token) --mode=w --language=en-US

這個程序突顯了一個關鍵的設計選擇: --url --token 參數在未經充分過濾或驗證的情況下,幾乎直接從 WebSocket 訊息傳遞給 WCMViewer.exe 執行檔。這種將使用者控制的輸入直接映射到命令列參數的做法,構成了 Argument Injection 漏洞的基礎 [1]

4. CVE-2025-12556 技術分析

CVE-2025-12556 的問題核心在於用於啟動 WCMViewer.exe 的指令中,對參數分隔符號未被正確過濾。該漏洞允許攻擊者將任意命令列參數注入到 WCMViewer.exe 程序中,從而有效地達成遠端程式碼執行(Remote Code Execution, RCE) [1]

4.1. Argument Injection 機制

WCMViewer.exe 是採用 Chromium 架構的應用程式。。Chromium 應用程式通常支援廣泛的命令列參數,用於設定與除錯。藉由注入特定參數,攻擊者可以操控 Chromium 程序的行為。例如, --gpu-launcher 參數可能特別危險。這個參數允許指定一個外部程式作為 GPU 程序使用,從而有效地實現在攻擊者控制的參數下執行任意執行檔。

該漏洞之所以產生,是因為 CWGService.exe 在將 --url --token 參數連接成 WCMViewer.exe 的指令字串之前,未正確進行跳脫或驗證。攻擊者可以建構一個包含參數分隔符號(例如引號、空格或其他特殊字元)的惡意 URL 或 Token,以脫離原定的參數並注入新參數。例如,如果 --url 參數未被正確引用,攻擊者就可以注入一個新參數,如 --gpu-launcher="C:\Windows\System32\calc.exe"

4.2. 利用情境

攻擊者可以透過魚叉式網路釣魚攻擊利用此漏洞。受害者收到一個惡意連結,點擊後會與其本機 CWGService.exe 建立 WebSocket 連線。攻擊者控制的網站隨後會傳送一個特別製作的 WebSocket 訊息,其中包含惡意參數。例如,可以操控 EXECUTECMD JSON Payload 中的 url 欄位來注入 --gpu-launcher 參數,指向受害者系統上的執行檔,例如用於概念驗證的 calc.exe ,或用於完全入侵的更具威脅性的惡意 Payload。

考慮一個簡化的惡意 EXECUTECMD Payload 範例:

  1. OEM:1
  2. DATATYPE:2
  3. EXECUTECMD: {
  4. "title": "ICM Viewer",
  5. "url": "example.com" --gpu-launcher="C:\Windows\System32\calc.exe" --no-sandbox",
  6. "protocol": "https:",
  7. "serverAddress": "https://icm.idisglobal.com",
  8. "xAccessToken": "base64(JWT.Token)",
  9. "viewerMode": "LIVE",
  10. "viewerLanguage": "en-USA",
  11. "viewerHashX86": "B75...7D8",
  12. "viewerHashX64": "748...6E9"
  13. }

在此情境下,注入的 --gpu-launcher 參數會導致 WCMViewer.exe 啟動 calc.exe --no-sandbox 參數通常是必要的,以便允許注入的程序在沒有 Chromium 沙箱限制的情況下執行。這展示了看似無害的參數如何被武器化以達成 RCE,並繞過瀏覽器的安全機制 [1]

5. 與其他 IoT 漏洞的比較分析

IDIS IP 攝影機中的漏洞與其他 IoT 及應用程式安全缺陷具有共同的潛在原理,特別是與輸入驗證不當與行程間通訊(Inter-Process Communication,簡稱IPC)相關的缺陷。審查類似漏洞可為理解現代軟體開發中的系統性風險提供更廣泛的背景。

5.1. CEF 應用程式中的 CSS 注入

可將其與 CEF 應用程式中的 CSS 注入漏洞進行相關比較 [2] 。這個漏洞鏈展示了未經處理的設定檔案 ( gwd_workspace.json ) 如何導致 CSS 注入。注入的 CSS 隨後作為與內部應用程式 API 互動的管道,最終達成命令注入(Command Injection)與 RCE。關鍵教訓在於利用網頁技術 (CSS),透過暴露的內部 API 來操控底層系統功能。

CEF 應用程式中的 CSS 注入文章說明了惡意 CSS 如何被注入:

background-image: url("//ninja-shell/api/some_vulnerable_endpoint?param=malicious_command");

可以透過注入來強制 CEF 應用程式向內部 API 發出請求。這與 IDIS 漏洞類似,後者是注入惡意參數來操控 WCMViewer.exe 的執行。這兩個案例都突顯了對使用者控制的輸入進行不充分過濾的危險,這些輸入隨後會由具備權限的組件處理。

5.2. 工業網路設備中的命令注入

另一個相關的比較是在 Planet Technology 工業網路設備中發現的命令注入漏洞 (CVE-2025-46272) [3] 。由於 dispatcher.cgi 二進位檔案中缺乏輸入過濾,該漏洞允許在驗證後進行命令注入。具體而言,traceroute 功能中的 ip_URL 參數存在漏洞,使攻擊者能夠注入任意命令。

來自 Planet Technology 設備的漏洞程式碼片段(為說明而簡化)為:

  1. void trace_route() {
  2. char ip[64];
  3. snprintf(ip, sizeof(ip), "traceroute %s", get_param("ip_URL"));
  4. system(ip); // Vulnerable to command injection
  5. }

這與 IDIS 漏洞直接相呼應:兩者都涉及應用程式使用未經處理的使用者輸入來建構系統指令。在 IDIS 案例中,它是執行檔的命令列參數;在 Planet Technology 案例中,它是 shell 指令。根本缺陷是相同的:在輸入可以改變程式執行的環境下信任使用者輸入。這些範例強調了在從桌面應用程式到嵌入式 IoT 設備的各種技術環境中,輸入驗證問題的普遍性。

6. 緩解措施與安全最佳實踐

解決像 CVE-2025-12556 這樣的漏洞需要多方面的途徑,將立即修補與軟體開發及部署中的長期安全最佳實踐相結合。

6.1. 修補與版本更新

最直接且關鍵的緩解措施是套用廠商提供的更新程式。IDIS 已發布 ICM Viewer 的更新版本 (v1.7.1) 以解決此漏洞。強烈建議使用者將其設備升級到此版本,或者如果無法升級,應立即解除安裝 ICM Viewer [1] 。定期進行軟體更新對於維持任何系統的安全態勢至關重要,尤其是那些連接到網際網路的系統。

6.2. 強健的輸入驗證與過濾

Argument Injection 與命令注入漏洞的根源通常是輸入驗證不足。所有使用者提供的輸入,無論是來自網頁表單、API 呼叫還是行程間通訊,在用於系統命令、檔案路徑或其他敏感環境之前,都必須經過嚴格的驗證與過濾。這包括:

  • 白名單: 僅允許已知的良性字元或模式。
  • 跳脫 (Escaping): 對可能被解釋為指令分隔符號或參數分隔符號的特殊字元進行適當跳脫。
  • 引用 (Quoting): 確保傳遞給執行檔的參數被正確引用,以防止注入額外參數。
  • 類型檢查: 驗證輸入是否符合預期的資料類型與長度。

開發人員應採取縱深防禦策略,在應用程式的多個層級套用驗證。

6.3. 安全的行程間通訊 (IPC)

在設計涉及行程間通訊的系統時,特別是在權限較低的組件與權限較高的組件(例如網頁用戶端與本機服務)之間,開發人員必須優先考慮安全性。這包括:

  • 最小權限原則: 確保每個組件以必要的最小權限運作。
  • 安全通訊管道: 為 IPC 使用加密且經過驗證的管道。
  • 嚴格的訊息驗證: 對行程間交換的所有訊息實施全面的驗證,類似於對外部輸入的輸入驗證。
  • 減少攻擊面: 盡量減少暴露的 API 與功能,特別是那些與底層作業系統互動的功能。

對於使用 Chromium 架構的應用程式,應仔細考慮命令列參數的使用,特別是那些可以啟動外部程序或修改安全設定的參數。應優先考慮使用具有結構化資料格式(例如具有 Schema 驗證的 JSON)的 IPC 機制,而非從不信任的輸入直接建構命令列參數。

7. 結論

IDIS Cloud Manager Viewer 中的 CVE-2025-12556 漏洞提醒我們,在保護複雜且互連的系統方面存在著持久的挑戰。物聯網裝置雲端化的過程雖然提供了許多優勢,但同時也引入了新的架構模式,這些模式可能在不經意間形成新的攻擊向量。透過 Argument Injection 達成的 1-click RCE 強調了細緻的輸入驗證與安全的行程間通訊設計的極端重要性,即使是對於看似內部或本機的互動也是如此。

這項研究突顯了漏洞通常源於基礎的安全失誤,例如在命令執行環境中對使用者控制的資料處理不當。與其他 IoT 漏洞(包含 CEF 應用程式中的 CSS 注入與工業網路設備中的命令注入)的比較分析揭示了一個共同點:未能預見並緩解會影響系統行為的輸入惡意操控。隨著 IoT 版圖持續擴大,採取包含強健開發實踐、持續漏洞研究與及時修補的主動且全面的安全方法,對於保護這些關鍵基礎設施免受演進中威脅的侵害至關重要。