摘要

本報告針對在 v32.7.4.0 版本之前的 Imunify360 Antivirus (AV) 元件（特別是 AI-bolit 惡意軟體掃描器）中發現的一個嚴重遠端程式碼執行 (RCE) 漏洞，提供技術分析 [1]。該漏洞源於解混淆邏輯的設計缺陷，它會執行從攻擊者提供的 malicious payload 中提取出的不可信任函式名稱和 Payload。這個缺陷允許 Threat actor 注入經過混淆的 PHP 碼，當被掃描時，它會強制解混淆器執行危險的 PHP 函式，例如 system 或 eval ，導致任意指令執行。本報告詳述了兩種主要的攻擊途徑：檔案掃描器和資料庫掃描器，並分析了供應商的更新程式，該更新程式引入了一個關鍵的白名單式驗證機制來降低風險。

防毒軟體自爆？Imunify360 AV 解混淆邏輯 RCE 漏洞的內部運作分析 | 資訊安全新聞

1. 簡介

Imunify360 是一個廣泛部署於網站代管（web hosting）環境中的資安解決方案，提供針對各種威脅（包括惡意軟體）的防護。AI-bolit 元件是一個專門的惡意軟體掃描器，目的在偵測和清理與網站相關的檔案。在這個元件中發現了一個嚴重的 RCE 漏洞，對其應當保護的代管環境的完整性構成了重大風險 [1]。該漏洞的嚴重性因掃描器通常以提升的權限執行而具有權限升級的潛力，以及透過資料庫掃描器途徑的利用 Ease （容易度）而更加凸顯。

2. 技術漏洞分析

2.1. 根本原因：不安全的解混淆邏輯

該漏洞的核心在於 AI-bolit 掃描器嘗試對惡意 PHP 程式碼進行解混淆的過程。惡意軟體作者經常使用混淆技術——例如十六進位逸出 ( hex escapes )、base64/gzinflate 鏈和自訂轉換——來規避靜態簽章型掃描器的偵測 [1]。為了應對此情況，AI-bolit 包含了啟發式方法 ( heuristics ) 和解混淆器。然而，解混淆程序存在缺陷，允許執行從混淆輸入中還原出來的不可信任函式名稱和 Payload [1]。

原始文章強調了兩種有問題的流程，這些流程依賴於 Helpers::executeWrapper 函式，該函式內部使用了 call_user_func_array 且未進行適當的驗證 [1]。如果攻擊者控制的 Payload 包含危險 PHP 函式的名稱（例如， system 、 exec 、 eval ），解混淆器將會以攻擊者控制的引數來執行它，從而導致 RCE [1]。

2.1.1. 攻擊機制

該漏洞的利用取決於掃描器識別和執行一系列函式以反轉混淆的能力。malicious payload 被精心製作，以模仿掃描器設計用來處理的合法混淆結構。舉例來說，該漏洞可能由從十六進位編碼字串中還原函式名稱，然後立即用十六進位編碼引數執行它們的模式所觸發。這是一種 Payload 混淆形式，惡意意圖被隱藏起來，直到被資安工具本身執行的那一刻 [3]。

一個脆弱解混淆流程的簡化表示可以透過下圖進行視覺化：

graph TD A[Malware Scan Initiated] --> B{Obfuscated Payload Detected?}; B -- Yes --> C[Start Deobfuscation Process]; C --> D["Extract Function Name (e.g., \x73\x79\x73\x74\x65\x6d)"]; D --> E["Extract Payload/Arguments (e.g., \x74\x6f\x75\x63\x68...)"]; E --> F{Call Helpers::executeWrapper}; F -- No Validation --> G["Execute Untrusted Function (e.g., system)"]; G --> H[Remote Code Execution]; H --> I[Compromise]; B -- No --> J[Clean];

原始文章中提供的概念性驗證 ( PoC ) 程式碼展示了這個機制，其中十六進位編碼字串被用來表示函式 system 及其引數，這些引數執行一個 shell 指令，在 /tmp 中創建一個檔案 [1]。

十六進位編碼的函式名稱 \x73\x79\x73\x74\x65\x6d 解碼為 system ，而十六進位編碼的引數字串解碼為 touch /tmp/l33t.txt && echo "DEF-36789" > /tmp/l33t.txt 。解混淆器在嘗試清理檔案時，執行了 Payload： 

  1. <?php
  2. $data = "test";
  4. // \x73\x79\x73\x74\x65\x6d decodes to 'system'
  5. // The argument string decodes to 'touch /tmp/l33t.txt && echo "DEF-36789" > /tmp/l33t.666.txt'
  6. $payload = "\x73\x79\x73\x74\x65\x6d"("\x74\x6f\x75\x63\x68\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74\x20\x26\x26\x20\x65\x63\x68\x6f\x20\x22\x44\x45\x46\x2d\x33\x36\x37\x38\x39\x22\x20\x3e\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74");
  8. // This line is part of the PoC to ensure the scanner attempts to process the payload
  9. // \x70\x61\x63\x6b decodes to 'pack'
  10. eval("\x70\x61\x63\x6b"($payload));
  11. ?>

2.2. 攻擊途徑

最初，該漏洞被認為僅限於檔案掃描器，需要攻擊者植入惡意檔案 [1]。然而，隨後的更新揭示了一個更為關鍵的途徑：資料庫掃描器（ imunify_dbscan.php ） [1]。

資料庫掃描器途徑顯著降低了攻擊的門檻：

  • 不需上傳檔案： Threat actors 不需要上傳任何惡意軟體檔案 [1]。
  • 輕易的資料注入： malicious payload 可以透過常見、通常無需驗證的網頁應用程式功能（例如留言表單、聯絡表單或搜尋紀錄）注入到資料庫中 [1]。
  • 自動執行： 當 Imunify360 執行其例行資料庫掃描時，malicious payload 會直接從資料庫中取出並傳遞給脆弱的解混淆函式，導致 RCE [1]。

這第二個途徑在共享主機環境中特別危險，因為對於低權限使用者或透過網頁應用程式的未經驗證 Threat actor 來說，寫入資料庫通常是一個輕易的能力 [1]。

2.3. 預設設定的影響

雖然 AI-bolit PHP CLI 工具看起來預設會停用深度解混淆，但 Imunify360 實際使用的包裝程式 ( wrapper )（ ./imav/malwarelib/scan/ai_bolit/scanner.py ）被發現會 始終啟用 --deobfuscate 選項 [1]。這個關鍵的設定細節意味著所有掃描類型——背景、 on-demand 、使用者發起和快速帳號掃描——預設都是脆弱的，這提升了問題的嚴重性 [1]。

來自 scanner.py 的相關 Python 程式碼片段顯示了 hardcoded 的 --deobfuscate 旗標： 

  1. def _cmd(
  2.       self,
  3.       filename,
  4.       intensity_ram,
  5.       progress_path,
  6.       *,
  7.       scan_type: str,
  8.       # ... parameters ...
  9.   ):
  10.       cmd = [
  11.           "/opt/ai-bolit/wrapper",
  12.           AIBOLIT_PATH,
  13.           "--smart",
  14.           "--deobfuscate",  # ALWAYS ENABLED!
  15.           "--avdb",
  16.           MalwareSignatures.AI_BOLIT_HOSTER,
  17.           # ...
  18.       ]

3. 緩解與更新程式分析

3.1. 供應商的更新程式

修復此漏洞的正確方法是確保解混淆是以純粹的語法方式執行，而不會執行任何還原的函式 [1]。供應商的更新程式 (DEF-36789) 透過在執行任何發現的函式之前引入驗證白名單來解決這個問題 [1]。

該更新程式實作了一個函式 isSafeFunc ，它嚴格限制解混淆器被允許執行的函式，僅限於一組純粹的解碼和確定性函式。這是一個關鍵的資安控制，從隱性信任模型轉變為顯性允許列表模型。

白名單中的函式旨在只執行解混淆所需的 Safe string manipulations （安全的字串操作），例如解碼、取消逸出(unescaping)和反轉字串。它們不包含任何能夠進行檔案系統存取、網路通訊或任意程式執行的函式。 

  1. public static function isSafeFunc($func) {
  2.     $safeFuncs = [
  3.         'base64_decode', // Safe for decoding
  4.         'gzinflate',     // Safe for decompression
  5.         'strrev',        // Safe for string reversal
  6.         'str_rot13',     // Safe for ROT13 decoding
  7.         'urldecode',     // Safe for URL decoding
  8.         'substr',        // Safe for substring extraction
  9.         'chr',           // Safe for character conversion
  10.         'ord',           // Safe for character to ASCII conversion
  11.     ];
  12.     return in_array(strtolower($func), $safeFuncs, true);
  13. }

3.2. 縱深防禦：白名單方法

白名單方法是針對此類漏洞的強大 Defense-in-Depth （縱深防禦）措施。透過將執行 Environment （環境）限制在僅已知的安全函式，該更新程式有效地消除了 RCE 風險。即使 Threat actor 成功注入了一個能夠還原出危險函式名稱（例如 system ）的 Payload， isSafeFunc 檢查也會阻止其執行。這是一個根本性的轉變，從依賴複雜的啟發式方法來偵測惡意意圖，轉變為在分析階段對可執行的程式碼實施嚴格的 Policy （政策）。

這種緩解策略直接與惡意軟體分析的一般挑戰有關，在惡意軟體分析中，混淆技術不斷發展 [2]。例如，進階混淆通常涉及多層編碼和動態函式呼叫，以隱藏最終的 Payload 。Imunify360 更新程式確保只允許執行 Safe reversal （安全反轉）這些編碼層所必需的函式，防止掃描器本身成為惡意軟體的執行引擎。

4. 結論

Imunify360 AV (AI-bolit) 中的遠端程式碼執行漏洞是一個嚴重缺陷，其 CVSS 評分為 8.2，使網站代管環境暴露於完全被 Compromise （危害）的風險 [1]。根本原因是在解混淆程序中不安全地執行了不可信任的程式碼，這是建立必須處理惡意輸入的資安工具時常見的 Pitfall （陷阱）。該漏洞因預設 Configuration （設定）始終啟用脆弱的解混淆邏輯，以及發現了一個低摩擦的資料庫掃描器攻擊途徑而更為複雜。

供應商的更新程式實施了安全的解碼函式嚴格白名單，代表了針對此問題的正確且可靠的技術解決方案。它是一個有價值的安全軟體開發 Case study （案例研究），突顯了輸入驗證和最小權限原則的必要性，即使在資安工具本身內也是如此。資安軟體開發人員必須深刻意識到，他們的工具由於其處理惡意輸入的性質，如果沒有得到嚴格的保護，可能會成為高價值利用的目標。

參考文獻

  1. Critical: Remote Code Execution via Malicious Obfuscated Malware in Imunify360 AV (AI-bolit)
  2. 深入 SLOW#TEMPEST：惡意軟體混淆如何挑戰你的資安思維
  3. 從 URL 編碼到 Unicode 混淆：資安專家必懂 Payload 隱藏術