GCP <--> Workspace Pivoting
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 GCP interna, acceda a datos en todo el Workspace en nombre de los usuarios.
Esto significa básicamente que las cuentas de servicio dentro de los proyectos de GCP de una organización podrían ser capaces de suplantar a los usuarios de Workspace de la misma organización (o incluso de una diferente).
Para más información sobre cómo funciona esto exactamente, consulta:
GCP - Understanding Domain-Wide DelegationSi un atacante comprometió algún acceso sobre GCP y conoce un correo electrónico de usuario válido de Workspace (preferiblemente super admin) de la empresa, podría enumerar todos los proyectos a los que tiene acceso, enumerar todas las Cuentas de Servicio de los proyectos, verificar a qué cuentas de servicio tiene acceso, y repetir todos estos pasos con cada Cuenta de Servicio que puede suplantar. Con una lista de todas las cuentas de servicio a las que tiene acceso y la lista de correos electrónicos de Workspace, el atacante podría intentar suplantar al usuario con cada cuenta de servicio.
Ten en cuenta que al configurar la delegación de dominio amplio no se necesita ningún usuario de Workspace, por lo tanto, solo saber que uno válido es suficiente y requerido para la suplantación. Sin embargo, se utilizarán los privilegios del usuario suplantado, así que si es Super Admin podrás acceder a todo. Si no tiene ningún acceso, esto será inútil.
Este script simple generará un token OAuth como el usuario delegado que luego puedes usar para acceder a otras APIs de Google con o sin gcloud:
Esta es una herramienta que puede realizar el ataque siguiendo estos pasos:
Enumerar proyectos de GCP utilizando la API de Resource Manager.
Iterar sobre cada recurso del proyecto y enumerar los recursos de cuentas de servicio de GCP a los que el usuario IAM inicial tiene acceso utilizando GetIAMPolicy.
Iterar sobre cada rol de cuenta de servicio y encontrar roles integrados, básicos y personalizados con permiso serviceAccountKeys.create en el recurso de cuenta de servicio objetivo. Cabe señalar que el rol de Editor posee inherentemente este permiso.
Crear una nueva clave privada KEY_ALG_RSA_2048 para cada recurso de cuenta de servicio que se encuentre con el permiso relevante en la política IAM.
Iterar sobre cada nueva cuenta de servicio y crear un JWT objeto para ella que esté compuesto por las credenciales de la clave privada de la SA y un alcance de OAuth. El proceso de creación de un nuevo objeto JWT iterará sobre todas las combinaciones existentes de alcances de OAuth de la lista oauth_scopes.txt, con el fin de encontrar todas las posibilidades de delegación. La lista oauth_scopes.txt se actualiza con todos los alcances de OAuth que hemos encontrado relevantes para abusar de las identidades de Workspace.
El método _make_authorization_grant_assertion revela la necesidad de declarar un usuario de workspace objetivo, referido como subject, para generar JWTs bajo DWD. Si bien esto puede parecer requerir un usuario específico, es importante darse cuenta de que DWD influye en cada identidad dentro de un dominio. En consecuencia, crear un JWT para cualquier usuario de dominio afecta a todas las identidades en ese dominio, de acuerdo con nuestra verificación de enumeración de combinaciones. En pocas palabras, un usuario válido de Workspace es suficiente para avanzar.
Este usuario puede definirse en el archivo config.yaml de DeleFriend. Si un usuario de workspace objetivo no se conoce ya, la herramienta facilita la identificación automática de usuarios válidos de workspace escaneando usuarios de dominio con roles en proyectos de GCP. Es clave notar (nuevamente) que los JWT son específicos del dominio y no se generan para cada usuario; por lo tanto, el proceso automático se dirige a una única identidad única por dominio.
Enumerar y crear un nuevo token de acceso portador para cada JWT y validar el token contra la API de tokeninfo.
Gitlab ha creado este script de Python que puede hacer dos cosas: listar el directorio de usuarios y crear una nueva cuenta administrativa mientras indica un json con credenciales de SA y el usuario a suplantar. Aquí está cómo lo usarías:
Es posible ver las Delegaciones de Dominio Amplio en https://admin.google.com/u/1/ac/owl/domainwidedelegation.
Un atacante con la capacidad de crear cuentas de servicio en un proyecto de GCP y privilegios de superadministrador en GWS podría crear una nueva delegación que permita a las cuentas de servicio suplantar a algunos usuarios de GWS:
Generación de una nueva cuenta de servicio y su correspondiente par de claves: En GCP, se pueden producir nuevos recursos de cuentas de servicio de forma interactiva a través de la consola o programáticamente utilizando llamadas a la API y herramientas de CLI directas. Esto requiere el rol iam.serviceAccountAdmin o cualquier rol personalizado equipado con el permiso iam.serviceAccounts.create. Una vez creada la cuenta de servicio, procederemos a generar un par de claves relacionado (permiso iam.serviceAccountKeys.create).
Creación de una nueva delegación: Es importante entender que solo el rol de Super Administrador posee la capacidad de configurar delegaciones globales de Dominio Amplio en Google Workspace y la delegación de Dominio Amplio no se puede configurar programáticamente, solo puede ser creada y ajustada manualmente a través de la consola de Google Workspace.
La creación de la regla se puede encontrar en la página Controles de API → Administrar delegación de Dominio Amplio en la consola de administración de Google Workspace.
Adjuntando privilegios de ámbitos de OAuth: Al configurar una nueva delegación, Google solo requiere 2 parámetros, el ID de Cliente, que es el ID de OAuth del recurso de Cuenta de Servicio de GCP, y los ámbitos de OAuth que definen qué llamadas a la API requiere la delegación.
La lista completa de ámbitos de OAuth se puede encontrar aquí, pero aquí hay una recomendación: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Actuando en nombre de la identidad objetivo: En este punto, tenemos un objeto delegado funcional en GWS. Ahora, usando la clave privada de la Cuenta de Servicio de GCP, podemos realizar llamadas a la API (en el ámbito definido en el parámetro de ámbito de OAuth) para activarlo y actuar en nombre de cualquier identidad que exista en Google Workspace. Como aprendimos, la cuenta de servicio generará tokens de acceso según sus necesidades y de acuerdo con los permisos que tiene para las aplicaciones de la API REST.
Consulta la sección anterior para algunas herramientas para usar esta delegación.
El ID de SA de OAuth es global y se puede usar para delegación entre organizaciones. No se ha implementado ninguna restricción para prevenir la delegación cruzada global. En términos simples, las cuentas de servicio de diferentes organizaciones de GCP pueden usarse para configurar delegaciones de dominio amplio en otras organizaciones de Workspace. Esto resultaría en solo necesitar acceso de Super Administrador a Workspace, y no acceso a la misma cuenta de GCP, ya que el adversario puede crear Cuentas de Servicio y claves privadas en su cuenta de GCP controlada personalmente.
Por defecto, los usuarios de Workspace tienen el permiso para crear nuevos proyectos, y cuando se crea un nuevo proyecto, el creador obtiene el rol de Propietario sobre él.
Por lo tanto, un usuario puede crear un proyecto, habilitar las APIs para enumerar Workspace en su nuevo proyecto y tratar de enumerarlo.
Para que un usuario pueda enumerar Workspace, también necesita suficientes permisos de Workspace (no todos los usuarios podrán enumerar el directorio).
Verifique más enumeración en:
GCP - IAM, Principals & Org Policies EnumPuede encontrar más información sobre el flujo de gcloud para iniciar sesión en:
Como se explicó allí, gcloud puede solicitar el alcance https://www.googleapis.com/auth/drive que permitiría a un usuario acceder al drive del usuario.
Como atacante, si ha comprometido físicamente la computadora de un usuario y el usuario aún está conectado con su cuenta, podría iniciar sesión generando un token con acceso al drive usando:
Si un atacante compromete la computadora de un usuario, también podría modificar el archivo google-cloud-sdk/lib/googlecloudsdk/core/config.py y agregar en el CLOUDSDK_SCOPES el alcance 'https://www.googleapis.com/auth/drive':
Por lo tanto, la próxima vez que el usuario inicie sesión, creará un token con acceso a drive que el atacante podría abusar para acceder al drive. Obviamente, el navegador indicará que el token generado tendrá acceso a drive, pero como el usuario se llamará a sí mismo el gcloud auth login, probablemente no sospechará nada.
Para listar archivos de drive: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Si un atacante tiene acceso completo a GWS, podrá acceder a grupos con acceso privilegiado a GCP o incluso a usuarios, por lo tanto, pasar de GWS a GCP suele ser más "sencillo" solo porque los usuarios en GWS tienen altos privilegios sobre GCP.
Por defecto, los usuarios pueden unirse libremente a los grupos de Workspace de la Organización y esos grupos pueden tener permisos de GCP asignados (verifica tus grupos en https://groups.google.com/).
Abusando de la escalación de privilegios de google groups, podrías ser capaz de escalar a un grupo con algún tipo de acceso privilegiado a GCP.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
