Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
IAMアクセスに関する詳細情報：
外部アカウント（A）にあなたのアカウントのロールにアクセスを許可すると、その外部アカウントに正確にアクセスできるのは誰かについて0の可視性しか持たない可能性があります。これは問題です。なぜなら、別の外部アカウント（B）が外部アカウント（A）にアクセスできる場合、Bもあなたのアカウントにアクセスできる可能性があるからです。
したがって、外部アカウントにあなたのアカウントのロールにアクセスを許可する際には、ExternalIdを指定することが可能です。これは、外部アカウント（A）があなたの組織のロールを引き受けるために必要な「秘密」の文字列です。外部アカウントBはこの文字列を知らないため、Aにアクセスできても、あなたのロールにアクセスできないことになります。
ただし、このExternalIdの「秘密」は秘密ではありません。IAMのロール引き受けポリシーを読むことができる人は誰でもそれを見ることができます。しかし、外部アカウントAがそれを知っていて、外部アカウントBがそれを知らない限り、BがAを悪用してあなたのロールにアクセスするのを防ぎます。
例：
攻撃者が混乱した代理人を悪用するためには、現在のアカウントのプリンシパルが他のアカウントのロールを偽装できるかどうかを何らかの方法で見つける必要があります。
このポリシーはすべてのAWSがロールを引き受けることを許可します。
このポリシーは任意のアカウントがこのLambdaを呼び出すために自分のapigatewayを設定することを許可します。
S3バケットがプリンシパルとして指定されている場合、S3バケットにはアカウントIDがないため、もしあなたのバケットを削除し、攻撃者が自分のアカウントでそれを作成した場合、彼らはこれを悪用することができます。
混乱した代理人の問題を回避する一般的な方法は、AWS:SourceArnを使用して起源ARNをチェックする条件を使用することです。しかし、一部のサービスはそれをサポートしていない可能性があります（いくつかの情報源によるとCloudTrailのように）。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
