Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
This post is the introduction of https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover which can be accessed for more details.
La delegación de dominio amplio de Google Workspace permite que un objeto de identidad, ya sea una aplicación externa del Marketplace de Google Workspace o una Cuenta de Servicio de GCP interna, acceda a datos en todo el Workspace en nombre de los usuarios. Esta función, que es crucial para las aplicaciones que interactúan con las API de Google o servicios que necesitan suplantación de usuarios, mejora la eficiencia y minimiza el error humano al automatizar tareas. Usando OAuth 2.0, los desarrolladores de aplicaciones y administradores pueden otorgar a estas cuentas de servicio acceso a los datos de los usuarios sin el consentimiento individual del usuario. Google Workspace permite la creación de dos tipos principales de identidades de objeto delegadas globales:
Aplicaciones GWS: Las aplicaciones del Marketplace de Workspace pueden configurarse como una identidad delegada. Antes de estar disponibles en el marketplace, cada aplicación de Workspace pasa por una revisión por parte de Google para minimizar el posible uso indebido. Si bien esto no elimina por completo el riesgo de abuso, aumenta significativamente la dificultad para que tales incidentes ocurran.
Cuenta de Servicio de GCP: Aprende más sobre Cuentas de Servicio de GCP aquí.
Así es como una Cuenta de Servicio de GCP puede acceder a las API de Google en nombre de otras identidades en Google Workspace:
La identidad crea un JWT: La identidad utiliza la clave privada de la cuenta de servicio (parte del archivo de clave JSON) para firmar un JWT. Este JWT contiene afirmaciones sobre la cuenta de servicio, el usuario objetivo a suplantar y los alcances de OAuth para acceder a la API REST que se está solicitando.
La identidad utiliza el JWT para solicitar un token de acceso: La aplicación/usuario utiliza el JWT para solicitar un token de acceso del servicio OAuth 2.0 de Google. La solicitud también incluye el usuario objetivo a suplantar (el correo electrónico del usuario de Workspace) y los alcances para los cuales se solicita acceso.
El servicio OAuth 2.0 de Google devuelve un token de acceso: El token de acceso representa la autoridad de la cuenta de servicio para actuar en nombre del usuario para los alcances especificados. Este token es típicamente de corta duración y debe ser renovado periódicamente (según la necesidad de la aplicación). Es esencial entender que los alcances de OAuth especificados en el token JWT tienen validez e impacto en el token de acceso resultante. Por ejemplo, los tokens de acceso que poseen múltiples alcances tendrán validez para numerosas aplicaciones de API REST.
La identidad utiliza el token de acceso para llamar a las API de Google: Ahora, con un token de acceso relevante, el servicio puede acceder a la API REST requerida. La aplicación utiliza este token de acceso en el encabezado "Authorization" de sus solicitudes HTTP destinadas a las API de Google. Estas API utilizan el token para verificar la identidad suplantada y confirmar que tiene la autorización necesaria.
Las API de Google devuelven los datos solicitados: Si el token de acceso es válido y la cuenta de servicio tiene la autorización adecuada, las API de Google devuelven los datos solicitados. Por ejemplo, en la siguiente imagen, hemos aprovechado el método users.messages.list para listar todos los IDs de mensajes de Gmail asociados con un usuario objetivo de Workspace.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
