昨年 4 月、私たちは Kubernetes の脅威マトリックスの最初のバージョンをリリースしました。これは、Kubernetes の脅威の状況を体系的にマッピングする最初の試みでした。前回の投稿で説明したように、脅威を記述するためのほぼ業界標準となった MITRE ATT&CK® フレームワークの構造を適応させることを選択しました。
昨年の脅威マトリックスの公開以降、状況は次のように変化しました。
- 攻撃者がより多くの Kubernetes ワークロードを標的にするにつれて、新しい脅威が発見されました。
- セキュリティ コミュニティがマトリックスを採用し、さらに技術を追加したことを嬉しく思います。
- Kubernetes が進化するにつれて、デフォルトでより安全になり、一部の手法はもはや関連しなくなります。
本日、これらの変更を考慮した Kubernetes の脅威マトリックスの 2 番目のバージョンをリリースします。更新されたマトリックスには、Microsoft の研究者によって発見された新しい手法と、コミュニティによって提案された手法が追加されています。また、新しいバージョンの Kubernetes には適用されなくなったいくつかの手法を廃止します。このバージョンでは、MITRE ATT&CK® コレクションから取られた新しい戦術も追加します。
廃止されたものは何ですか?
Kubernetes は進化し、デフォルトでより安全になりました。昨年のマトリックスに登場したテクニックは、新しい環境には関係ありません。そのため、一部の手法を非推奨にすることにしました。
公開された Kubernetes ダッシュボード
Kubernetes ダッシュボードの使用は、しばらくの間減少しています。 Microsoft の AKS や Google の GKE などのクラウド管理クラスターは、このサービスを廃止し、ポータルの集中型インターフェイスに移動しました。さらに、Kubernetes ダッシュボードの最近のバージョンでは認証が必要であり、認証を必要としない公開されたダッシュボードが見つかる可能性は低くなります。その結果、ラテラル ムーブメント戦術の下にある「 Kubernetes ダッシュボードにアクセスする 」という手法も削除しました。ダッシュボードが手動でインストールされた新しいクラスターを含む、古いバージョンの Kubernetes は、依然としてこの手法の影響を受けます。この手法の概念は、機密性の高いインターフェイスを公開するという新しい手法で一般化されました (以下を参照)。
耕うん機のエンドポイントにアクセスする
バージョン 3 の時点で、Helm はそのサーバー側コンポーネントである Tiller を使用しません。これは、Helm のセキュリティの大幅な改善です。現在、Helm は (デフォルトで) kubeconfig ファイルに表示されるユーザーの資格情報に代わって動作します。古いバージョンの Helm のユーザーは、依然としてこの手法の影響を受けます。
脅威マトリックスの新しい手法
1. 初期アクセス
機密性の高いインターフェースの公開
機密性の高いインターフェイスをインターネットに公開すると、セキュリティ リスクが生じます。一部の一般的なフレームワークは、インターネットに公開することを意図していないため、デフォルトで認証を必要としません。したがって、それらをインターネットに公開すると、機密性の高いインターフェイスへの認証されていないアクセスが可能になり、悪意のあるアクターがコードを実行したり、クラスターにコンテナーをデプロイしたりする可能性があります。悪用されたインターフェイスの例としては、Apache NiFi、Kubeflow、Argo Workflows、Weave Scope、Kubernetes ダッシュボードなどがあります。
2.実行
サイドカー インジェクション
Kubernetes Pod は、共有ストレージとネットワーク リソースを持つ 1 つ以上のコンテナーのグループです。サイドカー コンテナーは、メイン コンテナーの横にある追加のコンテナーを表すために使用される用語です。たとえば、サービス メッシュ プロキシは、アプリケーションのポッドでサイドカーとして動作しています。攻撃者は、クラスター内で独自の個別のポッドを実行する代わりに、サイドカー コンテナーをクラスター内の正当なポッドに挿入することで、コードを実行し、活動を隠すことができます。
3.持続性
悪意のあるアドミッション コントローラ
受付コントローラーは、Kubernetes API サーバーへの要求をインターセプトし、場合によっては変更する Kubernetes コンポーネントです。受付コントローラーには、検証コントローラーと変更コントローラーの 2 種類があります。名前が示すように、変更受付コントローラーは、傍受された要求を変更し、そのプロパティを変更できます。 Kubernetes には、 MutatingAdmissionWebhookという名前の組み込みの汎用アドミッション コントローラーがあります。このアドミッション コントローラーの動作は、ユーザーがクラスターにデプロイするアドミッション Webhook によって決まります。攻撃者は、このような Webhook を使用して、クラスター内の永続性を得ることができます。たとえば、攻撃者はクラスター内のポッド作成操作を傍受して変更し、作成されたすべてのポッドに悪意のあるコンテナーを追加できます。
4.資格情報へのアクセス
マネージド ID 資格情報にアクセスする
マネージド ID は、クラウド プロバイダーによって管理され、仮想マシンなどのクラウド リソースに割り当てることができる ID です。これらの ID は、クラウド サービスでの認証に使用されます。 ID のシークレットはクラウド プロバイダーによって完全に管理されるため、資格情報を管理する必要がなくなります。アプリケーションは、Instance Metadata Service (IMDS) にアクセスして ID のトークンを取得できます。 Kubernetes ポッドにアクセスできる攻撃者は、IMDS エンドポイントへのアクセスを利用して、マネージド ID のトークンを取得できます。トークンを使用すると、攻撃者はクラウド リソースにアクセスできます。
悪意のあるアドミッション コントローラ
永続性に加えて、悪意のあるアドミッション コントローラーを使用して資格情報にアクセスできます。 Kubernetes の組み込みアドミッション コントローラーの 1 つはValidatingAdmissionWebhookです。 MutatingAdmissionWebhookと同様に、このアドミッション コントローラーも汎用的であり、その動作はクラスターにデプロイされたアドミッション Webhook によって決定されます。攻撃者はこの Webhook を使用して、API サーバーへのリクエストを傍受し、シークレットやその他の機密情報を記録できます。
5.横移動
CoreDNS ポイズニング
CoreDNS は、Go で記述されたモジュール式のドメイン ネーム システム (DNS) サーバーであり、Cloud Native Computing Foundation (CNCF) によってホストされています。 CoreDNS は、Kubernetes で使用されている主要な DNS サービスです。 CoreDNS の構成は、corefile という名前のファイルによって変更できます。 Kubernetes では、このファイルは kube-system 名前空間にある ConfigMap オブジェクトに保存されます。攻撃者が、たとえばコンテナーのサービス アカウントを使用して ConfigMap を変更する権限を持っている場合、クラスターの DNS の動作を変更し、それを汚染し、他のサービスのネットワーク ID を取得することができます。
ARPポイズニングとIPスプーフィング
Kubernetes には、クラスターで使用できる多数のネットワーク プラグイン (コンテナー ネットワーク インターフェイスまたは CNI) があります。 Kubenet は基本であり、多くの場合デフォルトのネットワーク プラグインです。この構成では、veth ペアを使用してさまざまなポッドが接続されている各ノード (cbr0) にブリッジが作成されます。クロスポッド トラフィックがレベル 2 コンポーネントであるブリッジを通過するという事実は、クラスターで ARP ポイズニングを実行できることを意味します。したがって、攻撃者がクラスター内のポッドにアクセスすると、ARP ポイズニングを実行し、他のポッドのトラフィックをスプーフィングできます。この手法を使用することで、攻撃者はネットワーク レベルでいくつかの攻撃を実行でき、DNS スプーフィングや他のポッドのクラウド ID の盗用など、横方向の動きにつながる可能性があります (CVE-2021-1677)。
6. コレクション
今回のアップデートでは、脅威マトリックスに新しい戦術である収集も追加しました。 Kubernetes では、コレクションは、攻撃者がクラスターから、またはクラスターを使用してデータを収集するために使用する手法で構成されます。
非公開レジストリからの画像
クラスターで実行されているイメージは、プライベート レジストリに格納できます。これらのイメージをプルするには、コンテナー ランタイム エンジン (Docker や containerd など) が、それらのレジストリーに対する有効な資格情報を持っている必要があります。レジストリがクラウド プロバイダーによってホストされている場合、Azure Container Registry (ACR) や Amazon Elastic Container Registry (ECR) などのサービスでは、レジストリに対する認証にクラウド資格情報が使用されます。攻撃者がクラスターにアクセスできる場合、場合によってはプライベート レジストリへのアクセスを取得し、そのイメージをプルできます。たとえば、「マネージド ID 資格情報へのアクセス」手法で説明されているように、攻撃者はマネージド ID トークンを使用できます。同様に、EKS では、攻撃者はデフォルトでノードの IAM ロールにバインドされている AmazonEC2ContainerRegistryReadOnly ポリシーを使用できます。
コンテナ化された環境を保護する
コンテナ化された環境の攻撃面を理解することは、これらの環境向けのセキュリティ ソリューションを構築するための最初のステップです。改訂された Kubernetes の脅威マトリックスは、組織が Kubernetes を標的とするさまざまな脅威に対する防御範囲の現在のギャップを特定するのに役立ちます。
Azure Defender を使用してコンテナー化された環境の保護を今すぐ開始することをお勧めします。 コンテナー セキュリティに対する Azure Defender のサポートの詳細を確認してください。
Microsoft セキュリティ ソリューションの詳細については、当社の Web サイトをご覧ください。 セキュリティ ブログをブックマークして、セキュリティに関する専門家の記事を入手してください。また、 @MSFTSecurityをフォローして、サイバーセキュリティに関する最新ニュースと更新情報を入手してください。
Comments