二重特権昇格攻撃チェーン: GKE (Google Kubernetes Engine) で監視やサービス メッシュの構成と権限をエクスプロイトして Kubernetes で不正アクセスを取得する手法

This post is also available in: English (英語)

概要

本稿は、Google Kubernetes Engine (GKE) における 2 つの特定の問題について検討します。それぞれの問題は単独なら重大な損害はもたらしません。ただしこれらが組み合わさると、すでに Kubernetes クラスターにアクセスできる攻撃者に特権昇格の機会を与えます。Kubernetes ユーザーと管理者の皆さんは、本稿を重要なリソースとしてお使いください。また本稿は、潜在的な攻撃からクラスターを保護する洞察も提供します。

1 つめに検討する問題は、GKE のロギング エージェントである FluentBit のデフォルト構成についてです。FluentBit は全クラスターでデフォルトで実行されています。2 つめに検討する問題は、Anthos Service Mesh (ASM) のデフォルト権限です。ASM は利用者が有効にできるオプションのアドオンで、GKE 環境内でサービス間通信を制御する Istio Service Mesh の Google による実装です。

攻撃者が (たとえば、対象コンポーネント内にリモートから悪用可能な脆弱性を見つけるなどして) FluentBit コンテナー内での実行能力を持っていて、かつそのクラスターに ASM がインストールされていた場合、その攻撃者はそこから 1 本の強力な攻撃チェーンを作りだし、Kubernetes クラスターを完全に制御できるようになります。このアクセスを利用すれば、攻撃者はデータ窃取、悪質な Pod の展開、クラスターの運用妨害を行えるようになります。

Kubernetes は、アプリケーションのデプロイや管理に最も広く採用されているオープンソースのコンテナー プラットフォームです。多くの Kubernetes 環境はその複雑さにより、構成ミスや過剰な権限によるセキュリティ侵害の影響を受けやすくなっています。場合によっては、こうしたことが利用者が意識することなく発生することがあり、利用者がセキュリティ上の脆弱性にさらされる可能性があります。

2023 年 12 月 14 日、Google は GCP-2023-047 によって両方の構成問題を修正しました。

パロアルトネットワークスのお客様は、以下の方法で、本稿で説明する攻撃に対するよりよい保護と緩和を受けています。

• Unit 42 インシデント レスポンス チームは組織の皆さまへの個別対応をご利用いただけます。
• Prisma Cloud は、システムの Pod やアドオンの Pod を標的とした攻撃など、さまざまな脅威から Kubernetes クラスターを保護するのに役立ちます。
• Cortex XDR は、お使いのデジタル環境全体について、包括的にインシデントのストーリーを描くことにより、SOC チームの能力を強化します。

Kubernetes と Google Kubernetes Engine (GKE)

今回の問題点と攻撃可能性について掘り下げる前に、まずは Kubernetes の基本概念と GKE 機能の基本概要に関する共通理解を確立しておかねばなりません。

Kubernetes の概念

Kubernetes は複雑なプラットフォームで、さまざまな概念から構成されています。これらの概念への理解は今回の攻撃シナリオの理解には欠かせませんので、このなかから 2 つを取り上げて紹介したいと思います。「DaemonSet」と「ロールベースのアクセス制御 (RBAC)」の 2 つです。

DaemonSet

DaemonSet と Deployment はどちらも Kubernetes のコントローラーで、Podの作成やデプロイメントの管理に使われます。

ただし、この 2 つは目的やユース ケースが異なります。Deployment は Kubernetes クラスター全体にわたる Pod の複数インスタンスの作成やデプロイメントの管理に使われます。これは Web サーバーやデータベース サーバーなどのステートレスなアプリケーションの実行に役立ちます。

DaemonSet は Kubernetes クラスター内の各 Node 上で、ある Pod の単一インスタンスが実行されていることを保証するために使われます。これは ログの記録、監視、ネットワーキングなど、重要なクラスター サービスを提供する Pod の実行に役立ちます。

RBAC の権限

ロールベースのアクセス制御 (Role-based access control: RBAC) は、Kubernetes クラスター内のリソースにきめ細かいアクセス制御メカニズムを提供するセキュリティのしくみです。RBAC は、ユーザーとグループをロールに割り当て、それらのロールに特定リソースに対する権限を付与することによって機能します。

RBAC は偶発的な特権昇格や不正アクセスの防止に役立つ Kubernetes の重要なセキュリティ機能です。RBAC の権限を慎重に構成することで、ユーザーやグループが自身の職務遂行上必要とする権限だけを持てるようになります。

GKE の機能

GKE は、プラットフォームにもとからある多数の機能にくわえ、オプション機能も追加で有効化できるようにしています。これらの機能は Kubernetes クラスターのデプロイや管理を簡素化できるように設計されていますが、それらの機能がセキュリティに及ぼしうる影響については認識しておかねばなりません。

FluentBit

FluentBit は軽量で効率的なログ プロセッサー/フォワーダーです。2023 年 3 月のマイルストーン 105 以降、FluentBit は全 GKE クラスターのデフォルト ログ処理エージェントになっていて、DaemonSet によってデフォルトでデプロイされます。

これはつまり FluentBit はクラスター内の各 Node にインストールされていることを意味します。FluentBit は Container-Optimized の OS 109 からデフォルトで有効で、レガシーのエージェントはデフォルトで無効になっています。

Anthos Service Mesh

Anthos Service Mesh は、強力なオープンソース プロジェクトである Istio の Google による実装です。これを使えば、ユーザーはアプリケーション コードを変更することなく、サービスを管理、監視、保護できます。

次世代型第二段階クラウド攻撃

第二段階クラウド攻撃とは、攻撃者が対象の Kubernetes クラスターに対してすでにある程度のアクセスを有しているタイプの攻撃を指します。その後、攻撃者はクラスターへの展開や特権昇格をねらい、構成ミスそのほかの脆弱性を探します。

こうした攻撃側・防御側のいたちごっこにおいて、コンテナー エスケープは引き続き脅威となります。攻撃者は常に、コンテナーをエスケープしてクラウド環境を制御する方法を見つけようとしています。クラウド インフラそのほかの環境は、攻撃者が侵入に成功しても損害を与えられない (または少なくとも重大な損害を与えられない) ように、じゅうぶん安全にしておく必要があります。

特定の構成ミスのなかには、必ずしもセキュリティ上の問題にならず、保護されたクラウド環境に影響を与えないと考えうるものもありますが、そうした構成ミスが複数つながると強力なエクスプロイト チェーンを生んでしまうことがあります。

本稿で解説する 2 つの問題は、両者をつなぎ合わせて第 2 段階攻撃に組み込むことにより、攻撃者に Kubernetes クラスターの制御を完全に掌握されてしまうおそれがあります。

特権昇格の仕上げ

第 0 段階: FluentBit のエクスプロイトまたはコンテナーから Node へのエスケープ

この攻撃は二段階攻撃です。つまり攻撃者はリモート コード実行の脆弱性か任意のファイル読み取りの脆弱性を見つけて FluentBit コンテナーをエクスプロイトしておくか、別コンテナーからエスケープして対象 Node へのアクセスを得ておく必要があります。

第 1 段階: FluentBit の権限をエクスプロイトしてプロジェクションされたサービス アカウント トークンを読み取る

この攻撃チェーンの第 1 段階では、「FluentBit のコンテナーが /var/lib/kubelet/pods ボリュームをマウントしていた」という構成ミスを悪用します。このディレクトリーの下には、Node 上で実行されている各 Pod が、プロジェクションされたサービス アカウント トークンを含む kube-api-access ボリュームを持っています。

図 4 は、これにより FluentBit コンテナーが当該 Node 上の任意の Pod の任意のトークンにどのようにアクセスできようになるかを示したものです。

kube-api-access ボリュームには Pod が Kubernetes API と通信するためにプロジェクションされたサービス アカウント トークンが含まれていて、これは機微情報です。攻撃者が FluentBit Pod を侵害した場合、彼らはその Pod のボリュームにアクセスできるようになり、Node 上の任意の Pod の任意のトークンを使えるようになります。

攻撃者は Pod トークンを使って Kubernetes API サーバーへの特権アクセスを持つ Pod になりすまし、クラスターへのアクセスを不正に取得できます。さらにこの攻撃者は (get pods コマンドを使って) 実行中の Pod を一覧表示できるので、クラスター全体をマッピングすることも可能です。

攻撃者はこのクラスターへのアクセスを不正に得るだけでなく、特権昇格や有害行為を行いかねません。実際、Node 内で隣接する Pod の権限設定によっては、これが攻撃者に大きなアタック サーフェス (攻撃対象領域) を与えます。

FluentBit コンテナーは、デフォルトでは、また一般的には、 Kubernetes API サーバーに直接アクセスする必要はありません。このコンテナーは Kubernetes のインフラかサイドカー コンテナーのいずれかを使うことができます。というのも、サイドカー コンテナーの主目的は、メインのアプリケーション コンテナーからログを収集・解析・転送することにあるからです。このサイドカー コンテナーは Pod のコンテキスト内で動作し、Kubernetes のインフラを利用してログ ファイルとコンテナーのランタイム メタデータにアクセスします。

第 2 段階: Istio のインストール後の権限をエクスプロイトする

この攻撃チェーンの第 2 段階では「Anthos Service Mesh (ASM) のコンテナー ネットワーク インターフェイス (CNI) の DaemonSet が、インストール後に過剰な権限を持ったままになっている」という事実を悪用します。これにより、攻撃者は ASM の CNI DaemonSet 権限を持つ、新たな Pod を作成できるようになります。ASM を有効にした場合、そのクラスターには Istio-cni-node DaemonSet がインストールされます。

この Istio-cni-node DaemonSet は、クラスター内の各 Node に Istio CNI プラグインをインストール・構成する役割を果たします。このため Istio-cni-node DeamonSet はこれらのタスクを実行しうる強力な権限を持っています。ただし、いったん起動・実行してしまえば、これほど広い権限は必要ありません。

この DaemonSet には 2 つの役割があります。

• CNI プラグインをインストールする役割。これは、hostPath のマウントとホストのファイル システム (FS) へのいくつかのファイルの書き込み (これらを後に Kubelet が読み取る) によって行われます。これに RBAC は必要とされませんが、hostPath マウントは使われます。
• 「修復」モードの役割。このモードは、Pod が構成なしで開始された かどうかを検出して処理します。これが機能するにはいくつか RBAC の権限が必要です。

ASM の CNI DaemonSet がこうした権限を必要とすることが原因で、攻撃者が (たとえば「強力な Pod」を作成することで) DaemonSet をエクスプロイトしてクラスターへの不正アクセスを取得可能になります。

ここまで説明してきた 2 つの問題をつなぎあわせて使えば、攻撃者はクラスター管理者に特権昇格し、Kubernetes クラスターを完全に制御できるようになります。

完成した攻撃チェーン: クラスター管理者の奪取

Kubernetes の概念と問題を理解できたところで、これらを悪用して、対象のクラスターに対し、クラスター管理者の特権アクセスを得る方法を見ていきます。

前提条件: Anthos Service Mesh 機能が有効であること

いったん Kubernetes クラスターへの特権アクセスを取得してしまえば (このタスクの実現には FluentBit コンテナーの制御を奪取すればよい)、攻撃者は FluentBit コンテナーのデフォルト構成をエクスプロイトして /var/lib/kubelet/pods ボリュームをマウントできるようになります。そしてこれには kube-api-access-<ランダムな接尾辞> ディレクトリーへのアクセスがあります。これにより攻撃者は、ある Node のすべての Pod から、すべてのトークンを得ることになります。

FluentBit が DaemonSet であるという事実により、攻撃者は各 Node で最初の侵害行為を繰り返し行い、クラスター内のあらゆる Pod にマウントされているトークンを検索できます。そのようにしてクラスター全体をマッピングすれば、Istio-Installer-container トークンを見つけられます。

攻撃者はこの後、インストール プロセス完了後の ASM CNI DaemonSet の強力な権限を利用することになるでしょう。そして攻撃者は Kube-System 名前空間に新たな Pod を作成します。

これを意味のある特権昇格にするには、攻撃者は強力なサービス アカウントを狙う必要があるでしょう。

Kube-System 名前空間には、プリインストールされた非常に強力なサービス アカウントが多数用意されているのでそこから選ぶことができます。

clusterrole-aggregation-controller (CRAC) サービス アカウントがおそらく筆頭候補になるでしょう。このサービス アカウントであれば既存のクラスター ロールに任意の権限を追加できます。攻撃者は CRAC にバインドされたクラスター ロールを更新し、すべての特権を持たせることができます。

図 6 は、攻撃者が Pod の YAML ファイル内で CRAC のサービス アカウントに権限を付与し、最終的に攻撃者らがトークンを独自のボリューム フォルダーの 1 つに保存する方法を示しています。

この CRAC トークンは現在、攻撃者が作成したばかりの新たな Pod にマウントされています。攻撃者はここで再び FluentBit の構成ミスをエクスプロイトして CRAC トークンを取得できます。この CRAC トークンには、それ自体がクラスター管理者として動作する権限があります。

修正と緩和策

FluentBit は、/var/lib/kubelet/pods ディレクトリーの hostPath ボリューム マウントを使って、自身のジョブの実行に必要な特定のログを読み取れるようにしています。修正前は、明らかにボリューム マウント構成に Pod ディレクトリーへの不必要なアクセス (プロジェクションされたサービス アカウント トークンを含む) が含まれていました。Google セキュリティ チームは、FluentBit によるアクセスを必要なログのみに限定して修正しました。

Anthos Service Mesh に関しては、内部からの報告により、Google はすでに CNI DaemonSet に関連付けられた特権の高さについて認識していました。私たちが問題を報告した時点で Google による修正と権限の絞り込み処理がすでに行われており、現在この問題は修正済みになっています。

Unit 42 のリサーチャーは、最終的にはクラスター管理者権限への昇格が可能な、FluentBit の脆弱性と ASM の CNI DaemonSet 権限を組み合わせた攻撃チェーンを初めて確立しました。

私たちの勧告を受け、過去数週間にわたり、Google は FluentBit ボリューム マウントや Anthos Service Mesh の高い特権権限に対する修正と緩和策を展開しました。これらの施策は本稿に報告した攻撃を防ぎ、同様のエクスプロイトに対してプラットフォームを強化します。

Google は次のようにしてこれらの問題に対処しました。

• FluentBit の Pod から /var/lib/kubelet/pod ボリューム マウントを削除しました。これにより、ほかの Pod に対してプロジェクションされたサービス アカウント トークンへのアクセスを排除できます。
• ASM のクラスター ロール を修正し、機能の一部を再設計して、過剰な RBAC 権限を削除しました。

結論

Kubernetes は強力なコンテナー オーケストレーション プラットフォームで、あらゆる規模の組織がアプリケーションの実行にこれを使用しています。ただし状況によっては、システム Pod が組織のセキュリティ保護のおよばない領域となりかねません。

クラウド ベンダーはクラスターの起動時にシステム Podを自動的に生成します。これらは Kubernetes のインフラ内に構築されます。機能を有効化した場合に作成されるアドオン Pod も同様です。こうなっている理由は、クラウド ベンダーやアプリケーション ベンダーがそれらを作成・管理していて通常はユーザーがその構成や権限を制御できないためです。これらの Pod は昇格された特権で実行されていることから非常に危険でもあります。

本稿では、攻撃者がシステム Podとアドオン Pod の 2 つの問題を利用し、特権を昇格して管理者権限を得る方法について示しました。

パロアルトネットワークス製品による保護と緩和策

Prisma Cloud

パロアルトネットワークスの Prisma Cloud は、システム Pod やアドオン Pod を標的とする攻撃をはじめ、さまざまな脅威からの Kubernetes クラスター保護に役立てるために設計されたクラウド配信型セキュリティ プラットフォームです。

Prisma Cloud は、以下に役立つさまざまな機能を提供しています。

• クラスター内の不審なアクティビティを監視・検出します。
• システム Pod やアドオン Pod の構成ミスや過剰な権限を識別します。
• 攻撃者によるシステム Pod、アドオン Pod の構成ミスや脆弱性のエクスプロイトを防ぎます。

Prisma Cloud は Kubernetes クラスターのセキュリティを強化し、さまざまな脅威から保護します。

Cortex

Cortex XDR は、お使いのデジタル環境全体におよびうるインシデントのストーリーを包括的に描くことにより、SOC チームの能力を強化します。これは、Kubernetes Node と Kubernetes API Server の監査ログからのアクティビティ データ、エンドポイント データ、ネットワーク データを統合することによって実現されています。Cortex はこの情報を有効活用し、Kubernetes クレデンシャルの窃取、クリプトジャック、コンテナー エスケープ、そのほかのセキュリティ脅威など、確立された TTP (戦術・技術・手順) に一致する異常な Kubernetes 上のアクションを特定します。

侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、こちらのフォームからご連絡いただくか、下記の電話番号までお問い合わせください (ご相談は弊社製品のお客様には限定されません)。

• 北米フリーダイヤル: 866.486.4842 (866.4.UNIT42)
• EMEA: +31.20.299.3130
• APAC: +65.6983.8730
• 日本: (+81) 50-1790-0200

パロアルトネットワークスは、これらの調査結果を Cyber Threat Alliance (CTA: サイバー脅威アライアンス) のメンバーと共有しました。CTA のメンバーはこのインテリジェンスを使って、お客様に保護を迅速に提供し、悪意のあるサイバー攻撃者を体系的に阻害できます。詳細は Cyber Threat Alliance にてご確認ください｡

開示のタイムライン

• 2023 年 9 月 12 日: パロアルトネットワークス、二重特権昇格攻撃チェーンに関するレポートを Google に提出。
  同事象についてのクラウド脆弱性報奨金プログラム。
• 2023 年 9 月 13 日: Google セキュリティ チーム、弊社報告をセキュリティ上の問題として受理。
• 2023 年 10 月 24 日: Google セキュリティ チーム、弊社報告を「重要なセキュリティ コントロールの回避」として受理。
• 2023 年 11 月 24 日: パロアルトネットワークス、本稿公開の意向をGoogle に通知。本稿への修正ならびにフィードバックの機会を提供。
• 2023 年 12 月 11 日: Google セキュリティ チーム、本稿へのフィードバックを送付。
• 2023 年 12 月 14 日: Google セキュリティ チーム、同セキュリティ問題を修正。

追加リソース

• Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms – パロアルトネットワークス Unit 42
• コンテナーエスケープから「影の管理者」へ: GKE Autopilot の脆弱性 – パロアルトネットワークス Unit 42