Last updated
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)
Para una introducción sobre qué es una cuenta de servicio, consulta:
GCP - Basic InformationUna cuenta de servicio siempre pertenece a un proyecto:
Para una introducción sobre cómo funcionan los Usuarios y Grupos en GCP, consulta:
GCP - Basic InformationCon 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, dándoles acceso para 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 se necesita 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:
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 administrador habilitado, es posible que obtengas un error al enumerarlos porque tu usuario de workspace comprometido no tiene suficientes permisos:
Consulta esto para información básica sobre IAM.
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 de GCP es el rol de Administrador de Organización.
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.
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.
El permiso cloudasset.assets.analyzeIamPolicy puede solicitar t todas las políticas iam de un principal dentro de un recurso.
El permiso cloudasset.assets.searchAllResources permite listar todos los recursos de una organización, carpeta o proyecto. Recursos relacionados con IAM (como roles) incluidos.
El permiso cloudasset.assets.analyzeMove puede ser útil para recuperar políticas que afectan a un recurso como un proyecto.
Supongo que el permiso cloudasset.assets.queryIamPolicy también podría dar acceso para encontrar permisos de los principales.
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 debe estar habilitado.
En la siguiente página puedes verificar cómo abusar de los permisos de IAM para escalar privilegios:
GCP - IAM PrivescSi tienes altos privilegios podrías:
Crear nuevos SAs (o usuarios si estás en Workspace)
Dar más permisos a los principales controlados por ti
Dar más privilegios a SAs vulnerables (SSRF en vm, vuln Cloud Function…)
…
Para una introducción sobre qué son las Org Policies, consulta:
GCP - Basic InformationLas políticas de IAM indican los permisos que los principales tienen sobre los recursos a través de roles, que se asignan con 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.
En la siguiente página puedes verificar cómo abusar de los permisos de políticas de organización para escalar privilegios:
GCP - Orgpolicy PrivescAprende 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)
