Los atacantes pueden utilizar Google Cloud Build para manipular entornos de producción

Un grupo de investigadores de Orca Security ha advertido que los atacantes con acceso a una cuenta regular pueden abusar fácilmente de un permiso asociado con el servicio Google Cloud Build para elevar sus privilegios y potencialmente manipular las imágenes de contenedores utilizadas en entornos de producción. Google Cloud Build es una plataforma de CI/CD que permite a las organizaciones y desarrolladores ejecutar tareas de creación de código en Google Cloud en una variedad de lenguajes de programación. El servicio admite la importación de código fuente desde repositorios y ubicaciones de almacenamiento en la nube, crea el código en función de una especificación configurada y produce artefactos como imágenes de contenedores que se pueden implementar directamente en entornos de producción.

Google Build se integra con otros servicios de su nube, como Artifact Registry, Kubernetes Engine y App Engine. Como tal, tiene poderosas capacidades y acceso. Algunas funciones de usuario predefinidas en Google Cloud ya incluyen algunos de los permisos necesarios para invocar las funciones de Cloud Build, pero algunos de estos permisos también se pueden asignar individualmente a usuarios, grupos y cuentas de servicio.

Uno de estos permisos que los investigadores descubrieron que se puede abusar para escalar privilegios se llama cloudbuild.builds.create. Como su nombre indica, se puede usar para crear nuevas compilaciones utilizando el servicio Cloud Build. Una organización que tenga usuarios con este permiso sería muy razonable en un entorno que usa Cloud Build como la plataforma principal de CI/CD, dijeron los investigadores de Orca. De hecho, varios roles predeterminados lo tienen, incluidos los roles de nivel de administrador, pero también roles relacionados con el desarrollador, como dataflow.developer.

Escalada de privilegios que conduce a un compromiso de la cadena de suministro

En un escenario de ataque a la cadena de suministro, un atacante con acceso a una cuenta con menos privilegios intentaría encontrar una ruta que le otorgue acceso al código fuente o a los recursos, como artefactos binarios, que una organización usa para desarrollar y construir sus aplicaciones antes de que están desplegados. Según Orca Security, el permiso cloudbuild.builds.create hace exactamente eso.

“Al abusar de esta falla que permite la suplantación de la cuenta de servicio predeterminada de Cloud Build, un atacante puede manipular imágenes en el Registro de artefactos de Google e inyectar código malicioso”, dijeron los investigadores de Orca. “Todas las aplicaciones creadas a partir de las imágenes manipuladas se ven afectadas, con posibles resultados que incluyen ataques de denegación de servicio (DoS), robo de datos y propagación de malware. Peor aún, si las aplicaciones mal formadas están destinadas a implementarse en los entornos del cliente (ya sea en las instalaciones o semi-SaaS), el riesgo se cruza desde el entorno de la organización proveedora a los entornos de sus clientes, lo que constituye un ataque a la cadena de suministro, similar a lo que sucedió. en los incidentes de SolarWinds y MOVEit”.

Los investigadores de Orca llamaron a su vector de ataque de prueba de concepto Bad.Builds, pero en realidad lo encontraron mientras investigaban otro problema. Observaron que cada vez que se usaba el método API setIamPolicy para actualizar el acceso a un recurso de Google Cloud Platform (GCP), todos los permisos del proyecto se incluían en el cuerpo del mensaje y se guardaban en el registro de auditoría.

Los investigadores se dieron cuenta de que saber exactamente quién tiene acceso a qué recurso dentro de un proyecto podría ser información muy valiosa para que un atacante tenga que encontrar formas de realizar una escalada de privilegios o un movimiento lateral dentro de un entorno. Luego se preguntaron qué roles podían enumerar y ver los registros de auditoría y no eran administrativos y uno captó su atención: cloudbuild.builds.builder, el rol asociado con la cuenta de servicio de Cloud Build.

A partir de aquí, analizaron qué permiso se necesita para invocar el servicio Cloud Build y cómo podría usarse para realizar la acción logging.privateLogEntries.list que se necesita para leer el registro de auditoría. Así es como encontraron el permiso cloudbuild.builds.create y los roles predefinidos que lo tienen:

roles/cloudbuild.builds.builder
roles/cloudbuild.builds.editor
roles/composer.worker
roles/dataflow.admin
roles/dataflow.developer
roles/appengineflex.serviceAgent
roles/cloudbuild.serviceAgent
roles/cloudconfig.serviceAgent
roles/clouddeploy.serviceAgent
roles /cloudfunctions.serviceAgent
roles/datapipelines.serviceAgent
roles/dataprep.serviceAgent
roles/run.serviceAgent
roles/runapps.serviceAgent
roles/serverless.serviceAgent

Los investigadores crearon una cuenta de servicio llamada roin-svc para realizar pruebas y le asignaron la función dataflow.developer. Luego aprovecharon el permiso cloudbuild.builds.create para iniciar una nueva configuración de compilación y hacer que el servicio Cloud Build use sus propios permisos para llamar a setIamPolicy y luego registrar la respuesta como parte de su registro de eventos de compilación en un depósito remoto especificado como parte del configuración de compilación.

De esta forma, aunque el rol de desarrollador de Dataflow no tenía los permisos para leer el registro de auditoría, pudo aprovechar el servicio de Cloud Build para hacer el trabajo y recibir una lista de todos los permisos del proyecto. Después de informar este problema a Google, la empresa eliminó la acción logging.privateLogEntries.list del servicio Cloud Build, por lo que ya no es posible usarla de esta manera.

Sin embargo, es posible aprovechar el permiso cloudbuild.builds.create para iniciar nuevas compilaciones y realizar cualquier otra acción a la que Cloud Build todavía tenga acceso porque esto es así por diseño. Hay muchas llamadas API potentes, incluso para acceder y manipular archivos en el Registro de artefactos, como imágenes de contenedores, así como para crear, enumerar y eliminar depósitos de almacenamiento y objetos de almacenamiento dentro de esos depósitos.

Manipulación de artefactos de Google Cloud

El escenario PoC que Orca desarrolló y documentó en su informe se centra en el Registro de artefactos. Primero, los atacantes deben obtener acceso a una cuenta que tenga la capacidad de crear nuevas compilaciones, lo que se puede lograr a través de un token de acceso robado o filtrado. Luego, pueden hacerse pasar por la cuenta de servicio de Cloud Build y escalar los privilegios y ejecutar llamadas API contra el registro de artefactos.

Con los permisos de Cloud Build asociados con Artifact Registry, los atacantes pueden ubicar y extraer una imagen de contenedor que se usa dentro de Google Kubernetes Engine (GKE). Luego pueden modificarlo localmente, inyectarle un código malicioso, como un shell web, y volver a cargarlo en el registro. Una vez que GKE implementa automáticamente la imagen maliciosa, el atacante puede aprovechar la puerta trasera de forma remota y ejecutar comandos dentro del contenedor Docker como root.

“El impacto potencial puede ser diverso y se aplica a todas las organizaciones que utilizan el Registro de artefactos como su repositorio de imágenes principal o secundario”, dijeron los investigadores. “Ahora que sabemos que el permiso cloudbuild.builds.create otorga todos los permisos de la cuenta de servicio de Cloud Build, es importante que los equipos de seguridad sean muy conscientes de qué cuentas tienen derecho a esto. Si uno se ve comprometido, las consecuencias pueden ser inmensas”.

Para limitar aún más el riesgo, Orca recomienda que los usuarios de Google Cloud Platform restrinjan los permisos predeterminados otorgados a la cuenta de Cloud Build Service solo a las acciones específicas que necesitan y usan en sus flujos de trabajo según el principio de privilegio mínimo.