摘要 (Abstract)

本報告詳細介紹了對一個廣泛使用的防毒產品中所發現的本機權限提升 (LPE) 漏洞的技術分析，該漏洞被識別為 CVE-2024-36424 [1] 。該漏洞源於透過 named pipes 進行的程序間通訊處理不當，允許低權限使用者觸發高權限操作，特別是註冊檔竄改，最終導致 SYSTEM 等級的程式碼執行。本分析著重於攻擊手法，包括二進位協定濫用和使用 Image File Execution Options (IFEO) 技術，以及隨後對更新程式的繞過。

SYSTEM 權限奪取！剖析 K7 Antivirus 弱點：從 named-pipe 到 IFEO 註冊檔攻擊鏈 | 資訊安全新聞

1. 簡介 (Introduction)

防毒和其他安全軟體的核心元件通常會以提升的權限（例如 SYSTEM ）執行，以執行必要的全系統操作。為了讓使用者層級的應用程式能與這些高權限服務互動，通常會採用 named-pipe 等機制。然而，對透過這些 pipe 進行通訊的客戶端程序如果缺乏充分的驗證，可能會引入嚴重的安全漏洞。此處討論的漏洞影響 K7 Ultimate Security，即為此類設計缺陷的一個典型範例。最初的發現側重於識別具有寬鬆存取控制列表 (Access Control Lists, ACLs) 且正被 SYSTEM 層級服務使用的 named-pipe [1] 。

2. 漏洞發現與 named-pipe 濫用

該漏洞的核心在於 K7TSMngr.exe 服務，它以 SYSTEM 執行並公開了一個 named-pipe： \\.\pipe\K7TSMngrService1 。使用像 pipeviewer 這樣的工具進行初步檢查顯示，這個 pipe 的 ACLs 過於寬鬆，使得非特權使用者也能夠存取。

關鍵的觀察是在監控高權限使用者更改特定設定時所做的—允許非管理員使用者修改防毒設定。此操作由使用者層級程序 K7TSMain.exe 執行，導致二進位封包被發送到 K7TSMngrService1 pipe。該封包指示 SYSTEM 服務修改一個註冊檔 key ，特別是在防毒的設定更新中將 AdminNonAdminIsValid 設為 1 。

通訊流可以視覺化如下：

graph TD A[Low-Privilege Process:
K7TSMain.exe] -->|Sends Binary Packet| B(Named Pipe:
\\.\pipe\K7TSMngrService1); B --> C[SYSTEM Service:
K7TSMngr.exe]; C --> D[Registry Write Operation:
Set:
AdminNonAdminIsValid=1];

透過觀察在合法設定更改期間發送的資料，對二進位封包的結構進行了逆向工程。該封包包含一個長度欄位、一個命令識別符，以及要修改的註冊檔 key/Value pair。至關重要的是，服務沒有正確驗證封包的來源，也沒有嚴格驗證正在修改的註冊檔 key，從而允許低權限使用者以某種形式執行任意註冊檔寫入操作 [1] 。

3. 本機權限提升 (LPE) 的利用

即使對 key 長度有所限制，能夠竄改任意註冊檔 key 的能力也為 LPE 提供了強大的原始功能。選擇用於提升權限的技術是 Image File Execution Options (IFEO) Debugger key。

IFEO 機制允許使用者指定一個「Debugger」程序，每當啟動原始應用程式時，就會執行該程序來替代原始應用程式。透過鎖定一個已知由 SYSTEM 服務執行的程序，攻擊者可以劫持 (hijacking) 執行流程。

識別出的目標程序是 K7TSHlpr.exe ，它在防毒觸發的更新程序期間以 SYSTEM 權限執行。攻擊者製作一個 malicious payload 來修改以下註冊檔 key： 

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\K7TSHlpr.exe

該 Payload 將 Debugger 值設定為執行惡意批次檔的命令，例如： "Debugger"="cmd.exe /c C:\\temp\\foobar.bat" 。

攻擊程序涉及兩個主要步驟：

  1. 註冊檔竄改： 發送一個特別製作的二進位封包到 named-pipe，以設定 IFEO Debugger key。
  2. 觸發執行： 在防毒中啟動一個動作（例如，更新），導致 SYSTEM 服務啟動 K7TSHlpr.exe ，進而以 SYSTEM 權限執行攻擊者的腳本。

用於建構和發送 malicious payload 的 PowerShell 腳本結構至關重要。它涉及計算正確的封包長度，並將目標註冊檔 key/value 編碼成 named-pipe 伺服器所期望的二進位格式。

以下是 Payload 建構邏輯的概念性表示 [1] ： 

  1. # Conceptual PowerShell Payload Construction
  2. # The payload prefix contains the command and a length field (offset 20)
  3. $payload_prefix = [byte[]](
  4.     0x53,0x54,0x37,0x4b,0x10,0x10,0x00,0x00,0x1c,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
  5.     0x44,0x00,0x01,0x00,0xb8,0x00,0x00,0x00,0x00,0x00,0x00,0x00
  6. )
  8. # Target registry key for IFEO
  9. $key = '[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\K7TSHlpr.exe]'
  10. $key_bytes = [System.Text.Encoding]::ASCII.GetBytes($key)
  12. # Target registry value (Debugger command)
  13. $reg_value = '"Debugger"="cmd.exe /c C:\\temp\\foobar.bat"'
  14. $payload_suffix = [byte[]](0x0d,0x0a) + 
  15.     [System.Text.Encoding]::ASCII.GetBytes($reg_value) + 
  16.     [byte[]](0x0d,0x0a,0x0d,0x0a,0x00)
  18. # Combine parts
  19. $payload = $payload_prefix + $key_bytes + $payload_suffix
  21. # Calculate and fix the size field in the prefix (offset 20)
  22. $reg_block_len = $key_bytes.Length + $payload_suffix.Length
  23. $payload[20] = [byte]$reg_block_len
  25. # Send $payload to the named pipe
  26. # ...

此程式碼片段說明了繞過伺服器內部檢查所需的精確位元組層級竄改，這些檢查被發現是基於封包長度而非內容驗證。在 prefix 中 offset 20 位置的數值 0xb8（十進位 184）為預留的 placeholder，需更新為實際的 key 與 value 區塊長度。

4. 更新程式分析與繞過技術

該漏洞經過多次更新，但每次更新隨後都被繞過，突顯了確保複雜程序間通訊安全的難度。

4.1 更新程式 1：呼叫者驗證繞過

第一個更新程式試圖實作 呼叫者驗證 ，限制哪些程序可以發送命令到 named-pipe K7TSMngrService1 。這阻止了任意程序（例如一個簡單的 PowerShell 腳本）與服務通訊。

繞過涉及一種稱為 manual mapping 的技術 [1] 。攻擊者沒有嘗試從外部、未經驗證的程序進行通訊，而是將惡意的 DLL 直接注入到一個合法、經過驗證的程序 ( k7tsmngr.exe ) 中。透過手動將 DLL 映射到目標程序的記憶體空間，攻擊者可以在受信任的 Context 中執行程式碼，有效地繞過呼叫者驗證檢查。然後，被注入的程式碼可以禁用防毒的自我保護功能，並像以前一樣進行 LPE 利用。

4.2 更新程式 2：程序保護繞過

在第一次繞過之後，引入了一個新的驅動程式 ( k7sentry ) 來實作 程序保護 ，可能為了防止像 manual mapping 這樣的記憶體注入技術。該驅動程式用於監控和保護關鍵的防毒程序。

第二次繞過鎖定在驅動程式實作中的一個漏洞。發現驅動程式的保護機制對於某些程序竄改方法無效。研究人員發現並非所有K7可執行檔都在受保護清單中。攻擊者使用未受保護的K7簽章二進位（如K7QuervarCleaningTool.exe）作為 manual mapping 的目標。由於這些程序未被驅動程式保護，注入仍然可以成功。 [1] 。

4.3 更新程式 3：更全面的驗證機制

  1. 路徑驗證：檢查客戶端二進位檔案是否位於官方K7安裝目錄中
  2. 數位簽章驗證：驗證客戶端二進位檔案是否由K7 Computing正確簽章
  3. 驅動程式保護驗證：透過檢查登錄項目 HKLM\SYSTEM\CurrentControlSet\Services\K7Sentry\Config\VDefProtectedProcs 確認程序是否受驅動程式保護

最終繞過方法： 將任何K7數位簽章的二進位檔案複製到使用者控制的目錄（如桌面）並重新命名。<該二進位檔> ：

  1. 透過數位簽章驗證（因為是合法的K7簽章檔案）
  2. 無法通過路徑驗證（不在官方安裝目錄）
  3. 但關鍵的是，由於不在官方目錄，它通常也不在驅動程式的保護程序清單中

這使得修改後的二進位檔案既滿足簽章要求，又不受驅動程式保護，從而可再次用於 manual mapping 和 pipe communication attacks。

根本問題：所有更新程式都未能解決核心問題－高權限服務過度信任來自低完整性流程的輸入。更新側重於驗證客戶端身份而非驗證請求本身的合法性和安全性。

5. 結論

K7 Ultimate Security 中的 CVE-2024-36424 漏洞是根源於不安全程序間通訊的 LPE 缺陷的一個經典範例。從 named-pipe 發現和二進位協定濫用到透過 IFEO 進行註冊檔竄改的利用鏈，展示了一個複雜的攻擊途徑。隨後的更新和繞過循環強調了特權服務中強固安全設計的關鍵需求，包括：

  • 嚴格的 ACLs： named pipes 和其他 IPC 機制應採用最小權限原則。
  • 輸入驗證： 透過 IPC 通道接收的所有資料，特別是二進位協定，必須對格式和內容進行嚴格驗證，而不僅僅是長度。
  • 環境驗證： 特權服務必須對呼叫程序的身份和完整性執行強大的驗證，並且這種驗證必須能夠抵抗記憶體注入和程序模擬技術。

對此漏洞的分析為安全軟體開發的常見陷阱以及攻擊者用於實現系統層級入侵的進階技術提供了寶貴的見解。

參考文獻 (References)

  1. K7 Antivirus: named-pipe abuse, registry manipulation and privilege escalation