GCP - Basic Information
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)
Google Cloud utiliza una Jerarquía de recursos que es similar, conceptualmente, a la de un sistema de archivos tradicional. Esto proporciona un flujo de trabajo lógico de padre/hijo con puntos de conexión específicos para políticas y permisos.
A un alto nivel, se ve así:
Una máquina virtual (llamada una Compute Instance) es un recurso. Un recurso reside en un proyecto, probablemente junto a otras Compute Instances, buckets de almacenamiento, etc.
Es posible migrar un proyecto sin ninguna organización a una organización con los permisos roles/resourcemanager.projectCreator y roles/resourcemanager.projectMover. Si el proyecto está dentro de otra organización, es necesario contactar al soporte de GCP para moverlo fuera de la organización primero. Para más información, consulta esto.
Permiten centralizar el control sobre los recursos en la nube de tu organización:
Centraliza el control para configurar restricciones sobre cómo se pueden usar los recursos de tu organización.
Define y establece límites para que tus equipos de desarrollo se mantengan dentro de los límites de cumplimiento.
Ayuda a los propietarios de proyectos y sus equipos a moverse rápidamente sin preocuparse por romper el cumplimiento.
Estas políticas pueden ser creadas para afectar a la organización completa, carpeta(s) o proyecto(s). Los descendientes del nodo de jerarquía de recursos objetivo heredan la política de organización.
Para definir una política de organización, eliges un constraint, que es un tipo particular de restricción contra un servicio de Google Cloud o un grupo de servicios de Google Cloud. Configuras esa restricción con tus restricciones deseadas.
Limitar el uso compartido de recursos basado en el dominio.
Limitar el uso de cuentas de servicio de Identity and Access Management.
Restringir la ubicación física de los recursos recién creados.
Deshabilitar la creación de cuentas de servicio.
Hay muchas más restricciones que te dan un control detallado sobre los recursos de tu organización. Para más información, consulta la lista de todas las restricciones del Servicio de Políticas de Organización.
Estos son como las políticas de IAM en AWS ya que cada rol contiene un conjunto de permisos.
Sin embargo, a diferencia de AWS, no hay un repositorio centralizado de roles. En lugar de eso, los recursos dan X roles de acceso a Y principales, y la única forma de averiguar quién tiene acceso a un recurso es usar el método get-iam-policy sobre ese recurso.
Esto podría ser un problema porque significa que la única forma de averiguar qué permisos tiene un principal es preguntar a cada recurso a quién le está dando permisos, y un usuario podría no tener permisos para obtener permisos de todos los recursos.
Hay tres tipos de roles en IAM:
Roles básicos/primarios, que incluyen los roles de Propietario, Editor y Visualizador que existían antes de la introducción de IAM.
Roles predefinidos, que proporcionan acceso granular para un servicio específico y son gestionados por Google Cloud. Hay muchos roles predefinidos, puedes ver todos ellos con los privilegios que tienen aquí.
Roles personalizados, que proporcionan acceso granular de acuerdo a una lista de permisos especificada por el usuario.
Hay miles de permisos en GCP. Para verificar si un rol tiene un permiso, puedes buscar el permiso aquí y ver qué roles lo tienen.
También puedes buscar aquí roles predefinidos ofrecidos por cada producto. Ten en cuenta que algunos roles no pueden ser asignados a usuarios y solo a SAs debido a algunos permisos que contienen. Además, ten en cuenta que los permisos solo tendrán efecto si están adjuntos al servicio relevante.
O verifica si un rol personalizado puede usar un permiso específico aquí.
GCP - IAM, Principals & Org Policies EnumEn la consola de GCP no hay gestión de Usuarios o Grupos, eso se hace en Google Workspace. Aunque podrías sincronizar un proveedor de identidad diferente en Google Workspace.
Puedes acceder a los usuarios y grupos de Workspaces en https://admin.google.com.
MFA puede ser forzada a los usuarios de Workspaces, sin embargo, un atacante podría usar un token para acceder a GCP a través de cli que no estará protegido por MFA (estará protegido por MFA solo cuando el usuario inicie sesión para generarlo: gcloud auth login).
Cuando se crea una organización, se sugiere encarecidamente crear varios grupos. Si gestionas alguno de ellos, podrías haber comprometido toda o una parte importante de la organización:
Grupo
Función
gcp-organization-admins
(se requieren cuentas de grupo o individuales para la lista de verificación)
Administrar cualquier recurso que pertenezca a la organización. Asigna este rol con moderación; los administradores de la organización tienen acceso a todos tus recursos de Google Cloud. Alternativamente, dado que esta función tiene privilegios altos, considera usar cuentas individuales en lugar de crear un grupo.
gcp-network-admins
(requerido para la lista de verificación)
Crear redes, subredes, reglas de firewall y dispositivos de red como Cloud Router, Cloud VPN y balanceadores de carga en la nube.
gcp-billing-admins
(requerido para la lista de verificación)
Configurar cuentas de facturación y monitorear su uso.
gcp-developers
(requerido para la lista de verificación)
Diseñar, codificar y probar aplicaciones.
gcp-security-admins
Establecer y gestionar políticas de seguridad para toda la organización, incluyendo gestión de acceso y políticas de restricciones de organización. Consulta la guía de fundamentos de seguridad de Google Cloud para más información sobre la planificación de tu infraestructura de seguridad en Google Cloud.
gcp-devops
Crear o gestionar pipelines de extremo a extremo que soporten integración y entrega continuas, monitoreo y aprovisionamiento de sistemas.
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer
(ya no por defecto)
Monitorear el gasto en proyectos. Los miembros típicos son parte del equipo de finanzas.
gcp-platform-viewer
(ya no por defecto)
Revisar información de recursos a través de la organización de Google Cloud.
gcp-security-reviewer
(ya no por defecto)
Revisar la seguridad en la nube.
gcp-network-viewer
(ya no por defecto)
Revisar configuraciones de red.
grp-gcp-audit-viewer
(ya no por defecto)
Ver registros de auditoría.
gcp-scc-admin
(ya no por defecto)
Administrar el Centro de Comando de Seguridad.
gcp-secrets-admin
(ya no por defecto)
Gestionar secretos en Secret Manager.
Hacer cumplir contraseñas fuertes
Entre 8 y 100 caracteres
Sin reutilización
Sin expiración
Si las personas acceden a Workspace a través de un proveedor de terceros, estos requisitos no se aplican.
Estos son los principales que los recursos pueden tener adjuntos y acceso para interactuar fácilmente con GCP. Por ejemplo, es posible acceder al token de autenticación de una Cuenta de Servicio adjunta a una VM en los metadatos.
Es posible encontrar algunos conflictos al usar tanto IAM como scopes de acceso. Por ejemplo, tu cuenta de servicio puede tener el rol de IAM de compute.instanceAdmin, pero la instancia que has comprometido ha sido limitada con la restricción de scope de https://www.googleapis.com/auth/compute.readonly. Esto te impediría hacer cualquier cambio usando el token OAuth que se asigna automáticamente a tu instancia.
Es similar a los roles de IAM de AWS. Pero a diferencia de AWS, cualquier cuenta de servicio puede ser adjunta a cualquier servicio (no necesita permitirlo a través de una política).
Varias de las cuentas de servicio que encontrarás son en realidad generadas automáticamente por GCP cuando comienzas a usar un servicio, como:
Sin embargo, también es posible crear y adjuntar a recursos cuentas de servicio personalizadas, que se verán así:
Hay 2 formas principales de acceder a GCP como una cuenta de servicio:
A través de tokens OAuth: Estos son tokens que obtendrás de lugares como puntos finales de metadatos o robando solicitudes http y están limitados por los alcances de acceso.
Claves: Estos son pares de claves públicas y privadas que te permitirán firmar solicitudes como la cuenta de servicio e incluso generar tokens OAuth para realizar acciones como la cuenta de servicio. Estas claves son peligrosas porque son más complicadas de limitar y controlar, por eso GCP recomienda no generarlas.
Ten en cuenta que cada vez que se crea una SA, GCP genera una clave para la cuenta de servicio a la que el usuario no puede acceder (y no se listará en la aplicación web). Según este hilo, esta clave es utilizada internamente por GCP para dar acceso a los puntos finales de metadatos para generar los tokens OAuth accesibles.
Los alcances de acceso están adjuntos a los tokens OAuth generados para acceder a los puntos finales de la API de GCP. Restringen los permisos del token OAuth. Esto significa que si un token pertenece a un Propietario de un recurso pero no tiene en el alcance del token acceso a ese recurso, el token no puede ser utilizado para (ab)usar esos privilegios.
Google de hecho recomienda que no se utilicen alcances de acceso y que se confíe totalmente en IAM. El portal de gestión web de hecho hace cumplir esto, pero los alcances de acceso aún se pueden aplicar a instancias utilizando cuentas de servicio personalizadas programáticamente.
Puedes ver qué alcances están asignados consultando:
Los alcances anteriores son los generados por defecto usando gcloud para acceder a datos. Esto se debe a que cuando usas gcloud primero creas un token de OAuth y luego lo usas para contactar los endpoints.
El alcance más importante de esos potencialmente es cloud-platform, que básicamente significa que es posible acceder a cualquier servicio en GCP.
Puedes encontrar una lista de todos los posibles alcances aquí.
Si tienes credenciales de navegador de gcloud, es posible obtener un token con otros alcances, haciendo algo como:
Como se define en terraform en https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, al usar terraform con GCP hay diferentes formas de otorgar acceso a un principal sobre un recurso:
Membresías: Estableces principales como miembros de roles sin restricciones sobre el rol o los principales. Puedes poner a un usuario como miembro de un rol y luego poner a un grupo como miembro del mismo rol y también establecer esos principales (usuario y grupo) como miembros de otros roles.
Vinculaciones: Varios principales pueden estar vinculados a un rol. Esos principales aún pueden estar vinculados o ser miembros de otros roles. Sin embargo, si un principal que no está vinculado al rol se establece como miembro de un rol vinculado, la próxima vez que se aplique la vinculación, la membresía desaparecerá.
Políticas: Una política es autoritativa, indica roles y principales y luego, esos principales no pueden tener más roles y esos roles no pueden tener más principales a menos que esa política sea modificada (ni siquiera en otras políticas, vinculaciones o membresías). Por lo tanto, cuando un rol o principal se especifica en la política, todos sus privilegios están limitados por esa política. Obviamente, esto puede ser eludido en caso de que al principal se le dé la opción de modificar la política o permisos de escalada de privilegios (como crear un nuevo principal y vincularlo a un nuevo rol).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
