簡介
現代的企業管理解決方案通常優先考慮易用性與無縫部署,有時會以犧牲嚴格的安全邊界為代價。本研究探討了 Dell Wyse Management Suite (WMS) 中的一個關鍵漏洞鏈,特別聚焦於其在地端部署版本。透過利用業務邏輯缺陷與不當的存取控制,未經驗證的攻擊者可以達成完全的 遠端程式碼執行 (Remote Code Execution, RCE) 。這份報告分析了此漏洞攻擊鏈的技術組成,重點說明了從低權限的設備立足點轉向管理員權限接管與系統入侵的過程 [1] 。
1. 立足點:未經驗證的設備註冊
初始的進入點涉及設備註冊機制。在 WMS 的地端版本中,預設設定允許設備在沒有有效群組 token 的情況下進行註冊。這種目的在簡化初始設定的設計選擇,卻造成了重大的安全缺口。當一個帶有空 token 的註冊請求被發送時,系統會將設備放入「隔離」群組,而不是拒絕該請求 [1] 。這個行為是「預設開放(fail-open)」邏輯的典型例子,即認證的缺失導致了一個預設狀態,該狀態仍然授予某種程度的系統存取權限。
- /*
- * Simplified representation of the device registration logic
- * Path: com.dell.stratus.controller.DeviceController
- */
- @RequestMapping(...)
- @ResponseBody
- public Person deviceGroupLogin2(@RequestBody GroupToken token, HttpServletRequest req, HttpServletResponse response) {
- // If group token is empty, the system checks if it is an On-prem version
- if (token == null || token.getGroupToken() == null || token.getGroupToken().isEmpty()) {
- if (!this.publicCloud) { // [1] On-prem check
- List<TenantEntity> tenants = this.tenantDao.getAllActiveTenants();
- // Default installation typically has 2 tenants
- if (tenants.size() == 2) {
- for (TenantEntity tenant : tenants) {
- if (!tenant.isSuperTenant()) {
- // [4] Device is assigned to the Quarantine group
- userGroup = this.userGroupDao.QuarantineGroupAndUserByTenant(tenant.getId());
- }
- }
- }
- }
- }
- // Returns wyseIdentifier and authenticationCode for further signed requests
- return this.deviceGroupLoginInternal(token, req, response);
- }
成功註冊後,攻擊者會收到一個
wyseIdentifier
和一個
authenticationCode
。這些認證允許攻擊者簽署後續的 API 請求,有效地偽裝成受管理的設備。雖然一個被隔離的設備應該只有有限的存取權限,但 WMS 向設備開放的 API 介面卻異常廣泛。這個初步的立足點至關重要,因為它將一個外部的、未經驗證的攻擊者,轉變為內部的「受信任」設備實體,從而繞過了可能僅檢查未經驗證流量的邊界防禦
[1]
。
2. 利用邏輯缺陷進行權限提升
攻擊的第二階段利用設備簽署的請求來與管理端點互動,這些端點未能正確執行基於角色導向的存取控制 (Role-Based Access Control, RBAC)。具體來說,與 Active Directory (AD) 整合相關的端點,仍然對任何已註冊的設備開放。這是一個典型的 CWE-288:使用替代路徑或通道繞過驗證(Authentication Bypass Using an Alternate Path or Channel) 的例子,其中原本為管理員設計的功能,透過不同的介面暴露了出來 [2] 。該漏洞的根本原因在於,後端在處理與 AD 相關的命令時,只要請求是由已註冊設備加密簽署的,就不會驗證請求者是否具有管理員權限。
攻擊者可以串聯三個特定的 API 呼叫來建立一個新的管理員帳號:
-
importADUserGroups:在 WMS 資料庫中建立一個新的角色群組。該群組作為權限的容器。 -
addRoleToADGroup:將高權限的「Admin」角色指派給新建立的群組。這是權限提升的核心,因為它授予了對 WMS 實例的完全控制權。 -
importADUsers:匯入一個虛擬使用者並將其指派給惡意群組。系統在下次登入時會將此使用者視為合法的管理員。
雖然匯入的使用者密碼是隨機生成的,但攻擊者可以利用密碼重設機制中的一個漏洞來繞過登入屏障。當 WMS 試圖阻止對 AD 使用者進行密碼重設時,可以透過操縱使用者的 metadata 或在啟用 SMTP 設定的情況下利用 SMTP 來繞過檢查 [1] 。這突顯了透過未經驗證的輸入「污染」系統狀態的危險性,類似於在其他企業平台中看到的漏洞攻擊鏈,其中初始的低階存取權限被用來操縱後端設定 [3] 。從設備層級的存取點建立一個管理員帳號的能力,代表了安全模型的完全崩潰。
3. 達成遠端程式碼執行
一旦獲得管理員存取權限 (CVE-2026-22765),攻擊者就可以利用第二個漏洞 (CVE-2026-22766) 來達成 RCE。WMS 儀表板允許管理員管理檔案儲存庫,這些儲存庫用於儲存精簡型用戶端的韌體和設定檔。在儲存庫管理模組中,檔案上傳和路徑處理邏輯存在一個關鍵漏洞。透過操縱儲存庫路徑或在檔案同步期間利用目錄操縱,攻擊者可以將一個惡意的 JavaServer Pages (JSP) shell 上傳到一個可透過網頁存取的目錄中 [1] 。
- /*
- * Simplified representation of the device registration logic
- * Path: com.dell.stratus.controller.DeviceController
- */
- @RequestMapping(...)
- @ResponseBody
- public Person deviceGroupLogin2(@RequestBody GroupToken token, HttpServletRequest req, HttpServletResponse response) {
- // If group token is empty, the system checks if it is an On-prem version
- if (token == null || token.getGroupToken() == null || token.getGroupToken().isEmpty()) {
- if (!this.publicCloud) { // [1] On-prem check
- List<TenantEntity> tenants = this.tenantDao.getAllActiveTenants();
- // Default installation typically has 2 tenants
- if (tenants.size() == 2) {
- for (TenantEntity tenant : tenants) {
- if (!tenant.isSuperTenant()) {
- // [4] Device is assigned to the Quarantine group
- userGroup = this.userGroupDao.QuarantineGroupAndUserByTenant(tenant.getId());
- }
- }
- }
- }
- }
- // Returns wyseIdentifier and authenticationCode for further signed requests
- return this.deviceGroupLoginInternal(token, req, response);
- }
在將儲存庫路徑重新導向到 Tomcat 網頁根目錄中的某個位置後,攻擊者執行檔案上傳。系統將「儲存庫」檔案同步到新路徑,有效地將 JSP shell 放置在一個可以由網頁伺服器執行的位置。這種利用管理員檔案管理功能來獲得程式碼執行的模式,是複雜漏洞攻擊鏈中的常見主題,其最後一步通常涉及逃脫應用程式的預期檔案邊界 [4] 。執行 JSP shell 後,攻擊者將獲得運行 WMS 的服務帳號權限,該帳號通常是一個高權限的系統帳號。
4. 深入探討漏洞攻擊鏈的運作機制
此次攻擊的有效性在於其「邏輯鏈」,而非單一的記憶體損壞錯誤。鏈中的每一步都是一個邏輯操作,雖然單獨看來似乎無害,但共同導致了整個系統的淪陷。從設備註冊到 AD 使用者匯入的轉變尤其值得注意,因為它連接了兩個不同的信任領域:設備管理領域和使用者身分領域。在一個安全的架構中,這些領域應該被嚴格隔離。然而,在 WMS 中,共享的 API 後端允許一個設備影響使用者層級的權限 [1] 。
此外,檔案儲存庫漏洞顯示了「深度防禦(Defense in depth)」的失效。即使攻擊者獲得了管理員存取權限,應用程式也不應該允許修改關鍵系統路徑或將可執行檔案上傳到網頁根目錄。缺乏路徑清理以及賦予儲存庫管理模組過於廣泛的權限,是導致 RCE 的主要因素。這讓人想起在其他網路管理系統中發現的漏洞,其中管理員的「功能」被重新用於惡意目的 [4] 。
5. 技術總結與緩解措施
下表總結了未經驗證 RCE 鏈中所涉及的漏洞:
| 漏洞 ID | 組件 | 影響 | 技術根本原因 |
|---|---|---|---|
| CVE-2026-22765 | API 存取控制 | 權限提升 | 對於設備簽署的請求,AD 相關端點上的 RBAC 不當。 |
| CVE-2026-22766 | 儲存庫管理 | 遠端程式碼執行 | 不安全的檔案路徑處理,允許將 JSP shell 上傳到網頁根目錄。 |
| 邏輯缺陷 | 設備註冊 | 初始立足點 | 在地端安裝中,預設允許空的群組 token。 |
為了降低這些風險,組織應確保將 WMS 更新到最新版本,使這些端點受到適當的限制。此外,停用「允許空 token」功能,並對 WMS 伺服器實施嚴格的出口過濾,可以在多個階段中斷漏洞攻擊鏈。該研究強調,即使是「次要」的錯誤,例如過於寬鬆的註冊政策,在與其他邏輯缺陷結合時,也可能成為毀滅性攻擊的基礎 [1] [5] 。管理員也應監控對 AD 相關端點的異常 API 呼叫以及對儲存庫路徑的未經授權更改,因為這些都是強烈的入侵指標。