AWS - IAM & STS Unauthenticated Enum
AWSハッキングを学び、練習する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、練習する:
HackTricks Training GCP Red Team Expert (GRTE)
アカウント内のロールとユーザー名を列挙する
Assume Role Brute-Force
この技術はもう機能しません。ロールが存在するかどうかに関わらず、常にこのエラーが発生します:
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas
これをテストするには次を実行します:
aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example
必要な権限なしでロールを引き受けようとすると、AWSエラーメッセージがトリガーされます。例えば、権限がない場合、AWSは次のように返すかもしれません:
このメッセージはロールの存在を確認しますが、ロールの引き受けポリシーがあなたの引き受けを許可していないことを示しています。対照的に、存在しないロールを引き受けようとすると異なるエラーが発生します:
興味深いことに、この既存のロールと存在しないロールを識別する方法は、異なるAWSアカウント間でも適用可能です。有効なAWSアカウントIDとターゲットワードリストがあれば、アカウント内のロールを制限なく列挙することができます。
この問題を悪用して潜在的なプリンシパルを列挙するスクリプトを使用できます。
Trust Policies: Brute-Force Cross Account roles and users
IAMロールの信頼ポリシーを設定または更新することは、そのロールを引き受けて一時的な資格情報を取得することを許可されるAWSリソースまたはサービスを定義することを含みます。ポリシーで指定されたリソースが存在する場合、信頼ポリシーは正常に保存されます。しかし、リソースが存在しない場合、エラーが生成され、無効なプリンシパルが提供されたことを示します。
そのリソースにはクロスアカウントロールまたはユーザーを指定できることに注意してください:
arn:aws:iam::acc_id:role/role_name
arn:aws:iam::acc_id:user/user_name
これはポリシーの例です:
GUI
これは、存在しないロールを使用した場合に見つかるエラーです。ロールが存在する場合、ポリシーはエラーなしで保存されます。(エラーは更新時のものですが、作成時にも機能します)
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2218554093-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FlhtE9mh962i6B5Y7Jsw2%252Fuploads%252Fgit-blob-54012483226a4a2cbf2eaccd6e126db329503695%252Fimage%2520%28153%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=9b553cd3&sv=1)
CLI
このプロセスを自動化するには https://github.com/carlospolop/aws_tools を使用できます。
bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt
または Pacu を使用する場合:
run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
この例で使用されている
admin
ロールは、pacu が必要なポリシーを作成するために偽装されるアカウント内のロールです。
Privesc
ロールが誤って設定され、誰でもそれを引き受けることができる場合:
攻撃者はそれを仮定するだけかもしれません。
Third Party OIDC Federation
Github Actions workflowがAWS内のroleにアクセスしているのを読み取ることができたと想像してください。 この信頼は、次のtrust policyを持つロールへのアクセスを与えるかもしれません:
この信頼ポリシーは正しいかもしれませんが、条件が少なすぎるため、信用しない方が良いでしょう。 これは、前述のロールがGithub Actionsの誰でも引き受けることができるからです!条件には、組織名、リポジトリ名、環境、ブランチなども指定する必要があります。
もう一つの潜在的な誤設定は、次のような条件を追加することです:
コロン (:) の前に ワイルドカード (*) があることに注意してください。org_name1 のような組織を作成し、Github Action から ロールを引き受ける ことができます。
参考文献
AWS ハッキングを学び、練習する:HackTricks Training AWS Red Team Expert (ARTE)
GCP ハッキングを学び、練習する:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated