ImunifyAVのAI-bolitにRCE脆弱性、Linux共有ホスティング数千万サイトに影響

Source:https://www.bleepingcomputer.com/news/security/rce-flaw-in-imunifyav-puts-millions-of-linux-hosted-sites-at-risk/

🛡 概要

Linuxホスティングで広く使われるマルウェアスキャナ「ImunifyAV/ImunifyAV+/Imunify360」に含まれるAI-bolitコンポーネント（32.7.4.0未満）に、リモートコード実行（RCE）の重大な脆弱性が判明しました。CloudLinuxは2024年10月下旬に修正を公開し、11月10日にはImunify360向けに修正を後方移植しています。現時点でCVEなどの識別子やCVSSは未割り当てですが、ベンダは「クリティカル」として速やかなアップデート（32.7.4.0以降）を強く推奨しています。Imunifyは共有ホスティング、マネージドWordPress、cPanel/WHMやPlesk環境で一般的に導入され、同社公開値では5,600万サイトの背後で稼働しています。適用が遅れると、サイト全体の侵害や共有環境での横展開、場合によってはサーバ乗っ取りに繋がる恐れがあります。

🔍 技術詳細

脆弱性の根本原因は、AI-bolitが難読化されたPHPファイルを展開（デオブファスケーション）する際のロジックにあります。具体的には、難読化コードから抽出した関数名や引数を検証せずにcall_user_func_arrayで実行しており、攻撃者が制御可能な関数名を差し込むことで、system/exec/shell_exec/passthru/evalなどの危険関数が呼び出され得ます。これは「マルウェア解析時に安全・決定論的な関数のみ許可する」というサンドボックス原則に反する実装ミスです。

このコードパスは、Imunify360統合時のスキャナが「常時オン」のデオブファスケーションを有効としているため、バックグラウンドスキャン、オンデマンド、ユーザ起動、クイックスキャンのいずれでも到達します。Patchstackの報告では、/tmp配下に細工したPHPファイルを置くだけで、スキャン時にRCEを誘発できるPoCが示されています。一方、単体のAI-Bolit CLIではデフォルトでアクティブなデオブファスケーションが無効化されており、条件が満たされない限り同じコードパスには入りません。

影響は運用権限にも依存します。スキャナが高権限（例：共有ホスティングにおける特権サービスアカウント）で実行されている場合、RCEは単一サイトの改ざんに留まらず、サーバ全体の乗っ取りや他テナントへの横展開に発展する恐れがあります。CloudLinuxの修正は、デオブファスケーション時に許可関数をホワイトリストし、任意関数の実行を遮断するものです。

⚠ 影響

サイト侵害：Webシェル設置、コンテンツ改ざん、データ流出
サーバ侵害：スキャナが高権限の場合、全体管理権限の奪取や横展開
プラットフォーム影響：cPanel/WHM・Pleskなどの共用基盤全体の信頼性低下
法令・契約リスク：個人情報漏洩、SLA違反、ブランド毀損

CVSS：未公開（CVE未割り当てのため）

🛠 対策

至急アップデート：AI-bolitを含むImunifyAV/ImunifyAV+/Imunify360をv32.7.4.0以降へ。適用後にバージョン確認とロールバック禁止のロックダウンを実施。
一時的低減策：アップデート前に可能であればアクティブなデオブファスケーションを無効化、または対象範囲を縮小。実現不能な場合は、スキャン権限を一般ユーザ相当へダウングレードし、SELinux/AppArmorでプロセスを拘束。
実行面の最小化：/tmpなど一時領域をnoexec,nosuidでマウント（環境互換性を事前検証）。PHPの危険関数（system/exec/shell_exec/passthru等）をdisable_functionsで無効化（アプリ影響に注意）。
境界防御：アップロード経路にWAF/拡張子・MIME検証・アンチウイルスの多段チェックを導入。未知難読化コードを高リスクとして隔離。
資産・脆弱性管理：Imunify系のインスタンスとバージョンを台帳化し、自動更新/検証（CIS v8 Control 2,7）。

📌 SOC視点

現状認識：ベンダ公式の侵害有無判定手順やIOCは未公開。能動的ハンティングが必要。
プロセス監視：Imunify/AI-bolit（および当該プロセスが起動するPHPインタプリタ）がシェル（/bin/sh,/bin/bash）やネットワークコマンド（curl,wget,nc,python,perl,php等）を子プロセスとして生成していないかをEDR/auditd/eBPFで監視。
ファイル監視：/tmp等に作成されたPHP/スクリプトが直後にスキャン対象となり、不審プロセス実行へ連鎖していないかの相関検出。
ログ相関：Imunify/AV関連ログ（例：/var/log配下のImunify製品ログ。実際のパスは環境依存）とプロセス・ネットワークログを突合し、スキャン直後の外向き通信／権限変更を検知。
ネットワーク：スキャン直後に未知のC2宛て通信やDNSクエリが発生していないかフロー/プロキシログを確認。

📈 MITRE ATT&CK

TA0002 実行 — T1203 Exploitation for Client Execution：スキャナ（アプリケーション）が解析対象の攻撃者制御データを処理中に脆弱性を突かれ、コード実行に至るため。
TA0004 権限昇格 — T1068 Exploitation for Privilege Escalation：スキャナが高権限で動作する構成では、RCEを足掛かりに権限昇格が成立し得るため。
TA0005 防御回避 — T1211 Exploitation for Defense Evasion：セキュリティ製品自体の処理系を悪用して実行を得るため、検知・ブロックの回避につながるため。
TA0003 永続化 — T1505.003 Server Software Component: Web Shell：RCE後の典型としてWebシェル設置が想定されるため。
TA0011 C2 — T1071 Application Layer Protocol（補足）：RCE後にHTTP/HTTPSを用いたC2通信が想定されるため。

🏢 組織規模別助言

小規模（〜50名）：共有ホスティング/管理パネル上のImunifyバージョンを即確認し更新。自動更新とバックアップの二重化を設定。/tmpのnoexec化など基本ハードニングを優先。
中規模（50〜500名）：全ホスティングノードの構成管理（IaC/構成管理ツール）で一括更新。EDR/auditdルールを全サーバに展開し、親子プロセス異常の検知を標準化。ステージングで互換性検証後に段階配備。
大規模（500名以上）：インベントリとCI/CDに更新を組み込み、コンフィグドリフト検出を有効化。SELinux/AppArmorプロファイルのプログレッシブ適用、eBPF監視の常時運用、攻撃面最小化（最小権限・最小機能）の設計原則を徹底。

🔎 類似事例

CVE-2023-20032（ClamAV HFS+パーサのヒープバッファオーバーフローによりRCE）— スキャナ実装の不備で任意コード実行に至った例。
CVE-2023-2868（Barracuda Email Security GatewayのRCE）— セキュリティ製品の解析処理を突かれ、アプライアンス全体が侵害された事例。
CVE-2022-42475（FortiOS SSL-VPNのヒープオーバーフロー）— 製品の脆弱性を足掛かりに境界装置から侵入・横展開が発生。