AWS - IAM Post Exploitation

Reading time: 3 minutes

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"
      }
    }
  }
}

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