Kubernetesの調査事例から考える、クラウドペネトレーションテストの必要性

こんにちは、デジタルペンテスト部の井上です。

近年の大規模なインターネットサービス開発では、保守性を考慮して小さな機能単位でサービスを実装する、マイクロサービスアーキテクチャを採用することが多くなり、コンテナ技術の利用が増加しています。また、コンテナオーケストレーションツールの「Kubernetes」（以下、「k8s」）の、クラウドサービス上での構築も注目されています。k8sは、多くのユーザのサービス利用を想定したコンテナのデプロイや管理などを自動化するツールで、インフラをスケールできるメリットがあります。

しかし、クラウドサービスを使っているがゆえに、オンプレミス環境でk8sを単体で稼働させているときに考慮すべきセキュリティ設定に加え、クラウドサービス特有のセキュリティ設定も同時に考慮する必要があります。そうでなくてもクラウドサービスのセキュリティ設定は複雑なのですが......。

そこで、クラウド環境がゼロデイ脆弱性などにより攻撃者に侵入された場合を想定して、攻撃者に拡大されうる侵入範囲や攻撃者の目的達成の可否からセキュリティ対策上の問題点を調査し、一般的な対策方法や実際の運用にあわせた改善点を報告する、クラウドペネトレーションテストをご紹介します。

調査内容

ペネトレーションテストを実施する上で重要となるのが、「調査対象（＝スコープ）」および「攻撃目標（＝ゴール）」の設定です。

クラウドサービスに限らず、情報システムへのペネトレーションテストは大きく2種類あります。調査対象として、例えばクラウドサービスであればクラウド環境のインスタンスや管理コンソールなどに侵入できるかなどのように、プラットフォーム自体へ侵入できるか調査する「Black Box Engagement」と、プラットフォームへの侵入に成功した攻撃者が、どの程度まで侵入範囲を拡大できるかを調査する「Post-Exploitation Assessment」です。

クラウドサービスを対象とするペネトレーションテストにおいて、「Black Box Engagement」調査では、クラウドサービス固有の問題点を悪用してクラウド環境に侵入することはまれです。そのため、手法の多くは一般的な情報システム環境におけるものと同様のものを用います。この記事で紹介する「k8s on クラウドサービス」のような環境で、クラウド固有のセキュリティ上の問題点について調査したい場合は、コンテナ上で動作するアプリケーションが侵害されるなど、すでに攻撃者がコンテナに侵入していることを前提条件に、侵入されるおそれのあるコンテナおよびそのホストを起点とした「Post-Exploitation Assessment」調査を行うことをおすすめします。

調査内容は、一般的なサーバへのペネトレーションテストの調査に加え、k8sであるがゆえの調査や、クラウドサービス上で動作しているがゆえの調査など、ありとあらゆる視点から疑似攻撃を試行していくことになります。実際の攻撃者は、自由にクラウドサービスのリソースを操作し機密情報を窃取すること、またリソース自体を悪用することを攻撃目標（＝ゴール）としていると考えられるため、ペネトレーションテストにおいても同様の攻撃目標を設定します。これらの目標を達成するには、クラウドサービス自体の認証情報を窃取可能か否かが攻撃の鍵となるので、クラウドサービスのペネトレーションテストでの調査内容は主に以下のようになります。

• k8sの管理者権限が窃取可能か
• クラウドサービスの管理者権限が窃取可能か
• その他サービスの認証情報を窃取可能か

これらの調査内容の下、コンテナ侵入時における認証情報窃取、窃取可能な認証情報での権限昇格、窃取可能な機密情報を深堀して攻撃目標の達成可否を調査していきます。

調査事例

Amazon EKSで構築したk8s環境をペネトレーションテストする際に、コンテナ内から窃取されうる認証情報の調査事例を紹介します。

k8sサービスアカウントの権限窃取

k8sで作成されたコンテナには、コンテナに割り当てられたJWT（JSON Web Token）や証明書といったk8sサービスアカウントの認証情報が、以下のパスで示すディレクトリに保存されています。

• /var/run/secrets/kubernetes.io/serviceaccount 等

ここに保存される認証情報を窃取した攻撃者は、サービスアカウントに割り当てられている権限の範囲内ではありますが、k8sのAPIを通してクラスタを操作することが可能となります。

例えば、一部のコンテナでk8sクラスタを制御する必要があったため、デフォルトサービスアカウントに対して、cluster-adminという高権限なクラスタロールを付与して運用していたとします。その場合、サービスアカウントを明示的に指定せずにデプロイされているコンテナではデフォルトでこのサービスアカウントが割り当てられるため、攻撃者がいずれかのコンテナへの侵入に成功した場合は、クラスタ全体の制圧が可能です。その結果、k8sに悪意のあるコンテナをデプロイされバックドアとして悪用されることや、Secretsの内容を閲覧されて重要情報が漏えいする恐れがあります。

IAMロールの権限窃取

Amazon EKSといえど、コンテナが動作するノードはEC2としてAWS上で構築されます。そのため、IAMロールをそのEC2に割り当てている場合、以下のURLからインスタンスメタデータサービス（IMDS）へアクセスすることが可能です。

• http[:]//169[.]254.169.254/latest/meta-data/

コンテナ上からIMDSへアクセスすることで、そのノードのIAMロールの権限を窃取可能です。この権限を窃取した攻撃者は、IAMロールに割り当てられている権限の範囲内ではありますが、AWSアカウント上のリソースを操作することが可能となります。

例えば、コンテナ内からAWSアカウント上のS3リソースへアクセスする必要があったため、コンテナがデプロイされるホストノードのEC2のIAMロールにS3に対するフル権限（AmazonS3FullAccessポリシーなど）を付与して運用していたとします。その場合、上記の手法のIMDSで割り当てられているIAMロールの権限を窃取可能なため、このIAMロールが割り当てられているEC2インスタンス上のコンテナへの侵入に成功した場合は、AWSアカウント上のS3へ自由にアクセスが可能です。その結果、AWSアカウント上に存在するS3バケットの一覧や、バケット内のオブジェクト自体が漏えいする恐れがあります。

窃取したIAMから副次的に他サービスの認証情報を窃取

上記の「IAMロールの権限窃取」による方法や、脆弱性の悪用、認証情報の漏えいなどからなにかしらのIAMが窃取可能であった場合、そのIAMに付与されている権限によっては、副次的にAWS上の他のクラウドサービスで使用する別の認証情報を窃取可能な場合があります。特にEKSで構築されたk8sノードから窃取したIAMロールの権限の場合、「k8sのAPIを操作可能な認証情報」や「Amazon ECRに保存するコンテナイメージを取得可能な認証情報」などが窃取可能な場合があります。

「k8sのAPIを操作可能な認証情報」が窃取可能な場合、「k8sサービスアカウントの権限窃取」と同様、攻撃者は割り当てられているk8sの権限の範囲内でクラスタを操作することが可能です。また、ここで窃取できる権限は、上の「k8sサービスアカウントの権限窃取」で窃取できる権限よりも多くの権限を持っている場合があり、侵入範囲の拡大に悪用される恐れがあります。

また、「Amazon ECRに保存するコンテナイメージを取得可能な認証情報」が窃取可能な場合、攻撃者はECRに保存されているコンテナイメージへアクセスすることが可能です。その結果、ソースコードや実行バイナリなどのアプリケーション情報や、ハードコードされている認証情報などの機密情報が漏えいする恐れがあります。

k8sのPod情報から認証情報を窃取

適当な権限を持ったk8sアカウントを持っている場合、k8sのAPIを通してPod情報を閲覧することが可能です。kubectlコマンドでは、「kubectl get describe pods」を実行した結果がそれに相当します。

コンテナをdocker単体で使用している場合などで特に、アプリケーションで使用するデータベースのアクセス先や認証情報など可変的な情報は環境変数に設定するよう指定して、コンテナを起動することが多いかと思います。k8s環境でも同様に環境変数を設定するよう指定してコンテナを起動することが可能です。しかし、ここで指定した値は、Pod情報閲覧APIを通して表示されてしまいます。

上記で紹介しましたが、k8sアカウントは「k8sサービスアカウントの権限窃取」や「窃取したIAMから副次的に他サービスの認証情報を窃取」といった方法で攻撃者に窃取される恐れがあります。当該アカウントにPod情報を閲覧する権限が付与されていた場合、攻撃者は、k8sのAPIを通してデータベースへのアクセス情報を窃取することが可能となります。その結果、データベースへの侵入を許し、機密情報が漏えいする恐れが生じてしまうことになります。

原因と対策・緩和策

ここまで調査事例を見てきましたが、「k8sサービスアカウントの権限窃取」では、クラスタ管理者という明らかに大きすぎる権限をデフォルトサービスアカウントという汎用的なサービスアカウントに与えてしまっていたことが原因です。このような場合、クラスタ制御用のサービスアカウントを別に作成し、クラスタの制御に必要な権限のみを付与してコンテナをデプロイすべきと考えます。

また、「IAMロールの権限窃取」では、IAMロールの権限はIMDSで簡単に取得できるという仕様を把握していないこと、さらにk8sサービスアカウントと同様、S3へのフルアクセス権限という大きな権限をIAMロールに与えてしまっていたことが原因です。このような場合、操作可能なS3バケットを限定することや、目的に応じた操作権限のみを付与することを徹底すべきと考えます。例えばバックアップ目的であればPUT権限があれば十分です。

このように、問題点の多くは「人為的な設定ミス」に起因していることがお分かりいただけると思います。特に、クラウドサービスの仕様や特性をあまり理解しないまま設定してしまったことが問題点の一因ともいえるでしょう。

今回の調査事例で紹介した問題点では、以下のような対策を行うことで、問題点を解決および緩和することが可能です。

• k8sサービスアカウントやIAMロールに付与する権限は最小にすること。（最小権限の原則）
• IAMロールの権限を使用できるホストを限定すること。
• 重要情報はk8sのSecretsやサードパーティのkeyVaultなどでの管理を徹底すること。

おわりに

APT攻撃が増加したこともあり、Active Directoryで管理される社内システムのOAネットワークへのペネトレーションテストは、比較的一般的になってきて認知度も高いのではと思います。一方でクラウド、特にk8sのようなコンテナ環境は、設定の複雑さからセキュリティ上の懸念が残るにもかかわらず多くのインターネットサービスで広く利用されており、攻撃者もそこに目を光らせています。しかしながら、これらの環境に対するペネトレーションテストは国内ではまだまだ実施されることが少なく認知度も低いものです。

ラックの「ペネトレーションテスト」サービスでは、OAネットワークのみならず、このようなクラウド・コンテナ環境へのペネトレーションテストも実施することが可能です。クラウド環境に対してもペネトレーションテストサービスを実施いただくことで、ペンテスターがハッカー目線でお客様の環境を疑似攻撃します。その結果、攻撃による侵害可能範囲や窃取可能な重要情報を探索し現在のセキュリティ設定を検証可能です。また、そこに至るまでに悪用した問題点とその対策方法を分析しますので、お気軽にご相談ください。