Unit 42、AWS IAMの偵察で漏えいした情報を特定するオープンソースツールIAMFinderを公開

< 1 min read

著者:
- Jay Chen
公開日:December 28, 2020
カテゴリー
- セキュリティ技術
- 脅威リサーチ
タグ:

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

概要

Unit 42 は最近、「情報漏えいを引き起こす可能性があるAWS リソースベースのポリシー API を確認」というブログで、アマゾンウェブサービス (AWS) の API のクラスを悪用することにより、任意のアカウントに存在するユーザーや IAM (Identity and Access Management) ロールを見つけ出すことができる、という内容を公開しました。この問題の根本的原因は、AWSバックエンドがすべてのリソースベースのポリシーを検証し、指定されたプリンシパルが存在しない場合にアラートを発生させる点にあります。この機能を悪用すれば、ユーザーやロールが対象アカウントに存在するかどうかを確認することができます。攻撃者は名前をさまざまに変えつつ問いかけを続けることで、最終的には対象アカウントのすべてのユーザー、ロールをマッピングすることができます。このプロセスは、攻撃者がまず標的に関する公開済み情報を収集し、それにもとづいてテスト用単語リストを作成することでさらに容易になります。いったん組織の名簿を取得してしまえば、それを使って構成ミスのあるIAMロールの検索したり、スピアフィッシングメールを送信するなど、攻撃者はべつの標的型攻撃を仕掛けられるようになります。

この知見に基づき、 Unit 42はIAMFinderというカスタムオープンソースツールを開発しました。本ツールは現在 Amazon Simple Storage Service (S3)、Amazon Key Management Service (KMS)、Amazon Simple Queue Service (SQS)、AWS Identity and Access Management (IAM) の4つのAWSサービスのAPIを実装しています。対象アカウントのAWSアカウントID番号さえわかれば、IAMFinderはその環境のユーザーやロールを識別できます。したがって、組織がこのツールを使ってIAMの偵察から漏えいした情報を特定し、IAMの構成見直しと強化を重ねれば、AWSアカウントのユーザーとロールを把握している攻撃者から受ける潜在的影響を緩和することができます。

IAMFinderの主な特徴は次のとおりです。

攻撃者がとる行動をリアルにシミュレーション: 実際に悪意のある攻撃が行われた場合同じで、対象のアカウントがユーザーやロールを列挙されていることに気づくことはありません。列挙は、使用したアカウント上で実行され、ログは使用したアカウント上にのみ表示されるからです。ただし対象となったアカウントは、IAMFinderがロールを引き受けようとすればそれには気づくでしょう。
高速な列挙: IAMFinderは、次の方法で、対象アカウントのユーザーやロールをすばやく列挙できます。
- テスト実行用アカウントで複数のAWSサービス (S3、KMS、IAMなど) のAPIを同時に呼び出す
- 複数のAWSアカウントを使って並行でテストを実行
モジュール化されているので拡張が可能: こちらの情報漏えいに関するブログで説明したAWSのAPIを追加で実装して統合することができます。
クロスパーティション: IAMFinderは、AWS Standard (aws) 、AWS GovCloud US(aws-us-gov)、AWS China (aws-cn)の3つのAWSパーティションすべてでテスト済みです。
コスト不要: IAMFinderが各サービスで作成するリソースは実際のワークロードがないのでコストが発生しません。

ユースケース

構成ミスのあるIAMの信頼ポリシーの検索に: このツールを使えば、IAMのユーザーやロールを列挙できます。したがってそうしたIAMエンティティを特定することで構成ミスをテストするプロセスを開始できます。私たちUnit 42のリサーチャーが最近行ったレッドチーム演習では、構成ミスのあるIAMロールを使って、数万のワークロードを持つクラウドアカウントへの特権アクセスを得ることに成功しました。そのさい私たちは、対象アカウントに匿名ユーザーによるロール引き受けが可能な構成ミスを含むロールを特定していました。こうした構成ミスがあれば、ランサムウェア攻撃など、組織に対する攻撃がいくらでも発生する可能性がありますし、高度かつ持続的な脅威攻撃者 (APT攻撃者) を招き入れる事態にすら繋がりかねません。

資格情報をもっとも強化すべき箇所の把握に: Unit 42の最新クラウド脅威レポートからは、南北アメリカのIAMユーザーの46％が多要素認証 (MFA) を実施していないことがわかっています。通常、1つのクラウドアカウントには数十〜数百のユーザーが存在しているということを勘案すれば、MFAを有効にしていないクラウドアカウントの既存ユーザーを識別することで、攻撃者は資格情報のクラッキング攻撃やクレデンシャルスタッフィング攻撃 (資格情報を対象としたパスワードリスト型攻撃) などを試みることができるようになります。組織でIAMFinderを使えば、クラウドインフラにハッカー側の視点を得らることができます。IAMFinderに検出されたユーザーはより攻撃対象になりやすいことから、つねに強力なパスワードとMFAを設定しておくべきです。

クラウド環境の偵察に: システム管理者は、機能にもとづいてIAMロールに名前を付けることが多いので、たとえばAWS Lambda関数の実行に「ecsTaskExecutionRole」という名前を使ったり、AWS CodeDeployの管理に「AWSCodeDeployRole」という名前を使ったり、S3バケットへのアクセスに「S3Access」という名前を使ったりします。これはつまり、攻撃者は既存ロールを観察すればクラウドアカウントのワークロードの種類とその機能を知ることができる、ということです。そこで、組織でIAMFinderを使い、クラウドインフラ内にあるジェネリックなロール名を識別し、ランダムな文字をいくつか追加しておくことにより、ロール名を見つかりにくくすることができます。

CI/CDパイプラインとの統合に: クラウド環境のユーザーやロールは、さまざまなアプリケーションの要件に合わせて始終更新されていますので、IAMのドリフトを監視して、セキュアでない構成が新たに入り込んでいないかどうかを特定することが重要です。IAMFinderをCI/CDパイプラインに統合して、クラウド環境のユーザーやロールに対して承認なしのスキャンを実行することで、さらに安全性を高めるべき構成がないかを特定することができます。

設計と評価

IAMFinderのアーキテクチャでは、マルチスレッドで複数のリソースに並行してアクセスし、ラウンドロビン方式でアカウントとサービスを切り替えます。 — 図1 IAMFinderのアーキテクチャ

図1はIAMFinderのアーキテクチャを示したものです。IAMFinderには、テストの実行に必要とされる権限を持つAWSアカウントが少なくとも1つ必要です。テストに必要な権限についてはこちらの手順ページに詳しく説明してありますので参照してください。IAMFinderは単語リストとAWSアカウントのID番号を入力として受け取って、見つかった実在の名前リストを出力します。IAMFinderは、1つまたは複数のAWSアカウントにリソース (S3バケット、SQSキュー、KMSキーなど) を作成し、さまざまなプリンシパル名を使ってリソースベースのポリシーを更新しようとします。IAMFinderは、マルチスレッドで複数のリソースに並行してアクセスし、ラウンドロビン方式でアカウントとサービスを切り替えます。

AWSは各APIのリクエストをスロトッリングしているので、列挙スピードはAPIリクエストに許可された最大速度の制限を受けます。私たちの評価では、S3バケットのポリシーをシーケンシャルに更新するさい、IAMFinderは2.8個/秒で名前をチェック可能ということが確認されています。ですが、何千個もある名前リストをブルートフォースで列挙するのにこのスピードでは遅すぎます。そこで、この制限を克服するのに、IAMFinderは同時に呼び出すAPI数の増加に以下の複数の方法を実装しています。これらの設定構成を変更すれば、列挙スピードが速くなります。

使用するAWSサービス数: IAMFinderは現在、S3、KMS、SQS、IAMの4つのAWSサービスをサポートしています。ユーザーは1つまたは複数のAWSサービスを使ってテストを実行することを選択できます。私たちの評価では、IAMFinderの列挙スピードは、使用されるサービス数とともに増加することがわかっています。図2は、単一のS3バケットで2,000個の名前を列挙するのに710秒かかかり、4つのサービスすべてを使用すればこの時間が101秒に短縮されることを示しています。
AWSサービスごとに作成されるリソースの数: 各APIのリクエスト速度を最大限に活用するため、IAMFinderはAWSサービスごとに複数のリソースを作成し、同じAPIを並行して呼び出すことができます。たとえばIAMFinderは3つのS3バケットを作成し、update_bucket() APIを並行して呼び出してポリシーを変更できます。私たちの評価では、通常だと2〜3個のリソースでAPIのリクエスト速度いっぱいになることがわかっていますが、リソースを使いすぎると時間ペナルティが発生して悪影響が生じる可能性があります。図2でS3バケットを1つだけ使用した場合に列挙にかかる時間は710秒ですが、3つのS3バケットを使用した場合この時間は240秒に短縮されます。
AWSアカウントの数: 列挙スピードを上げるもう1つの方法が複数のAWSアカウントを使ってテストを実行することです。IAMFinderでは複数のAWSアカウントのサービスを同時使用して対象アカウントを列挙できます。私たちの評価では、使用されたアカウント数に応じて列挙速度がリニアに向上することがわかっています。図3では3つのAWSアカウントを使って2,000個の名前を列挙していますが、これだと単一アカウントで列挙する場合の約3分の1の時間ですみます。

これは、1つのアカウントとさまざまな数のサービスとリソースを使用してIAMFinderで2,000人のユーザーを列挙するのにかかる時間を示しています。青い棒グラフはサービスごとに1つのリソース、赤い棒グラフはサービスごとに2つのリソース、オレンジ色の棒グラフはサービスごとに3つのリソースをつかった場合を示しています。このチャートはS3のみを使ったケース、S3とKMSを使ったケース、S3、KMS、SQSを使ったケース、S3、KMS、SQS、IAMを使ったケースを示しています。 — 図2 使用されているさまざまな設定に応じて、IAMFinderで2,000人分の名前を列挙するのにかかった時間

このグラフは、さまざまな数のアカウントを使用して対象アカウントのユーザーを列挙すると、タスクの実行にかかる時間にどのように影響するかを示しています。これらの棒グラフは、4つのサービスを使い、各サービスごとに1つのリソースを使った場合に、1つ、2つ、または3つの異なるアカウント数を使った場合に2,000人のユーザーの列挙にかかる時間を示しています。 — 図3 1つ、2つ、または 3 つのAWSアカウントを使用してIAMFinderで2,000人分の名前を列挙したさいにかかった時間

結論

IAMFinderは、最近実施されたUnit42の調査結果「情報漏えいを引き起こす可能性があるAWS リソースベースのポリシー API を確認」に基づいて開発されたオープンソースツールです。IAMFinderは現在、上記ブログで説明した16のAWSサービスのうち4つ (S3、KMS、SQS、IAM) を実装しています。さらに多くのサービスが実装されれば、IAMFinderのパフォーマンスはさらに向上するはずです。

組織はこのツールを使って、IAMの偵察から漏えいした情報を特定し、IAMの構成見直しと強化を重ねることで潜在的な影響を緩和できます。

サイバーセキュリティコミュニティの皆さんがこの取り組みに参画して本ツールの改善にご協力くださることを願っています。IAMFinderはGitHubに投稿してあります。コミュニティの皆さんが拡張をかさねることで、よりプロアクティブなDevOpsユースケースに適用していけるようにしてくださればと思います。