AWS - IAM Post Exploitation

Unterstütze HackTricks

IAM

Für weitere Informationen über IAM-Zugriff:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

Wenn du einem externen Konto (A) erlaubst, auf eine Rolle in deinem Konto zuzugreifen, wirst du wahrscheinlich 0 Sichtbarkeit darüber haben, wer genau auf dieses externe Konto zugreifen kann. Dies 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 dein Konto zugreifen kann.

Daher ist es möglich, beim Erlauben eines externen Kontos, auf eine Rolle in deinem Konto zuzugreifen, eine ExternalId anzugeben. Dies ist eine "geheime" Zeichenkette, die das externe Konto (A) angeben muss, um die Rolle in deiner Organisation zu übernehmen. Da das externe Konto B diese Zeichenkette nicht kennt, kann es, selbst wenn es Zugriff auf A hat, nicht auf deine Rolle zugreifen.

Beachte jedoch, dass diese ExternalId "geheim" kein Geheimnis ist, jeder, der die IAM-Rollenübernahmerichtlinie lesen kann, wird sie sehen können. Aber solange das externe Konto A sie kennt, das externe Konto B sie jedoch nicht kennt, verhindert es, dass B A missbraucht, um auf deine Rolle zuzugreifen.

Beispiel:

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

Damit ein Angreifer einen verwirrten Stellvertreter ausnutzen kann, muss er irgendwie herausfinden, ob die Principals des aktuellen Kontos Rollen in anderen Konten imitieren können.

Unerwartete Vertrauensstellungen

Wildcard als Principal

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

Diese Richtlinie erlaubt allen AWS, die Rolle zu übernehmen.

Service als Principal

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

Diese Richtlinie erlaubt jedem Konto, seine apigateway so zu konfigurieren, dass es diese Lambda aufruft.

S3 als Principal

"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 löschen und der Angreifer ihn in seinem eigenen Konto erstellt, könnte er dies ausnutzen.

Nicht unterstützt

{
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

Ein häufiger Weg, um Confused Deputy Probleme zu vermeiden, ist die Verwendung einer Bedingung mit AWS:SourceArn, um die Herkunfts-ARN zu überprüfen. Allerdings könnten einige Dienste dies nicht unterstützen (wie CloudTrail laut einigen Quellen).

Referenzen

Unterstütze HackTricks

Last updated