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は、カーネルレベルでsyscallを監視することで不審な活動の検知に優れています。Falcoはsyscallを実行前にブロックするわけではありませんが、攻撃者がエクスプロイトを完全に実行する前に、エスケープの試行を検知してアラートを出すことができます。
FalcoはeBPFを使ってsyscall実行前のガードレールを強制できますか？
Falcoはsyscallの可視化にeBPFを活用していますが、実行前にsyscallをブロックするためにeBPFへ固定的に組み込まれているわけではありません。代わりに検知モードで動作し、システムコールを分析してセキュリティルールに基づくリアルタイムアラートを生成します。つまり、次のことを意味します。
FalcoはVM/コンテナのエスケープで何を検知できますか？
Falcoは、コンテナの想定境界の外で実行されるsyscallを検知するための堅牢なルールを提供します。
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 escapefrom 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
別のデフォルト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]このルールは、コンテナまたはVMのエスケープを促進し得る特権操作に焦点を当てることで、CVEで示された攻撃ベクターに直接対処します。
ケーパビリティによる権限昇格を検知
別案として、コンテナまたは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内でrootに近い権限を得るために悪用される可能性があります。このルールは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]このルールは、VMXプロセスにおける競合状態を悪用する試みを検知することでCVE-2025-22224に関連します。これにより、攻撃者がVMから脱出してホストシステムへアクセスできる可能性があります。VMXプロセスとの異常な相互作用に焦点を当てることで、このルールは潜在的なVMエスケープの試行を特定し、緩和するのに役立ちます。
追加のハードニング対策：SELinux & KubeArmor
Falcoは強力なランタイム検知を提供しますが、追加の強制レイヤーにより悪用を防止できます。
強制アクセス制御（MAC）のためのSELinux
- 厳格なアクセス制御ポリシーを強制し、未承認のプロセスがハイパーバイザーのコンポーネントを改変することを防ぎます。
- VMXプロセスの改変を、信頼されたユーザーとプロセスのみに制限できます。
Kubernetes強制のためのKubeArmor
- コンテナレベルでsyscall制限を強制することで、エスケープの試行を能動的にブロックできます。
- 検知だけでなく既知の攻撃パターンを防止することで、Falcoを補完します。
Kubernetesの場合、KubeArmorはクラウドネイティブのランタイムセキュリティ強制システムであり、SELinux（Security-Enhanced Linux）やAppArmorなどのLinux Security Modules（LSM）に加えてeBPFも活用し、Kubernetesのセキュリティコンテキストを設定するだけでは得られない機能を提供してKubernetesワークロードを保護します。
これらのESXiホストは常にKubernetesに紐づくとは限らないため、ユーザーがKubeArmorの利点（LSMの複雑さを簡素化し、アラートやテレメトリーイベントを含む、Pod・コンテナ・ノード向けのきめ細かなランタイムセキュリティを提供すること）を常に享受できるわけではありません。そのようなシナリオでは、次のように、これらのsyscallを制限するカスタムSELinuxモジュールを定義することを推奨します。
module vmx_escape_restrict 1.0;
require {
type vmx_t;
type sysctl_t;
classprocess{ execmem execstack };
classsyscall{ 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のような潜在的に危険なsyscallをVMXプロセスが実行できないように制限します。カスタムSELinuxポリシーを定義することで、VMXが許可されるsyscallを特定して制限でき、成功するエスケープの可能性を低減できます。
上記ポリシーの文脈では、vmx_t はVMware ESXiにおけるVMXプロセスのSELinuxタイプであり、一方で syscall { setns unshare }は、コンテナやVMのエスケープ試行で一般的に使用される名前空間操作に関連する実際のシステムコールです。このポリシーは、VMXプロセスに対してこれらのsyscallを拒否します。VMXプロセスの通常実行に必要なプロセス権限としてprocess { execmem execstack } を含めています。最後に、sysctl_tはシステム制御プロセスのタイプであり、セキュリティに影響を与えることなく通常の設定へのアクセスを許可します。
ファイル（拡張子が.teで終わる）にSELinuxポリシーを定義したら、それをコンパイルして読み込むことができます。ただし、このようなSELinuxポリシーを本番環境に展開する前に、正当なVMware ESXiの機能を妨げないことを確認するため、ステージング環境で十分にテストしてください。これは限定的なsyscall活動の例として提示したものですが、本番利用前にテストが必要です。カスタムFalcoルールで同様の挙動を検知したのと同様に、SELinuxでVMXプロセスのsetnsおよびunshare syscallsを拒否できます。このポリシーにより、VMXプロセスは名前空間を操作できなくなり、これはコンテナおよびVMエスケープのエクスプロイトにおける主要な手法です。
ハイパーバイザーエスケープに対する防御の強化
CVE-2025-22224はクラウド環境に対する深刻な脅威を示しています。Falcoは重要な検知レイヤーを提供し、攻撃者が完全な悪用を実行する前にVMおよびコンテナのエスケープを特定します。しかし、Falcoはsyscallを実行前にブロックしないため、SELinux、KubeArmor、そして堅牢なパッチ管理と組み合わせることが不可欠です。
Kubernetes & コンテナセキュリティ
翻訳元: https://www.sysdig.com/blog/detect-cve-2025-22224-with-falco
