攻撃者がノードのroot奪取で同居ワークロードの身分証を偽造 — Unit 42がSPIFFE/SPIREのなりすまし実証と検証ツール「Spooffe」を公開

Palo Alto Networksの脅威リサーチ部門Unit 42は2026年9月10日、Kubernetesノード上でroot権限を奪った攻撃者が、マシンID基盤であるSPIFFE/SPIREの仕組みを悪用し、同居する別のワークロードになりすます手法を実証したと発表した。攻撃者はLinuxのcgroup情報を偽装し、ノード上のSPIREエージェントをだまして、別ワークロードの身分証（SVID）を攻撃者自身のプロセスに発行させる。Unit 42は防御側が自環境の影響範囲を検証できるオープンソースツール**「Spooffe」**も公開した。なおUnit 42は、この手口が実環境で悪用された事例は確認していないと明言している。

クラウドネイティブ環境を運用する日本企業でも、ワークロード間の相互認証にSPIFFE/SPIREや同様の仕組みを使う例が増えている。root奪取後の被害範囲を正しく見積もるための前提知識として重要だ。

SPIFFE/SPIREとは — 短命な「身分証」で秘密情報を置き換える仕組み

SPIFFE（Secure Production Identity Framework for Everyone）は、マシンやワークロードに短命で暗号学的に検証可能な身分証を発行するためのオープン標準である。長い有効期限を持つ秘密情報（いわゆる「Secret Zero」問題）をなくし、鍵の配布・更新・失効の運用負荷を下げる狙いがある。SPIREはその代表的な実装で、Kubernetes環境に広く導入されている。

登場人物は3つある。ワークロード（コンテナやプロセスなどの実行単位）、各ノード上で動くSPIREエージェント、認証局として振る舞い身分証を署名・発行するSPIREサーバーだ。ワークロードが身分証（SVID）を求めると、エージェントはそのワークロードの実行時属性（セレクターと呼ぶ。cgroup情報やKubernetesのPod情報など）を収集し、サーバーが登録済みポリシーと照合して発行可否を決める。SVIDにはX.509証明書形式とJWT形式があり、mTLS接続時の相互認証などに使われる。

攻撃の仕組み — cgroup偽装でエージェントをだます

Unit 42の実証では、攻撃者が対象ノードのroot権限を既に奪っていることが前提となる。攻撃者は次の手順で別ワークロードのSVIDを入手する。

cgroup情報の偽装: SPIREエージェントはワークロードの正体をLinuxのcgroup情報で見分けている。root権限を持つ攻撃者はこのメタデータを操作し、自分のプロセスが標的ワークロードであるかのように見せかける
SVIDの不正発行: だまされたエージェントは、サーバーのポリシー照合を通過するための認証データを生成する。その結果、標的ワークロード宛てのSVIDが攻撃者のプロセスに交付される
なりすましと収集: 攻撃者は入手したSVIDを使い、標的ワークロードとして他のサービスとmTLS通信できる。同一ノード上の複数の身分証を収穫すれば、横展開の足がかりになる

Unit 42はこの問題の本質を、「ノードは信頼できる」というあらゆるマシンIDシステム共通の前提が、root奪取によって崩れる点にあると指摘している。SPIRE固有の脆弱性ではなく、信頼設計の前提条件の問題だという整理だ。

検証ツール「Spooffe」とUnit 42が示す対策

Unit 42は研究成果として、**管理者権限を持つ攻撃者がcgroupメタデータを操作して同居ワークロードの身分証を取得できるかを検証するツール「Spooffe」**をオープンソースで公開した。防御側は自環境で実行し、**どの範囲の身分証が同一ノードのroot奪取で漏れるか（identity area of impact）**を事前に把握できる。

Unit 42が推奨する対策は次の通りである（いずれも同社が公表した内容）。

ノードを強化する: 不要な機能を削り、攻撃面を狭める
rootアクセスを制限する: ノードへの管理者権限の付与を最小限にする
特権コンテナやホストへの直接アクセスを禁止する: root奪取の経路を断つ
弱いセレクターへの依存を減らす: 偽装しやすい属性だけで発行可否を決めない設計にする

同社は脅威モデルを設計する際、「ノードのroot権限奪取は、そのノードに紐づくすべての暗号学的身分証の奪取と同義」とみなすべきだと述べている。

Unit 42の推奨に沿った対応 — 設計前提の見直しが先決

Kubernetesやクラウドネイティブ基盤でSPIFFE/SPIRE（または同等のワークロードID基盤）を使う組織について、Unit 42は次の対応を推奨している。まず同社が公開したSpooffeで単一ノード侵害時にどの身分証が漏れるかを検証し、特権コンテナの有無やノードへのroot到達経路を確認する。Unit 42が強調する通り、これは今すぐパッチを当てる類いの脆弱性ではなく、設計前提の見直しである。実環境での悪用は確認されていないため、脅威モデルと運用ポリシーへの反映が先決だと同社は述べている。

出典

Palo Alto Networks Unit 42, “The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE”（2026年9月10日公開）: https://unit42.paloaltonetworks.com/kubernetes-spiffe-spire-identity-spoofing/

この記事は、公開情報と編集部の調査・知見をもとに構成しています。内容は公開時点の情報に基づく解説であり、個別の環境への診断・対応を保証するものではありません。重要な判断では、記事内の出典や各提供元の最新情報もご確認ください。