AWS - IAM Post Exploitation

Unterstütze HackTricks

IAM

Für weitere Informationen über IAM-Zugriff:

Verwirrtes Stellvertreterproblem

Wenn du einem externen Konto (A) den Zugriff auf eine Rolle in deinem Konto erlaubst, hast du 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 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" Zeichenfolge, die das externe Konto (A) angeben muss, um die Rolle in deiner 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 deine Rolle zuzugreifen.

Beachte jedoch, dass dieses ExternalId "Geheimnis" kein Geheimnis ist; jeder, der die IAM-Rollenübernahme-Richtlinie lesen kann, wird in der Lage sein, es zu sehen. Solange das externe Konto A es kennt, das externe Konto B es 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"
}
}
}
}

Um einen verwirrten Stellvertreter auszunutzen, muss ein Angreifer herausfinden, ob die Prinzipale des aktuellen Kontos Rollen in anderen Konten impersonieren können.

Unerwartete Vertrauensstellungen

Platzhalter als Prinzipal

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

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

Dienst als Hauptakteur

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

"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, dann 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 gängiger Weg, um Probleme mit dem Verwirrten Stellvertreter 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

Unterstütze HackTricks

Last updated