AWS - IAM Post Exploitation

Reading time: 4 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

IAM

Für weitere Informationen über IAM-Zugriff:

AWS - IAM, Identity Center & SSO Enum

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 den Zugriff auf eine Rolle in Ihrem Konto 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, selbst wenn es Zugriff auf A hat, nicht in der Lage sein, auf Ihre Rolle zuzugreifen.

Beachten Sie jedoch, dass diese ExternalId "Geheimnis" kein Geheimnis ist; jeder, der die IAM-Rollenübernahme-Richtlinie lesen kann, wird sie 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

Wildcard 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 wird, da S3-Buckets keine Account-ID 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).

Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks