AWS - IAM & STS Unauthenticated Enum

Support HackTricks

Rollen & Benutzernamen in einem Konto auflisten

Rolle annehmen Brute-Force

Diese Technik funktioniert nicht mehr, da du, egal ob die Rolle existiert oder nicht, immer diese Fehlermeldung erhältst:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas

Du kannst dies testen, indem du:

aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example

Der Versuch, eine Rolle ohne die erforderlichen Berechtigungen anzunehmen, löst eine AWS-Fehlermeldung aus. Zum Beispiel, wenn nicht autorisiert, 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, zeigt jedoch an, dass ihre Assume-Rolle-Policy Ihre Annahme nicht erlaubt. 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, um dieses Problem auszunutzen.

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

Die Konfiguration oder Aktualisierung der Vertrauensrichtlinie einer IAM-Rolle 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 jedoch nicht existiert, wird ein Fehler generiert, der anzeigt, dass ein ungültiger Principal angegeben wurde.

Beachten Sie, dass Sie in dieser Ressource eine rollen- oder benutzerübergreifende Kontenrolle angeben könnten:

  • arn:aws:iam::acc_id:role/role_name

  • arn:aws:iam::acc_id:user/user_name

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, wenn Sie eine Rolle verwenden, die nicht existiert. Wenn die Rolle existiert, wird die Richtlinie ohne Fehler gespeichert. (Der Fehler tritt beim Update 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"

Du kannst 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 deinem Konto, die von pacu impersoniert werden kann, um die Richtlinien zu erstellen, die für die Enumeration benötigt werden.

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 es einfach annehmen.

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 annehmen von einer Github-Aktion.

Referenzen

Unterstützen Sie HackTricks

Last updated