AWS - IAM Post Exploitation

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

IAM

For more information about IAM access:

AWS - IAM, Identity Center & SSO Enum

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

• https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.