Español - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP <--> Workspace Pivoting

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

De GCP a GWS

Conceptos básicos de la Delegación a Nivel de Dominio

La delegación a nivel de dominio 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 toda la Workspace en nombre de los usuarios.

Básicamente esto significa que las cuentas de servicio dentro de los proyectos de GCP de una organización podrían suplantar a los usuarios de Workspace de la misma organización (o incluso de una diferente).

Para obtener más información sobre cómo funciona exactamente, consulta:

Comprometer la delegación existente

Si un atacante compromete algún acceso en GCP y conoce un correo electrónico válido de usuario de Workspace (preferiblemente super administrador) 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 CS que pueda 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 a nivel de dominio no se necesita un usuario de Workspace, por lo tanto, solo conocer uno válido es suficiente y necesario para la suplantación. Sin embargo, se utilizarán los privilegios del usuario suplantado, por lo que si es un Super Administrador podrás acceder a todo. Si no tiene ningún acceso, esto será inútil.

Generador de Token de Delegación de GCP

Este sencillo script generará un token OAuth como el usuario delegado que luego puedes usar para acceder a otras APIs de Google con o sin gcloud:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "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"

DeleFriend

Esta es una herramienta que puede realizar el ataque siguiendo estos pasos:

  1. Enumerar Proyectos de GCP utilizando la API de Resource Manager.

  2. Iterar en cada recurso del proyecto y enumerar los recursos de cuentas de servicio de GCP a los cuales el usuario IAM inicial tiene acceso utilizando GetIAMPolicy.

  3. Iterar en 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 destacar que el rol de Editor posee inherentemente este permiso.

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

  5. Iterar en cada nueva cuenta de servicio y crear un objeto JWT para ella que esté compuesto por las credenciales de la clave privada de SA y un alcance de OAuth. El proceso de creación de un nuevo objeto JWT iterará en todas las combinaciones existentes de alcances de OAuth de la lista oauth_scopes.txt, para 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.

  6. El método _make_authorization_grant_assertion revela la necesidad de declarar un usuario de Workspace objetivo, referido como subject, para generar JWT bajo DWD. Aunque esto pueda parecer que requiere 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, coherente con nuestra verificación de enumeración de combinaciones. En resumen, un usuario de Workspace válido es suficiente para avanzar. Este usuario puede ser definido en el archivo config.yaml de DeleFriend. Si un usuario de Workspace objetivo aún no es conocido, la herramienta facilita la identificación automática de usuarios de Workspace válidos escaneando usuarios de dominio con roles en proyectos de GCP. Es importante tener en cuenta (nuevamente) que los JWT son específicos del dominio y no se generan para cada usuario; por lo tanto, el proceso automático apunta a una identidad única por dominio.

  7. Enumerar y crear un nuevo token de acceso de portador para cada JWT y validar el token contra la API de tokeninfo.

Script de Python de Gitlab

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. Así es como lo usarías:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

Crear una nueva delegación (Persistencia)

Es posible verificar las Delegaciones a Nivel de Dominio 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 privilegio de super administrador en GWS podría crear una nueva delegación que permita a las cuentas de servicio suplantar a algunos usuarios de GWS:

  1. Generación de una Nueva Cuenta de Servicio y Par de Claves Correspondiente: En GCP, los recursos de nuevas cuentas de servicio pueden ser producidos de forma interactiva a través de la consola o programáticamente utilizando llamadas directas a la API y herramientas de CLI. Esto requiere el rol iam.serviceAccountAdmin o cualquier rol personalizado equipado con el permiso iam.serviceAccounts.create. Una vez que se crea la cuenta de servicio, procederemos a generar un par de claves relacionadas (permiso iam.serviceAccountKeys.create).

  2. Creación de una nueva delegación: Es importante entender que solo el rol de Super Administrador posee la capacidad de configurar la delegación global a nivel de dominio en Google Workspace y la delegación a nivel de dominio no puede ser configurada 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 la delegación a nivel de dominio en la consola de administración de Google Workspace.

  1. Asignación del privilegio de alcance de OAuth: Al configurar una nueva delegación, Google requiere solo 2 parámetros, el ID de Cliente, que es el ID OAuth de la cuenta de servicio de GCP y los alcances de OAuth que definen qué llamadas a la API requiere la delegación.

  • La lista completa de alcances 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

  1. Actuar en nombre de la identidad objetivo: En este punto, tenemos un objeto delegado funcional en GWS. Ahora, utilizando la clave privada de la cuenta de servicio de GCP, podemos realizar llamadas a la API (en el alcance definido en el parámetro de alcance 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 tenga para aplicaciones de API REST.

  • Consulta la sección anterior para algunas herramientas para utilizar esta delegación.

Delegación entre Organizaciones Cruzadas

El ID de SA de OAuth es global y se puede utilizar para delegación entre organizaciones cruzadas. No se ha implementado ninguna restricción para evitar la delegación global cruzada. En términos simples, las cuentas de servicio de diferentes organizaciones de GCP pueden ser utilizadas para configurar la delegación a nivel de dominio 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.

Crear un Proyecto para enumerar Workspace

Por defecto los usuarios de Workspace tienen 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 e intentar enumerarlo.

Para que un usuario pueda enumerar Workspace también necesita suficientes permisos de Workspace (no todos los usuarios podrán enumerar el directorio).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Verifica más enumeración en:

Abusando de Gcloud

Puedes encontrar más información sobre el flujo de gcloud para iniciar sesión en:

Como se explica allí, gcloud puede solicitar el alcance https://www.googleapis.com/auth/drive lo que permitiría a un usuario acceder a la unidad del usuario. Como atacante, si has comprometido físicamente la computadora de un usuario y el usuario sigue conectado con su cuenta, podrías iniciar sesión generando un token con acceso a la unidad usando:

gcloud auth login --enable-gdrive-access

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 a Drive. Obviamente, el navegador indicará que el token generado tendrá acceso a Drive, pero como el usuario llamará a 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"

De GWS a GCP

Acceder a usuarios privilegiados de GCP

Si un atacante tiene acceso completo sobre GWS, podrá acceder a grupos con acceso privilegiado sobre GCP o incluso a usuarios, por lo tanto, moverse de GWS a GCP suele ser más "simple" simplemente porque los usuarios en GWS tienen altos privilegios sobre GCP.

Escalada de privilegios en Grupos de Google

Por defecto, los usuarios pueden unirse libremente a grupos de Workspace de la Organización y esos grupos podrían tener permisos de GCP asignados (verifica tus grupos en https://groups.google.com/).

Abusando de la escalada de privilegios en grupos de Google, podrías ser capaz de escalar a un grupo con algún tipo de acceso privilegiado a GCP.

Referencias

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorGCP - Storage EnumSiguienteGCP - Understanding Domain-Wide Delegation

Última actualización