# AWS - IAM Post Exploitation

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

## IAM

Für weitere Informationen über IAM-Zugriff:

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

## Verwirrtes Stellvertreterproblem

Wenn Sie **einem externen Konto (A)** den Zugriff auf eine **Rolle** in Ihrem Konto erlauben, haben Sie wahrscheinlich **0 Sichtbarkeit** darüber, **wer genau auf dieses externe Konto zugreifen kann**. Das ist ein Problem, denn wenn ein anderes externes Konto (B) auf das externe Konto (A) zugreifen kann, ist es möglich, dass **B auch auf Ihr Konto zugreifen kann**.

Daher ist es möglich, beim Erlauben eines externen Kontos, auf eine Rolle in Ihrem Konto zuzugreifen, eine `ExternalId` anzugeben. Dies ist eine "geheime" Zeichenfolge, die das externe Konto (A) **angeben muss**, um **die Rolle in Ihrer Organisation zu übernehmen**. Da das **externe Konto B diese Zeichenfolge nicht kennt**, wird es **nicht in der Lage sein, auf Ihre Rolle zuzugreifen**, selbst wenn es Zugriff auf A hat.

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

Beachten Sie jedoch, dass dieses `ExternalId` "Geheimnis" **kein Geheimnis** ist; jeder, der die IAM-Rollenübernahme-Richtlinie **lesen kann, wird es sehen können**. Solange das externe Konto A es kennt, das externe Konto **B es jedoch nicht kennt**, **verhindert es, dass B A missbraucht, um auf Ihre Rolle zuzugreifen**.

Beispiel:
```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]
> Damit ein Angreifer einen verwirrten Stellvertreter ausnutzen kann, muss er irgendwie herausfinden, ob die Prinzipale des aktuellen Kontos Rollen in anderen Konten impersonieren können.

### Unerwartete Vertrauensstellungen

#### Platzhalter als Prinzipal
```json
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}
```
Diese Richtlinie **erlaubt allen AWS**, die Rolle zu übernehmen.

#### Dienst als Hauptakteur
```json
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
Diese Richtlinie **erlaubt jedem Konto**, ihr apigateway so zu konfigurieren, dass es diese Lambda aufruft.

#### S3 als Hauptakteur
```json
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
```
Wenn ein S3-Bucket als Principal angegeben ist, da S3-Buckets keine Kontonummer haben, wenn Sie **Ihren Bucket gelöscht haben und der Angreifer ihn in seinem eigenen Konto erstellt hat**, könnte er dies ausnutzen.

#### Nicht unterstützt
```json
{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
Ein gängiger Weg, um Probleme mit verwirrten Stellvertretern zu vermeiden, ist die Verwendung einer Bedingung mit `AWS:SourceArn`, um die Ursprungs-ARN zu überprüfen. Allerdings **unterstützen einige Dienste das möglicherweise nicht** (wie CloudTrail laut einigen Quellen).

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