Kubernetesノードへのroot権限アクセスを持つ攻撃者が、SPIFFE/SPIREを通じて発行されたワークロードIDを窃取し、同一ホスト上で稼働する正規のアプリケーションになりすますことを可能にするポストエクスプロイト手法が明らかになりました。
この手法は、クラウドネイティブなマシンID管理システムの前提となっている「ノードは信頼できる」という考え方そのものを揺るがすものであり、攻撃者が相互TLS認証やID基盤の認可によって保護されているサービスにアクセスできてしまう可能性があります。
Palo Alto Networks傘下のUnit 42によれば、この手法が実際の攻撃で悪用された事例はこれまでのところ確認されていないとのことです。
Hacking& Cracking
SPIFFE(Secure Production Identity Framework for Everyone)は、静的なシークレットやAPIキーによるアクセス、長期間有効な証明書に代わり、短命かつ暗号学的に検証可能なワークロードIDを実現するために設計されたオープン標準規格です。
SPIREは、Kubernetes、仮想マシン、ベアメタル環境全体にわたってワークロードのアテステーション(証明)を行い、クレデンシャルを発行し、信頼情報を配布するために使われている、実運用向けのリファレンス実装です。
ワークロードには一般に「spiffe://trust-domain/workload-path」の形式で表されるSPIFFE IDと、それに紐づくSPIFFE検証可能アイデンティティ文書(SVID)が付与されます。
SVIDは、mTLS認証用のX.509証明書、あるいはアプリケーションレベルの認可用のJWTとして発行できます。連携先のサービスは、ワークロードのIDを受け入れる前に、このクレデンシャルを信頼バンドルと照合して検証します。
ホストが信頼できる状態にある限り、このモデルは強固な境界を提供します。しかし、Unit 42の調査によると、ノードレベルでの侵害が発生した後は、この境界が崩壊してしまうことが分かりました。
Unit42の研究者らは、SPIFFE/SPIREを利用する組織にとって重大な弱点があると指摘しています。それは、Kubernetesノードがroot権限レベルで侵害されると、そのノードが利用可能なすべてのワークロードIDが漏洩したものとみなすべきだ、という点です。
Kubernetesへのアイデンティティ攻撃
攻撃者は、標的アプリケーションのSVIDを守る暗号技術を破る必要はありません。代わりに、そのアプリケーションが信頼しているローカルのID発行プロセスを悪用することができます。
この攻撃は、SPIREのワークロードアテステーション、すなわちSPIREエージェントがローカルプロセスに対して特定のワークロードIDを発行してよいかどうかを判断するプロセスを標的にしています。
Kubernetes環境では、エージェントはLinuxの/procデータやcgroupパスからワークロードの属性を導き出し、発見したコンテナやPodの詳細情報をKubernetesのメタデータと照合します。
これらの属性は「セレクタ」と呼ばれ、Kubernetesの名前空間、サービスアカウント、Pod UID、Pod名、コンテナイメージ、LinuxのUIDやGIDなどを含む場合があります。
SPIREエージェントは、対応するSVIDを発行する前に、このセレクタ群をローカルにキャッシュされたワークロード登録エントリと照合します。
Unit 42は、root権限を持つ攻撃者であれば、攻撃者が制御するプロセスのcgroupメタデータを操作し、そのプロセスがあたかも同一ホスト上の別のコンテナに紐づいているかのように見せかけられることを発見しました。
その悪意あるプロセスは、その後ローカルのSPIFFE Workload APIを通じてクレデンシャルを要求し、エージェントになりすまし対象のワークロードに属する有効なSVIDを発行させることができます。
この影響はクレデンシャルの窃取だけにとどまりません。窃取されたX.509 SVIDを使えば、攻撃者は被害を受けたアプリケーションになりすまし、mTLS経由で内部サービスに認証を通すことができてしまう可能性があります。
また、JWT-SVIDは、標的ワークロードのSPIFFE IDが信頼されているID認識型のAPIや認可レイヤーで受け入れられてしまう可能性があります。つまり、ノードの侵害は、クラスタ内部での横展開や権限昇格の機会になり得るということです。
防御側が自組織の被害範囲を検証できるよう、Unit 42はオープンソースの評価ツール「Spooffe」を公開しました。
このツールはノード上で稼働中のワークロードをスキャンし、そのcgroupパスを特定した上で、自身のプロセス用に偽装したcgroup構造を作成し、取得できる可能性のあるIDについてローカルのSPIREエージェントに照会します。
このツールは正規の防御目的の検証を想定したものであり、セキュリティチームは、攻撃者がワーカーノードへの管理者アクセス権を得た場合にどのSVIDが窃取され得るかを特定できます。
また、エージェントへのなりすましシナリオを検証する機能も含まれていますが、今回の調査ではcgroup操作によるセレクタ偽装が主な焦点となっています。
今回の発見は、SPIFFEの暗号技術そのものが破られていることを示すものではありません。むしろ、ワークロードのIDの強度は、ノードのセキュリティ境界の強度に依存するにすぎないという点を裏付けるものです。
Securitytraining courses
組織は、Kubernetesワーカーノードでのroot権限アクセスを、そのノードに紐づくすべてのIDの漏洩として扱うべきです。
防御側は、ノードを強化し、rootや特権コンテナへのアクセスを厳格に制限し、不要なホスト名前空間、ソケット、ファイルシステムマウントを排除し、脆弱または過度に広範なワークロードセレクタへの依存を最小限に抑える必要があります。
セキュリティチームはまた、各ノードから発行され得る価値の高いIDを洗い出すとともに、管理された環境下でSpooffeを使って被害の及ぶ範囲を測定すべきです。
SOCのアラート調査を1件あたり21分短縮。即座に対応できるよう、IOCの文脈情報でSOCを強化しましょう。 TI Lookupを自組織のSOCに統合する
翻訳元: https://gbhackers.com/kubernetes-identity-attack/
