# AWS - IAM Post Exploitation

{{#include ../../../banners/hacktricks-training.md}}

## IAM

For more information about IAM access:

{{#ref}}
../aws-services/aws-iam-enum.md
{{#endref}}

## 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**.

<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>

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:

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

> [!WARNING]
> 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

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

This policy **allows all AWS** to assume the role.

#### Service as principal

```json
{
  "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

```json
"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

```json
{
  "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](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

{{#include ../../../banners/hacktricks-training.md}}