GCP - Understanding Domain-Wide Delegation

Unterstützen Sie HackTricks

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.

Verständnis der domänenweiten Delegation

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 interagieren oder 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, durchläuft jede Workspace-Anwendung eine Überprüfung durch Google, 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.

Domänenweite Delegation: Unter der Haube

So kann ein GCP-Dienstkonto auf Google APIs im Namen anderer Identitäten in Google Workspace zugreifen:

  1. 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-Berechtigungen für den Zugriff auf die angeforderte REST-API.

  2. 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 Berechtigungen, für die der Zugriff angefordert wird.

  3. 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 Berechtigungen 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-Berechtigungen Gültigkeit haben und Auswirkungen auf das resultierende Zugriffstoken haben. Beispielsweise haben Zugriffstoken mit mehreren Berechtigungen Gültigkeit für zahlreiche REST-API-Anwendungen.

  4. 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.

  5. 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.

Unterstützen Sie HackTricks

Last updated