本文の内容は、2025年3月13日に Nigel Douglas が投稿したブログ(https://sysdig.com/blog/detect-cve-2025-22224-with-falco/)を元に日本語に翻訳・再構成した内容となっております。
Shadowserver グループは最近、重大な Time-of-Check Time-of-Use ( TOCTOU ) コード実行攻撃であるCVE-2025-22224に対して脆弱な、インターネットに公開されている 41,500 台を超える VMware ESXi ハイパーバイザーを特定しました。侵害された VM への管理者アクセス権を取得した攻撃者は、この欠陥を悪用してハイパーバイザー上で任意のコードを実行し、ホストされているすべての VM とネットワーク資産を完全に制御できます。
Broadcom は、この欠陥を修正するために ESXi および Workstation 製品向けの緊急パッチをリリースしました。CVSS スコアは9.3に設定されています。ただし、悪用が活発に行われているため、セキュリティチームは、回避の試みが成功する前にそれを検知するために、強力なランタイム脅威検出を導入する必要があります。
FalcoでVMとコンテナのエスケープアクティビティを検知する方法
クラウドネイティブのランタイム セキュリティ ツールであるFalco は、カーネルレベルでのシステムコールを監視することで、不審な活動を検知するのに優れています。Falcoはシステムコールを事前にブロックすることはできませんが、攻撃者がエクスプロイトを完全に実行する前に、エスケープ試行を検出してアラートを発することができます。
Falco は eBPF を使用して pre-syscall ガードレールを強制できますか?
FalcoはeBPFを活用してシステムコールの可視性を確保しますが、eBPFに依存してシステムコールを事前にブロックするわけではありません。代わりに、検知モードで動作し、システムコールを分析し、セキュリティルールに基づいてリアルタイムのアラートを生成します。これはつまり、次のようなことを意味します。
- Falco は、予期しない権限昇格やコンテナ/VM 内からのホストレベルのアクセスなどのエスケープの振る舞いを早期に検知します。
- Falco は最初のエクスプロイトの試みを防ぐことはできませんが、対応アクション（Kubernetes アドミッション コントローラー、 KubeArmorなどの強制ツール、SELinuxポリシーなど）と組み合わせることで、影響を軽減できます。
Falco は VM/コンテナエスケープにおいて何を検知できますか?
Falco は、コンテナの想定境界外で実行されたシステムコールを検知するための堅牢なルールを提供します。Falco
がコンテナ、プロセス、VM エスケープを検出する方法をよりよく理解するために、デフォルトの Falco ルールがどのように機能するかを見てみましょう。
release_agentファイルコンテナのエスケープを検知する
以下のルールは、Falcoに標準で提供されています。このルールは、release_agent ファイルを変更することでコンテナエスケープを試みる行為を検知します。これは、特定のケーパビリティ（CAP_SYS_ADMINやCAP_DAC_OVERRIDEなど）を持つ特権ユーザーが、コンテナ内でこのファイルにアクセスし、書き込みを行った場合に発生する可能性があります。このルールは、そのような書き込み操作が発生した際にトリガーされ、潜在的なセキュリティ侵害を示します。
- rule: Detect release_agent File Container Escapes
desc: >
Detects an attempt to exploit a container escape using release_agent file.
By running a container with certain capabilities, a privileged user can modify
release_agent file and escape from the container.
condition: >
open_write
and container
and fd.name endswith release_agent
and (user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE)
and thread.cap_effective contains CAP_SYS_ADMIN
output: Detect an attempt to exploit a container escape using release_agent file (file=%fd.name cap_effective=%thread.cap_effective evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
priority: CRITICAL
tags: [maturity_stable, container, process, mitre_privilege_escalation, T1611]
特権コンテナで Debugfs を起動
もう1つのデフォルトのFalcoルールは、特権コンテナ内でDebugFSファイルシステムデバッガーが起動された際に検知を行います。これは、コンテナエスケープの可能性がある行為として監視されます。しかし、このルールの適用範囲は限定的であり、特権コンテナ内で動作するdebugfsプロセスを特定の対象としているため、特定のツールと環境に焦点が絞られています。
- rule: Debugfs Launched in Privileged Container
desc: >
Detect file system debugger debugfs launched inside a privileged container which might lead to container escape.
This rule has a more narrow scope.
condition: >
spawned_process
and container
and container.privileged=true
and proc.name=debugfs
output: Debugfs launched started in a privileged container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
priority: WARNING
tags: [maturity_stable, container, cis, process, mitre_privilege_escalation, T1611]
ホストネームスペースへのアクセスを検知
CVE-2025-22224の文脈において、以下のカスタムFalcoルールは、コンテナ内のプロセスがホストのネームスペースとやり取りしようとする試みを監視することで、潜在的なコンテナエスケープの試みを検知します。具体的には、setns や unshare といったシステムコールが実行された際にアラートをトリガーします。これらのシステムコールは、ネームスペースを操作するために一般的に使用され、コンテナの境界を突破しホストシステムを侵害する可能性があります。
- rule: Container Escape Attempt via Namespace Access
desc: Detects attempts to access host namespaces from a container
condition: >
container.id != host and
(evt.type = setns or evt.type = unshare)
output: "Possible container escape attempt (process=%proc.name, pid=%proc.pid)"
priority: CRITICAL
tags: [custom_rule, host, process, mitre_privilege_escalation, T1611]
このルールは、特権操作に着目することで、CVEで指摘された攻撃ベクトルに直接対応し、コンテナやVMのエスケープを引き起こす可能性のある振る舞いを検知します。
ケーパビリティを利用した特権昇格の検知
また、コンテナやVM内での特権昇格の試みを検出するために、特定のケーパビリティ（特にCAP_SYS_ADMINやCAP_SYS_PTRACE）を獲得したプロセスを監視するカスタムルールを提供しています。
- rule: Privilege Escalation via New Capabilities
desc: Detects processes inside a container gaining extra capabilities
condition: >
container.id != host and evt.type = capset and
(evt.arg.cap = CAP_SYS_ADMIN or evt.arg.cap = CAP_SYS_PTRACE)
output: "Process gained elevated capabilities (process=%proc.name, cap=%evt.arg.cap)"
priority: HIGH
tags: [custom_rule, host, process, mitre_privilege_escalation, T1611]
これらの機能はシステムレベルの操作にとって重要であり、攻撃者がコンテナまたは VM 内でルートのような権限を取得するために悪用される可能性があります。このルールは CVE に直接関連しており、攻撃者がコンテナエスケープを実行する前に権限を昇格する試みを特定して、ホスト システムのさらなる侵害を防ぐのに役立ちます。
VMX プロセスを標的としたエクスプロイトの検知 (CVE-2025-22224 固有)
この脆弱性はESXi の VMX プロセスにおける競合状態を悪用するため、Falco は不要な VMX アクティビティを監視できます。以下の Falco ルールは、仮想マシンの実行を担当する VMware ESXi の vmx プロセスに関連するアクティビティを監視します。プロセスが予期せず開かれたり、書き込まれたり、実行されたりし、コマンドラインに「expected_admin_task」が含まれていない場合、アラートがトリガーされます。これは、潜在的に悪意のある、または異常な変更を示しています。
- rule: Suspicious VMX Process Modification
desc: Detects unexpected changes to VMX processes in ESXi
condition: >
proc.name = "vmx" and evt.type in (open, write, execve) and
not proc.cmdline contains "expected_admin_task"
output: "Potential VM escape attempt targeting VMX process (cmdline=%proc.cmdline)"
priority: CRITICAL
tags: [custom_rule, host, process, mitre_privilege_escalation, T1611]
このルールは、CVE-2025-22224 に関連しており、VMX プロセスで競合状態を悪用する試みを検出します。これにより、攻撃者は VM からエスケープし、ホストシステムにアクセスできるようになります。このルールは、VMX プロセスとの異常なやり取りに焦点を当てることで、潜在的な VM エスケープの試みを特定し、軽減するのに役立ちます。
追加の強化策: SELinux と KubeArmor
Falco は強力なランタイム検知を提供しますが、追加の強制レイヤーによって悪用を防ぐことができます。
強制アクセス制御のための SELinux
- 厳格なアクセス制御ポリシーを適用し、不正なプロセスがハイパーバイザーコンポーネントを変更するのを防ぎます。
- VMX プロセスの変更を信頼できるユーザーとプロセスのみに制限できます。
Kubernetes における強制のための KubeArmor
- コンテナ レベルで syscall 制限を適用することにより、エスケープ試行を積極的にブロックできます。
- 既知の攻撃パターンを検出するだけでなく、防止することで Falco を補完します。
Kubernetes の場合、KubeArmor はクラウドネイティブのランタイム セキュリティ強制システムであり、SELinux (Security-Enhanced Linux) や AppArmor などの Linux セキュリティ モジュール (LSM) を eBPF とともに利用して Kubernetes ワークロードを保護し、Kubernetes でセキュリティ コンテキストを設定する以上の機能を提供します。
これらの ESXi ホストは常に Kubernetes に結び付けられるわけではないため、ユーザーは、LSM の複雑さを簡素化し、アラートやテレメトリイベントを含むポッド、コンテナ、ノードに対してきめ細かなランタイムセキュリティを提供するという KubeArmor の利点を常に享受できるわけではありません。このようなシナリオでは、次のようにカスタム SELinux モジュールを定義して、これらのシステム コールを制限することをお勧めします。
module vmx_escape_restrict 1.0;
require {
type vmx_t;
type sysctl_t;
class process { execmem execstack };
class syscall { setns unshare };
}
# Deny syscalls related to namespace manipulation for the vmx process
deny vmx_t self:syscall setns;
deny vmx_t self:syscall unshare;
# Allow other normal activities of the vmx process
allow vmx_t sysctl_t:process { execmem execstack };
上記のカスタム SELinux アクセス制御ポリシーは、コンテナまたは VM のエスケープ試行でよく使用される setns や unshare などの潜在的に危険なシステム コールを実行する VMX プロセスの機能を制限します。カスタム SELinux ポリシーを定義することで、VMX が実行できるシステム コールを具体的に制限し、エスケープが成功する可能性を減らすことができます。
上記のポリシーのコンテキストでは、vmx_t は VMware ESXi の VMX プロセスの SELinux タイプですが、は syscall { setns unshare }コンテナまたは VM のエスケープ試行でよく使用されるネームスペース操作に関連する実際のシステムコールです。このポリシーは、VMX プロセスへのこれらのシステム コールを拒否します。VMX プロセスprocess { execmem execstack } の通常の実行のためのプロセス権限として含めます。最後に、sysctl_tはシステム制御プロセスのタイプであり、セキュリティに影響を与えることなく通常の構成へのアクセスを許可します。
SELinuxポリシーを .te 拡張子のファイルとして定義した後、それをコンパイルしてロードできます。しかし、このようなSELinuxポリシーを本番環境にデプロイする前に、必ずステージング環境で十分にテストし、正当なVMware ESXiの機能を妨げないことを確認してください。このポリシーは、限定的なシステムコールアクティビティの例として提供されていますが、本番環境で使用する前にテストが必要です。我々がカスタムFalcoルールで同様の動作を検知したように、SELinuxを使用してVMXプロセスに対する setns および unshare システムコールを拒否できます。このポリシーにより、VMXプロセスが名前空間を操作できなくなり、コンテナやVMのエスケープ攻撃に利用される主要な手法を防ぐことができます。
ハイパーバイザーからのエスケープに対する防御の強化
CVE-2025-22224はクラウド環境に対する重大な脅威を示しています。Falcoは重要な検知レイヤーを提供し、攻撃者が完全な悪用を実行する前にVMおよびコンテナのエスケープを特定します。しかし、Falcoはシステムコールを実行前にブロックしないため、SELinux、KubeArmor、そして堅牢なパッチ管理と組み合わせることが重要です。
重要なポイント:
- Falco は、エスケープ試行の初期兆候 (ネームスペースアクセス、権限昇格、疑わしい VMX 変更など) を検知します。
- Falcoはシステムコール実行前にエクスプロイトをブロックすることはできません。しかし、Falco Talonを活用することで、リアルタイムのアラートおよび自動対応を実現できます。
- Falco と SELinux を組み合わせると強制力が強化され、システムコールアクティビティが防止されます。
- ESXi の脆弱性を直ちに修正することは、セキュリティギャップを埋めるために重要です。
Falco のランタイム検知を活用することで、セキュリティチームは、エスケープの試みがハイパーバイザーの完全な侵害にエスカレートする前に、それを検知して阻止できます。VM とコンテナのセキュリティがミッションクリティカルな世界では、階層化された防御が最善の戦略です。Falco がエスケープアクティビティを検知する方法について詳しく知りたい場合は、同様の CVE に関するブログを多数公開しています。