Todo lo que se necesita para tomar Google Cloud: un paquete de PyPI, un pip install y un poco de automatización ingenua de Cloud Build

Todo lo que se necesita para tomar Google Cloud: un paquete de PyPI, un pip install y un poco de automatización ingenua de Cloud Build

Una vulnerabilidad en Google Cloud Platform permite tomar el control de la infraestructura de la víctima.

image

La vulnerabilidad ConfusedComposer, descubierta por especialistas de Tenable, es otro ejemplo de cómo la lógica interna de los servicios en la nube puede ser aprovechada para obtener accesos que exceden los permisos originales. Aunque el fallo ya ha sido corregido, su esencia ofrece una nueva perspectiva sobre la seguridad en el entorno de Google Cloud Platform, especialmente en escenarios donde la automatización y la orquestación de servicios se convierten en el talón de Aquiles.

Cloud Composer es un servicio gestionado de Google basado en Apache Airflow, diseñado para crear y automatizar flujos de trabajo. Está estrechamente integrado con Cloud Build, encargado de compilar, probar y desplegar aplicaciones. La vulnerabilidad surgió precisamente en la interacción entre ambas soluciones.

El problema radicaba en que, al instalar bibliotecas Python adicionales a través de Composer, este utilizaba automáticamente Cloud Build para crear el entorno. El proceso se ejecutaba con la cuenta de servicio predeterminada de Cloud Build, la cual posee amplios privilegios sobre servicios clave, incluyendo almacenamiento y registros de artefactos. Bastaba con tener permisos para actualizar el entorno de Composer para intervenir en el proceso.

Un atacante podía agregar un paquete PyPI malicioso a la configuración del entorno. Durante la instalación de bibliotecas con Pip —herramienta usada por Cloud Build— se ejecutaban scripts de instalación, mediante los cuales se podía correr código arbitrario dentro del entorno de Cloud Build y acceder a sus metadatos. A partir de allí, era posible obtener el token de autenticación de la cuenta de servicio y, en consecuencia, controlar una parte significativa de la infraestructura en la nube de la víctima.

Lo particular de este ataque es que no se requería acceso directo a las cuentas de servicio de Composer o Cloud Build. Era suficiente con el permiso composer.environments.update, común en escenarios de DevOps y CI/CD. Así, un usuario legítimo podía convertirse en administrador del proyecto sin romper ninguna restricción explícita.

Tras el reporte de Tenable, Google modificó la arquitectura del proceso de instalación de bibliotecas. Ahora, en lugar de usar la cuenta de servicio de Cloud Build, se emplea una cuenta de servicio menos privilegiada del entorno de Composer. Además, la documentación actualizada revisa los apartados relacionados con la gestión de permisos y la instalación de dependencias.

Este caso da continuidad a la vulnerabilidad ConfusedFunction previamente descubierta, y ha permitido destacar una nueva clase de ataques que los investigadores llaman "efecto Jenga". Como en el famoso juego de mesa, donde sacar una pieza puede hacer colapsar toda la torre, en la nube las dependencias no evidentes y los mecanismos ocultos de orquestación pueden convertirse en vulnerabilidades críticas.

No esperes a que los hackers te ataquen: ¡suscríbete a nuestro canal y conviértete en una fortaleza impenetrable!

Suscribirse