エクスプロイト&脆弱性
過剰特権のコンテナ経由でデータ盗聴：AWS認証情報を露呈させる概念実証を検証
Amazon EKS内のコンテナに設定不備がある / 過剰な特権が付与されている場合、機密性の高いAWS認証情報がパケットスニッフィングやAPI通信の盗聴などの脅威にさらされる可能性があります。これらのリスク低減のために最小特権の原則やプロアクティブセキュリティの導入が推奨されます。
- Kubernetes環境内のコンテナに設定不備がある / 過剰な特権が付与されている場合、機密性の高いAWS認証情報への不正アクセスを容易にし、同環境で特権昇格や不正活動が実施される可能性があります。
- Trend™ Researchは、攻撃者が過剰な特権の付与されたコンテナを悪用する手口などを検証しました。当検証では、通信内容が暗号化されないHTTPトラフィックを盗聴して平文の認証情報を窃取するパケットスニッフィングの手口や、ネットワーク設定を不正に操作して認証トークンを取得（API通信の盗聴）し、特権昇格による不正アクセスを実行する手口などを特定しました。
- AWSにおける責任共有モデルは、サービス提供企業側（Amazon）がインフラ設備の安全性を確保する一方で、ユーザ側では安全なクラウド環境を維持するためにコンテナ化されたアプリケーション内に付与する特権範囲（スコープ）を自身で運用管理するという、各々の範囲をサービス提供企業とユーザが共同で責任を持つ考え方のことです。
- トレンドマイクロが提供するコンテナ環境の保護対策「Trend Vision One™ - Container Security」は、組織の意図する特権レベルを超えて動作するコンテナを検出し、リスクを軽減するための包括的なセキュリティポリシーの適用を可能にします。これにより、パケットスニッフィングやAPI通信の盗聴などの悪用手口が阻止され、攻撃対象領域（アタックサーフェス）を縮小してセキュリティリスクを最小限に抑止することができます。
Kubernetesベースのコンテナプラットフォームは、コンテナ化されたアプリケーションをクラウド内で効率的かつ大規模に相互連携させて運用管理する際に重要な役割を担います。これらのプラットフォームは、コンテナ化されたアプリケーションの展開、スケーリング（リソースの調整）、運用管理を自動化するため、マイクロサービスや様々なワークロードを構築する上で最適と言えます。主な利点としては、ポータビリティ（他環境への移行が容易｟可搬性｠）、リソース配分最適化によるコスト効率の最大化、自動化・自己修復による開発サイクルの加速化、分散システムにおける管理の簡素化などが挙げられ、これらすべてが弾力性や拡張性のあるアプリケーション開発を可能にします。
Amazon社が提供するマネージドサービス「Amazon Elastic Kubernetes Service（EKS）」は、AWS（Amazon Web Services）やオンプレミス上でのKubernetes実行を効率化させます。Amazon EKSは、Kubernetesコントロールプレーンの運用管理を自動化して高可用性や拡張性を確保するほか、別のAWSサービス（ネットワーク、セキュリティ、ストレージ）との円滑な統合を可能にします。これによりユーザは、コンテナ化されたアプリケーションの展開や運用管理に注力できるようになります。
ただし、それらのコンテナに設定不備がある / 過剰な特権が付与されている場合、同環境内の機密データやシステムリソースの制御 / 不正アクセスに悪用される可能性があるため、重大なセキュリティリスクをもたらすおそれがあります。このため、最小限の権限を付与するなど、コンテナを適切に構成することは、安全なコンテナインフラストラクチャを維持する上で極めて重要です。
本ブログ記事では、過剰な特権が付与されたコンテナに概念実証コードを用いた場合に想定される「パケットスニッフィングの手口」や「API通信の盗聴手口」の検証結果を解説します。本検証は、これらの設定不備によりAWS上のコンテナ化されたアプリケーション内から機密性の高いセキュリティ認証情報が直接窃取される手口を明らかとし、クラウド環境内の重大な懸念事項に対して適切な保護対策を実施する際に役立てることが目的です。
AI搭載型エンタープライズサイバーセキュリティプラットフォーム「Trend Vision One™」をご利用のお客様においては、Trend Vision Oneコンソールにログインして左ペインにある「Cloud Security」→「Container Security」→「Container Protection」内で独自のカスタムポリシーを作成・適用し、それらのルールセットに違反するコンテナアクティビティを可視化/検出して対処する方法をお伝えします。
攻撃者がAmazon EKS Pod Identityサービスを潜在的に悪用する手口
Amazon EKS Pod Identityは、EKSクラスタ内で動作するPodにAWS認証情報を付与する処理を簡素化するためにAWSによって導入された機能です。同機能は、IRSA（IAM Roles for Service Accounts）に代わる仕組みとしてPodにIAM（Identity and Access Management）ロールを割り当てることで、Kubernetes上のアプリケーション（Pod）内からAWSリソース（S3バケットやDynamoDBテーブルなど）へのセキュアなアクセスを可能にします。
Amazon EKS Pod Identityエージェントをセットアップする場合、Amazon EKSクラスタ上にeks-pod-identity-agentアドオンをインストールします。当エージェントは、名前空間「kube-system」内のDaemonSetとして動作し、同エージェントのインスタンスが各ワーカーノードで実行されていることを保証します。
同エージェントは、Authorizationヘッダ内にKubernetesサービスアカウントトークンを受け入れた後、以下のAWS EKS Auth APIでアクションを実行するシンプルなAPIを露呈します。
当APIは、ポート番号80上のリンクローカルアドレス（IPv4では「169.254.170.23」、IPv6では「[fd00:ec2::23]」）にて公開されます。
EKS Pod Identity Webhook経由で動作するアドミッションコントローラ「mutating admission controller」は、Pod Identityに関連付けられたサービスアカウントを使用するPod内に以下の環境変数を自動的に注入（インジェクション）します。
AWS_CONTAINER_CREDENTIALS_FULL_URI
AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
注入されたこれらの環境変数は、AWS SDK（ソフトウェア開発キット）によって認識されます。
AWS SDKを使用するPod内のアプリケーションがAWSサービスにリクエストを行う際、SDKは関連する環境変数を自動的に識別し、ノード上で実行されているEKS Pod Identityエージェントから一時的な認証情報を取得します。その後、同エージェントは、EKS Auth APIで「AssumeRoleForPodIdentity」アクションを実行するAPIとやり取りし、関連付けされたIAMロールに必要な認証情報を取得します。
同条件下で想定されるパケットスニッフィングの手口
EKS Pod Identityエージェントは各ノード上で動作し、通信内容が暗号化されないHTTP経由でローカルIPアドレス上のAPIを公開します。
上記の状況は、セキュリティリスクを招く原因となり得ます。hostNetworkがtrueに設定されたPodは、潜在的にノード上のネットワークトラフィックを監視できるようにするため、APIエンドポイント「169.254.170.23:80」から送信される認証情報が盗聴されるおそれがあるためです（図1）。AWS環境では、これらの認証情報が特定の資産に紐づけ（バインド）されないため、攻撃者はそれらを悪用して同環境内で特権を昇格させる可能性があります。
当検証に用いた概念実証（Proof of Concept、PoC）コードにより、認証情報が平文で送信されていることが実証されています（図1）。当コードには、多くのLinux系OSに標準搭載されているコマンドラインユーティリティ（CLU）「tcpdump」を使用しました。既述の通りAWS認証情報は、特定のホストに紐づけされないため、第三者が特権昇格に悪用する可能性があります。
同条件下で想定されるAPI通信の盗聴手口
hostNetworkが有効なPodから「CAP_NET_RAW」ケーパビリティを削除したとしても、ネットワークインタフェースの操作を許可する別のケーパビリティ（「CAP_NET_ADMIN」など）が有効になっている場合は、API通信の盗聴されるリスクを完全に軽減できない可能性があります。攻撃者がPodのNIC（ネットワークインターフェースカード）設定を操作できる限り、プロセスに関連付けされたローカルリンクアドレスを削除することで、ノード上で動作するEKS Pod Identityエージェント（Daemonset）のHTTP通信を無効化することができます。これにより攻撃者は、APIエンドポイント「169.254.170.23:80」上で実行されているHTTPサービスを制御し、独自のHTTPサーバを展開できるようになります。その後攻撃者は、独自のサーバを介して認証トークンを含むHTTPリクエストを盗聴し、有効なAWS認証情報を取得する可能性があります。
トレンドマイクロはPythonで書かれた概念実証コードを開発し、pyroute2などの一般的なライブラリを利用して、上記の状況が悪用可能であることを実証しました。
まとめとセキュリティ上の推奨事項
本検証により、Kubernetes環境内でAWSリソースへのアクセスを簡素化させる機能「Amazon EKS Pod Identity」の使用時にセキュリティ上の重大な考慮事項があることが判明しました。これらの設定不備（特にコンテナに過剰な特権が付与された状態など）は、AWS認証情報を露呈させ、クラウド環境内での特権昇格や不正活動を含む重大なセキュリティリスクを招く可能性があります。
本記事では、「パケットスニッフィングの手口」や「API通信の盗聴手口」の概念実証を通じて、過剰な特権の付与されたコンテナが悪用された場合に機密データが盗聴されたり不正にアクセスされたりする可能性について解説しました。これらのセキュリティ上の考慮事項は、企業や組織が最小特権の原則を遵守してコンテナに付与する特権範囲を適切に管理し、潜在的な悪用機会を最小限に抑えることの重要性を浮き彫りにしています。
セキュリティベンダによる情報提供および対策
上記の手口2つは、トレンドマイクロの運営する脆弱性発見コミュニティ「Zero Day Initiative™（ZDI）」の脆弱性発見報奨金制度（バグバウンティプログラム）を通じてAmazon社に報告された後、「ZDI-CAN-26891」として記録されています。AWS社の声明は以下の通りです。
「弊社のチームは当調査を完了し、報告書の動作がセキュリティ上の問題ではなく、ノードの信頼境界線内で想定された動作であり、責任共有モデルにおいて責任範囲がお客様側にあると判断しました。アプリケーションに適切な範囲で特権が付与されていることを確認するのは、ノードまたはクラスタを運用管理するお客様側の責任です。EKS Pod IdentityがPodにIAMロールの認証情報を割り当てる機能は想定されたものであるほか、Amazon EKSのPodに対するセキュリティのベストプラクティスと責任共有モデルに係る文書に概説のように、各々の範囲をサービス提供企業とユーザが共同で責任を持つ考え方と一致しています。」
過剰な特権の付与されたコンテナをTrend Vision One™で特定して防止する
コンテナ機能の包括的な運用管理は、コンテナ環境を保護するために不可欠な側面です。コンテナ構成時に最小特権の原則を採用することは、攻撃対象領域（アタックサーフェス）を最小化し、潜在的なセキュリティリスクを低減させる上で非常に重要です。
コンテナに付与された過剰な特権を検出する
AI搭載型エンタープライズサイバーセキュリティプラットフォーム「Trend Vision One™」のコンテナ保護対策「Container Security」では、組織の意図する特権レベルを超えて動作するコンテナを検出するセキュリティポリシーを策定し、それらのルールセットに違反するコンテナアクティビティの可視化/検出/実行阻止が可能となります。上記の想定手口は、CAP_NET_RAW、CAP_NET_ADMIN、またはhostNetworkがtrueに設定されたPodなど、過剰な特権の付与されたコンテナに起因します。
ポリシー設定は、Trend Vision Oneコンソールにログインし、左ペインにある「Cloud Security」→「Container Security」→「Container Protection」からアクセスでき、設定に係る様々なオプションがご利用いただけます。本記事で解説した過剰な特権付与に対処する場合は、「Pod properties」セクション内の「containers that run in the host network namespace」を選択し、ドロップダウンリストから「Log」または「Block」に設定してレ点を入れます。併せて「containers with capabilities that do not conform with a Baseline policy」を選択し、ドロップダウンリストから「Log」または「Block」に設定してレ点を入れます（図3）。
Kubernetes保護ポリシーの作成と利用方法に係る詳細情報は、以下のTrend Vision Oneドキュメントをご参照ください。
上記のポリシーが設定されると、図4の例に示すように違反が検出されるようになります。
参考記事：
An Investigation of AWS Credential Exposure via Overprivileged Containers
By: Jiri Gogela
翻訳：益見 和宏（Platform Marketing, Trend Micro™ Research）