mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-14 22:03:11 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -4,9 +4,9 @@
|
||||
|
||||
## **De GCP a GWS**
|
||||
|
||||
### **Conceptos básicos de Delegación de Dominio**
|
||||
### **Conceptos básicos de Delegación a Nivel de Dominio**
|
||||
|
||||
La delegación de dominio de Google Workspace permite que un objeto de identidad, ya sea una **aplicación externa** del Google Workspace Marketplace o una **Cuenta de Servicio GCP** interna, **acceda a datos en todo el Workspace en nombre de los usuarios**.
|
||||
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 GCP** interna, **acceda a datos en todo el Workspace en nombre de los usuarios**.
|
||||
|
||||
> [!NOTE]
|
||||
> 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).
|
||||
@@ -23,10 +23,10 @@ Si un atacante **comprometió algún acceso sobre GCP** y **conoce un correo ele
|
||||
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**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Ten en cuenta que al configurar la delegación de dominio 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**.\
|
||||
> Ten en cuenta que al configurar la delegación a nivel de dominio 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.
|
||||
|
||||
#### [GCP Generar Token de Delegación](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
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`:
|
||||
```bash
|
||||
@@ -45,9 +45,9 @@ Esta es una herramienta que puede realizar el ataque siguiendo estos pasos:
|
||||
3. 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.
|
||||
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 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.
|
||||
6. 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 términos simples, 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 de workspace válidos 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.
|
||||
7. **Enumerar y crear un nuevo token de acceso portador** para cada JWT y validar el token contra la API de tokeninfo.
|
||||
6. 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 no se conoce ya un usuario de workspace objetivo, 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 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.
|
||||
7. **Enumerar y crear un nuevo token de acceso bearer** para cada JWT y validar el token contra la API de tokeninfo.
|
||||
|
||||
#### [Script de Python de Gitlab](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
|
||||
@@ -79,19 +79,19 @@ Es posible **ver las Delegaciones de Dominio Amplio en** [**https://admin.google
|
||||
|
||||
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:**
|
||||
|
||||
1. **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`**).
|
||||
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 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.
|
||||
1. **Generación de una nueva cuenta de servicio y par de claves correspondiente:** En GCP, se pueden producir nuevos recursos de cuenta 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** (**`iam.serviceAccountKeys.create`** permiso).
|
||||
2. **Creación de nueva delegación**: Es importante entender que **solo el rol de Super Administrador tiene la capacidad de configurar la delegación global de Dominio Amplio en Google Workspace** y la delegación de Dominio Amplio **no se puede configurar programáticamente,** solo se puede crear y ajustar **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**.
|
||||
3. **Adjuntando privilegios de ámbitos de OAuth**: Al configurar una nueva delegación, Google requiere solo 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.
|
||||
3. **Adjuntando privilegios de ámbitos de OAuth**: Al configurar una nueva delegación, Google requiere solo 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í**](https://developers.google.com/identity/protocols/oauth2/scopes), 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`
|
||||
4. **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.
|
||||
|
||||
#### Delegación entre organizaciones
|
||||
|
||||
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 global cruzada. En términos simples, **las cuentas de servicio de diferentes organizaciones de GCP pueden usarse para configurar la delegación 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.
|
||||
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 se pueden usar para configurar la delegación 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.
|
||||
|
||||
### Creando un Proyecto para enumerar Workspace
|
||||
### Creando un proyecto para enumerar Workspace
|
||||
|
||||
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.
|
||||
|
||||
@@ -127,10 +127,10 @@ Verifique **más enumeración en**:
|
||||
Puede encontrar más información sobre el flujo de `gcloud` para iniciar sesión en:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistance.md
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
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 se explica 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:
|
||||
```bash
|
||||
gcloud auth login --enable-gdrive-access
|
||||
@@ -140,7 +140,7 @@ Si un atacante compromete la computadora de un usuario, también podría modific
|
||||
<figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
> [!WARNING]
|
||||
> 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 **`gcloud auth login`**, probablemente **no sospechará nada.**
|
||||
> 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"`**
|
||||
|
||||
@@ -148,11 +148,11 @@ Si un atacante compromete la computadora de un usuario, también podría modific
|
||||
|
||||
### Acceso a usuarios privilegiados de GCP
|
||||
|
||||
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 "simple" solo porque **los usuarios en GWS tienen altos privilegios sobre GCP**.
|
||||
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**.
|
||||
|
||||
### Escalación de privilegios en Google Groups
|
||||
|
||||
Por defecto, los usuarios pueden **unirse libremente a grupos de Workspace de la Organización** y esos grupos **pueden tener permisos de GCP** asignados (verifica tus grupos en [https://groups.google.com/](https://groups.google.com/)).
|
||||
Por defecto, los usuarios pueden **unirse libremente a grupos de Workspace de la Organización** y esos grupos **pueden tener permisos de GCP** asignados (verifique sus grupos en [https://groups.google.com/](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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user