AWS - IAM & STS Unauthenticated Enum
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:
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:
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:
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
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:
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:
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:
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
Last updated