Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Dieser Beitrag ist die Einführung von https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover, die für weitere Details aufgerufen werden kann.
Die domänenweite Delegation von Google Workspace ermöglicht einem Identitätsobjekt, entweder einer externen App aus dem Google Workspace Marketplace oder einem internen GCP-Dienstkonto, Daten im gesamten Workspace im Namen von Benutzern zuzugreifen. Diese Funktion, die für Apps, die mit Google APIs oder Diensten interagieren und Benutzer impersonieren müssen, entscheidend ist, erhöht die Effizienz und minimiert menschliche Fehler durch Automatisierung von Aufgaben. Mit OAuth 2.0 können App-Entwickler und Administratoren diesen Dienstkonten Zugriff auf Benutzerdaten ohne individuelle Benutzerzustimmung gewähren. Google Workspace ermöglicht die Erstellung von zwei Haupttypen globaler delegierter Objektidentitäten:
GWS-Anwendungen: Anwendungen aus dem Workspace Marketplace können als delegierte Identität eingerichtet werden. Bevor sie im Marketplace verfügbar gemacht werden, wird jede Workspace-Anwendung von Google überprüft, um potenziellen Missbrauch zu minimieren. Auch wenn dies das Risiko von Missbrauch nicht vollständig ausschließt, erhöht es erheblich die Schwierigkeit, dass solche Vorfälle auftreten.
GCP-Dienstkonto: Erfahren Sie mehr über GCP-Dienstkonten hier.
So kann ein GCP-Dienstkonto im Namen anderer Identitäten in Google Workspace auf Google APIs zugreifen:
Identität erstellt ein JWT: Die Identität verwendet den privaten Schlüssel des Dienstkontos (Teil der JSON-Schlüsselpaardatei), um ein JWT zu signieren. Dieses JWT enthält Ansprüche über das Dienstkonto, den Zielbenutzer, der impersoniert werden soll, und die OAuth-Bereiche des Zugriffs auf die angeforderte REST-API.
Die Identität verwendet das JWT, um ein Zugriffstoken anzufordern: Die Anwendung/der Benutzer verwendet das JWT, um ein Zugriffstoken vom OAuth 2.0-Dienst von Google anzufordern. Die Anfrage enthält auch den Zielbenutzer, der impersoniert werden soll (die Workspace-E-Mail des Benutzers), und die Bereiche, für die der Zugriff angefordert wird.
Der OAuth 2.0-Dienst von Google gibt ein Zugriffstoken zurück: Das Zugriffstoken repräsentiert die Autorität des Dienstkontos, im Namen des Benutzers für die angegebenen Bereiche zu handeln. Dieses Token ist typischerweise kurzlebig und muss regelmäßig (je nach Bedarf der Anwendung) aktualisiert werden. Es ist wichtig zu verstehen, dass die im JWT-Token angegebenen OAuth-Bereiche Gültigkeit haben und Auswirkungen auf das resultierende Zugriffstoken haben. Beispielsweise haben Zugriffstoken mit mehreren Bereichen Gültigkeit für zahlreiche REST-API-Anwendungen.
Die Identität verwendet das Zugriffstoken, um Google APIs aufzurufen: Jetzt kann der Dienst mit einem relevanten Zugriffstoken auf die erforderliche REST-API zugreifen. Die Anwendung verwendet dieses Zugriffstoken im "Authorization"-Header ihrer HTTP-Anfragen, die an Google APIs gerichtet sind. Diese APIs nutzen das Token, um die impersonierte Identität zu überprüfen und zu bestätigen, dass sie die erforderliche Autorisierung hat.
Google APIs geben die angeforderten Daten zurück: Wenn das Zugriffstoken gültig ist und das Dienstkonto die entsprechende Autorisierung hat, geben die Google APIs die angeforderten Daten zurück. Zum Beispiel haben wir im folgenden Bild die Methode users.messages.list verwendet, um alle Gmail-Nachrichten-IDs aufzulisten, die mit einem Zielbenutzer im Workspace verbunden sind.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
