GCP - IAM, Principals & Org Policies Enum

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)

Apoya a HackTricks

• Revisa los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repos de github.

Cuentas de Servicio

Para una introducción sobre qué es una cuenta de servicio, consulta:

GCP - Basic Information

Enumeración

Una cuenta de servicio siempre pertenece a un proyecto:

gcloud iam service-accounts list --project <project>

Usuarios y Grupos

Para una introducción sobre cómo funcionan los Usuarios y Grupos en GCP, consulta:

GCP - Basic Information

Enumeración

Con los permisos serviceusage.services.enable y serviceusage.services.use es posible habilitar servicios en un proyecto y usarlos.

Ten en cuenta que, por defecto, a los usuarios de Workspace se les otorga el rol Creador de Proyectos, lo que les da acceso a crear nuevos proyectos. Cuando un usuario crea un proyecto, se le otorga el rol owner sobre él. Así que podría habilitar estos servicios sobre el proyecto para poder enumerar Workspace.

Sin embargo, ten en cuenta que también es necesario tener suficientes permisos en Workspace para poder llamar a estas APIs.

Si puedes habilitar el servicio admin y si tu usuario tiene suficientes privilegios en workspace, podrías enumerar todos los grupos y usuarios con las siguientes líneas. Incluso si dice identity groups, también devuelve usuarios sin ningún grupo:

# Enable admin
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com

# Using admin.googleapis.com
## List all users
gcloud organizations list #The DIRECTORY_CUSTOMER_ID is the Workspace ID
gcloud beta identity groups preview --customer <workspace-id>

# Using cloudidentity.googleapis.com
## List groups of a user (you can list at least the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum

## List Group Members (you can list at least the groups you belong to)
gcloud identity groups memberships list --group-email=<email>
### Make it transitive
gcloud identity groups memberships search-transitive-memberships --group-email=<email>

## Get a graph (if you have enough permissions)
gcloud identity groups memberships get-membership-graph --member-email=<email> --labels=cloudidentity.googleapis.com/groups.discussion_forum

En los ejemplos anteriores, el parámetro --labels es obligatorio, por lo que se utiliza un valor genérico (no es necesario si usas la API directamente como PurplePanda lo hace aquí.

Incluso con el servicio de administración habilitado, es posible que obtengas un error al enumerarlos porque tu usuario de workspace comprometido no tiene suficientes permisos:

IAM

Consulta esto para información básica sobre IAM.

Permisos Predeterminados

De los docs: Cuando se crea un recurso de organización, a todos los usuarios de tu dominio se les otorgan los roles de Creador de Cuenta de Facturación y Creador de Proyecto por defecto. Estos roles predeterminados permiten a tus usuarios comenzar a usar Google Cloud de inmediato, pero no están destinados para su uso en la operación regular de tu recurso de organización.

Estos roles otorgan los permisos:

• billing.accounts.create y resourcemanager.organizations.get

• resourcemanager.organizations.get y resourcemanager.projects.create

Además, cuando un usuario crea un proyecto, se le otorga automáticamente la propiedad de ese proyecto según los docs. Por lo tanto, por defecto, un usuario podrá crear un proyecto y ejecutar cualquier servicio en él (¿mineros? ¿enumeración de Workspace? ...)

El privilegio más alto en una Organización GCP es el rol de Administrador de Organización.

set-iam-policy vs add-iam-policy-binding

En la mayoría de los servicios, podrás cambiar los permisos sobre un recurso utilizando el método add-iam-policy-binding o set-iam-policy. La principal diferencia es que add-iam-policy-binding agrega un nuevo enlace de rol a la política IAM existente, mientras que set-iam-policy eliminará los permisos previamente otorgados y establecerá solo los que se indican en el comando.

Enumeración

# Roles
## List roles
gcloud iam roles list --project $PROJECT_ID # List only custom roles
gcloud iam roles list --filter='etag:AA=='

## Get perms and description of role
gcloud iam roles describe roles/container.admin
gcloud iam roles describe --project <proj-name> <role-name>

# Policies
gcloud organizations get-iam-policy <org_id>
gcloud resource-manager folders get-iam-policy <folder-id>
gcloud projects get-iam-policy <project-id>

# MISC
## Testable permissions in resource
gcloud iam list-testable-permissions --filter "NOT apiDisabled: true" <resource>
## Grantable roles to a resource
gcloud iam list-grantable-roles <project URL>

cloudasset IAM Enumeration

Hay diferentes formas de verificar todos los permisos de un usuario en diferentes recursos (como organizaciones, carpetas, proyectos...) utilizando este servicio.

• El permiso cloudasset.assets.searchAllIamPolicies puede solicitar todas las políticas iam dentro de un recurso.

gcloud asset search-all-iam-policies #By default uses current configured project
gcloud asset search-all-iam-policies --scope folders/1234567
gcloud asset search-all-iam-policies --scope organizations/123456
gcloud asset search-all-iam-policies --scope projects/project-id-123123

• El permiso cloudasset.assets.analyzeIamPolicy puede solicitar t todas las políticas iam de un principal dentro de un recurso.

# Needs perm "cloudasset.assets.analyzeIamPolicy" over the asset
gcloud asset analyze-iam-policy --organization=<org-id> \
--identity='user:[e-mail]'
gcloud asset analyze-iam-policy --folder=<folder-id> \
--identity='user:[e-mail]'
gcloud asset analyze-iam-policy --project=<project-name> \
--identity='user:[e-mail]'

• El permiso cloudasset.assets.searchAllResources permite listar todos los recursos de una organización, carpeta o proyecto. Recursos relacionados con IAM (como roles) incluidos.

gcloud asset search-all-resources --scope projects/<proj-name>
gcloud asset search-all-resources --scope folders/1234567
gcloud asset search-all-resources --scope organizations/123456

• El permiso cloudasset.assets.analyzeMove puede ser útil para recuperar políticas que afectan a un recurso como un proyecto.

gcloud asset analyze-move --project=<proj-name> \
--destination-organization=609216679593

• Supongo que el permiso cloudasset.assets.queryIamPolicy también podría dar acceso para encontrar permisos de los principales.

# But, when running something like this
gcloud asset query --project=<proj> --statement='SELECT * FROM compute_googleapis_com_Instance'
# I get the error
ERROR: (gcloud.asset.query) UNAUTHENTICATED: QueryAssets API is only supported for SCC premium customers. See https://cloud.google.com/security-command-center/pricing

testIamPermissions enumeration

Si no puedes acceder a la información de IAM utilizando los métodos anteriores y estás en un Red Team. Podrías usar la herramienta https://github.com/carlospolop/bf_my_gcp_perms para hacer un ataque de fuerza bruta a tus permisos actuales.

Sin embargo, ten en cuenta que el servicio cloudresourcemanager.googleapis.com necesita estar habilitado.

Privesc

En la siguiente página puedes verificar cómo abusar de los permisos de IAM para escalar privilegios:

GCP - IAM Privesc

Unauthenticated Enum

GCP - IAM, Principals & Org Unauthenticated Enum

Post Exploitation

GCP - IAM Post Exploitation

Persistence

Si tienes altos privilegios podrías:

• Crear nuevos SAs (o usuarios si estás en Workspace)

• Dar a los principales controlados por ti más permisos

• Dar más privilegios a SAs vulnerables (SSRF en vm, vuln Cloud Function…)

• …

Org Policies

Para una introducción sobre qué son las Org Policies, consulta:

GCP - Basic Information

Las políticas de IAM indican los permisos que los principales tienen sobre los recursos a través de roles, que se asignan permisos granulares. Las políticas de organización restringen cómo se pueden usar esos servicios o qué características están deshabilitadas. Esto ayuda a mejorar el principio de menor privilegio de cada recurso en el entorno de GCP.

gcloud resource-manager org-policies list --organization=ORGANIZATION_ID
gcloud resource-manager org-policies list --folder=FOLDER_ID
gcloud resource-manager org-policies list --project=PROJECT_ID

Privesc

En la siguiente página puedes verificar cómo abusar de los permisos de políticas de organización para escalar privilegios:

GCP - Orgpolicy Privesc

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)

Apoya a HackTricks

• Revisa los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.