AWS - IAM & STS Unauthenticated Enum

Reading time: 6 minutes

Rollen & Benutzernamen in einem Konto auflisten

Rolle annehmen Brute-Force

Der Versuch, eine Rolle ohne die erforderlichen Berechtigungen anzunehmen, löst eine AWS-Fehlermeldung aus. Wenn Sie beispielsweise nicht autorisiert sind, könnte AWS zurückgeben:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS

Diese Nachricht bestätigt die Existenz der Rolle, weist jedoch darauf hin, dass ihre Assume-Rolle-Policy Ihre Annahme nicht zulässt. Im Gegensatz dazu führt der Versuch, eine nicht existierende Rolle anzunehmen, zu einem anderen Fehler:

An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

Interessanterweise ist diese Methode des Unterscheidens zwischen bestehenden und nicht bestehenden Rollen sogar über verschiedene AWS-Konten hinweg anwendbar. Mit einer gültigen AWS-Konto-ID und einer gezielten Wortliste kann man die im Konto vorhandenen Rollen auflisten, ohne auf inhärente Einschränkungen zu stoßen.

Sie können dieses Skript verwenden, um potenzielle Principals aufzulisten, indem Sie dieses Problem ausnutzen.

Vertrauensrichtlinien: Brute-Force über Konten hinweg Rollen und Benutzer

Die Konfiguration oder Aktualisierung einer IAM-Rollenvertrauensrichtlinie umfasst die Definition, welche AWS-Ressourcen oder -Dienste berechtigt sind, diese Rolle zu übernehmen und temporäre Anmeldeinformationen zu erhalten. Wenn die im Richtlinien angegebenen Ressourcen existieren, wird die Vertrauensrichtlinie erfolgreich gespeichert. Wenn die Ressource nicht existiert, wird ein Fehler generiert, der anzeigt, dass ein ungültiger Principal angegeben wurde.

Dies ist ein Beispiel für eine Richtlinie:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::216825089941:role/Test"
},
"Action": "sts:AssumeRole"
}
]
}

GUI

Das ist der Fehler, den Sie finden werden, wenn Sie eine Rolle verwenden, die nicht existiert. Wenn die Rolle existiert, wird die Richtlinie ohne Fehler gespeichert. (Der Fehler tritt beim Aktualisieren auf, funktioniert aber auch beim Erstellen)

CLI

### You could also use: aws iam update-assume-role-policy
# When it works
aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
{
"Role": {
"Path": "/",
"RoleName": "Test-Role",
"RoleId": "AROA5ZDCUJS3DVEIYOB73",
"Arn": "arn:aws:iam::947247140022:role/Test-Role",
"CreateDate": "2022-05-03T20:50:04Z",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::316584767888:role/account-balance"
},
"Action": [
"sts:AssumeRole"
]
}
]
}
}
}

# When it doesn't work
aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"

Sie können diesen Prozess automatisieren mit https://github.com/carlospolop/aws_tools

• bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt

Unserer Verwendung von Pacu:

• run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
• run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
• Die admin Rolle, die im Beispiel verwendet wird, ist eine Rolle in Ihrem Konto, die von pacu impersoniert werden soll, um die Richtlinien zu erstellen, die es für die Enumeration benötigt.

Privesc

Im Falle, dass die Rolle schlecht konfiguriert ist und es jedem erlaubt, sie zu übernehmen:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}

Der Angreifer könnte einfach davon ausgehen.

Drittanbieter OIDC-Föderation

Stellen Sie sich vor, Sie schaffen es, einen Github Actions-Workflow zu lesen, der auf eine Rolle innerhalb von AWS zugreift.
Dieses Vertrauen könnte den Zugriff auf eine Rolle mit der folgenden Vertrauensrichtlinie gewähren:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}

Diese Vertrauensrichtlinie könnte korrekt sein, aber der Mangel an weiteren Bedingungen sollte dich misstrauisch machen.
Das liegt daran, dass die vorherige Rolle von JEDER Person von Github Actions übernommen werden kann! Du solltest in den Bedingungen auch andere Dinge wie den Organisationsnamen, den Reponamen, die Umgebung, den Branch... angeben.

Eine weitere potenzielle Fehlkonfiguration besteht darin, eine Bedingung wie die folgende hinzuzufügen:

"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
}

Beachten Sie das Wildcard (*) vor dem Doppelpunkt (:). Sie können eine Organisation wie org_name1 erstellen und die Rolle von einer Github-Aktion annehmen.

Referenzen

• https://www.youtube.com/watch?v=8ZXRw4Ry3mQ
• https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/