HackTricks Cloud
HackTricks Cloud
Ask or search…
⌃K
Links

AWS - IAM Post Exploitation

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks:

IAM

For more information about IAM access:

Confused Deputy Problem

If you allow an external account (A) to access a role in your account, you will probably have 0 visibility on who can exactly access that external account. This is a problem, because if another external account (B) can access the external account (A) it's possible that B will also be able to access your account.
Therefore, when allowing an external account to access a role in your account it's possible to specify an ExternalId. This is a "secret" string that the external account (A) need to specify in order to assume the role in your organization. As the external account B won't know this string, even if he has access over A he won't be able to access your role.
However, note that this ExternalId "secret" is not a secret, anyone that can read the IAM assume role policy will be able to see it. But as long as the external account A knows it, but the external account B doesn't know it, it prevents B abusing A to access your role.
Example:
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}
For an attacker to exploit a confused deputy he will need to find somehow if principals of the current account can impersonate roles in other accounts.

Unexpected Trusts

Wildcard as principal

{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" },
}
This policy allows all AWS to assume the role.

Service as principal

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
This policy allows any account to configure their apigateway to call this Lambda.

S3 as principal

"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
If an S3 bucket is given as a principal, because S3 buckets do not have an Account ID, if you deleted your bucket and the attacker created it in their own account, then they could abuse this.

Not supported

{
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
A common way to avoid Confused Deputy problems is the use of a condition with AWS:SourceArn to check the origin ARN. However, some services might not support that (like CloudTrail according to some sources).

References

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks: