AWS - IAM Post Exploitation

htARTE(HackTricks AWS Red Team Expert) を通じて、ゼロからヒーローまでAWSハッキングを学びましょう

HackTricksをサポートする他の方法:

IAM

IAMアクセスの詳細については:

pageAWS - IAM, Identity Center & SSO Enum

混乱した副官問題

外部アカウント(A)があなたのアカウント内のロールにアクセスを許可すると、その外部アカウントが正確にアクセスできるかどうかについて0の可視性がある可能性があります。これは問題です、なぜなら別の外部アカウント(B)が外部アカウント(A)にアクセスできる場合、Bもあなたのアカウントにアクセスできる可能性があるからです。

したがって、外部アカウントがあなたのアカウント内のロールにアクセスできるようにする場合、ExternalIdを指定することが可能です。これは、外部アカウント(A)が組織内のロールを仮定するために指定する必要がある「秘密」の文字列です。外部アカウントBがこの文字列を知らない限り、Aにアクセス権があっても、あなたのロールにアクセスできなくなります

ただし、このExternalId「秘密」は秘密ではないことに注意してください。IAMアサムロールポリシーを読むことができる人であれば、それを見ることができます。ただし、外部アカウントAがそれを知っている限り、外部アカウントBがそれを知らない限り、BがAを悪用してあなたのロールにアクセスするのを防ぎます

例:

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}

攻撃者が混乱した代理人を悪用するためには、現在のアカウントの主体が他のアカウントの役割をなりすますことができるかどうかを見つける必要があります。

予期しない信頼

プリンシパルとしてのワイルドカード

{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" },
}

このポリシーは、すべてのAWSがそのロールを前提とすることを許可します。

サービスを主体として

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

このポリシーは、どのアカウントでも、そのLambdaを呼び出すために自分のapigatewayを構成できるようにします。

プリンシパルとしてのS3

"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}

サポートされていません

{
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

一般的な混乱した代理人問題を回避する方法は、AWS:SourceArnとの条件を使用して元のARNをチェックすることです。ただし、一部のサービスはそれをサポートしていない場合があります(一部の情報源によると、CloudTrailなど)。

参考

htARTE(HackTricks AWS Red Team Expert)を使用して、ゼロからヒーローまでAWSハッキングを学びましょう!

HackTricksをサポートする他の方法:

最終更新