Introducción
Orca Security ha identificado recientemente una falla de diseño en el servicio Google Cloud Build, denominada "Bad.Build". Esta falla plantea un grave riesgo de seguridad, ya que permite a los atacantes ejecutar Privilege Escalation, otorgándoles entrada no autorizada a los repositorios de código de Artifact Registry de Google.
Las consecuencias de esta vulnerabilidad se extienden a la cadena de suministro de software, ya que los atacantes pueden aprovecharla para manipular imágenes de aplicaciones con intenciones maliciosas. En consecuencia, los usuarios y clientes desprevenidos que instalen las aplicaciones manipuladas pueden ser víctimas de infecciones.
Esta situación nos recuerda el impacto significativo observado en ataques anteriores a la cadena de suministro como SolarWinds, 3CX y Muévelo, enfatizando las implicaciones de largo alcance de tales fallas de seguridad.
¿Cómo funciona?
Google Construcción en la nube se presenta como una integración continua/entrega continua (CI/CD) servicio ofrecido dentro del ecosistema de Google Cloud. Desempeña un papel fundamental en las aplicaciones en la nube, ya que interactúa fluidamente con otros servicios esenciales como Artifact Registry y App Engine.
La falla que nos ocupa se debe a un problema con privilegios excesivos. En concreto, el “logging.privateLogEntries.lista"La acción permite inadvertidamente la inclusión de registros de auditoría en una función no deseada, a saber, "roles/cloudbuild.builds.builder."
Lamentablemente, esta función predeterminada se asigna a la cuenta del servicio de compilación en la nube. Esta situación plantea un grave riesgo ya que los registros de auditoría contienen información confidencial que revela todos los permisos asociados con el proyecto. Este acceso no intencionado otorga a los atacantes la capacidad de hacerse pasar por la cuenta de creación de la nube, adquiriendo así conocimiento sobre qué acciones pueden realizar diferentes cuentas de Google. En consecuencia, esto abre la puerta al movimiento lateral y a la escalada de privilegios, lo que presenta una vulnerabilidad de seguridad extremadamente peligrosa.
Para hacerse pasar por la cuenta de servicio de compilación solo se requiere la cloudbuild.builds.create permiso, que tienen muchos roles predefinidos y que se otorgan a los desarrolladores en cualquier momento razonable CI/CD entorno que utiliza Cloud Build. Por lo tanto, si tiene acceso a una cuenta de desarrollador, crear un archivo de configuración de compilación personalizado ejecutará el... comando de lectura de registro de gcloud, que enumerará los permisos.
Pero el problema no termina aquí: el La cuenta del servicio Google Cloud Build tiene muchos privilegios, con muchas acciones para interactuar con el Registro de artefactos de Goggle.
Al explotar la vulnerabilidad que permite la suplantación de la cuenta de servicio predeterminada de Cloud Build, los actores maliciosos obtienen la capacidad de alterar las imágenes almacenadas en el Registro de artefactos de Google mediante la inyección de código malicioso. En consecuencia, cualquier aplicación creada a partir de estas imágenes comprometidas se vuelve susceptible a posibles consecuencias, incluidos ataques de denegación de servicio (DoS), robo de datos y propagación de malware.
La gravedad de la situación aumenta cuando estas aplicaciones manipuladas están destinadas a implementarse en los entornos de los clientes, ya sea on-premise o semi-SaaS. Esto amplía el riesgo más allá de la infraestructura de la organización proveedora, lo que da lugar a un ataque a la cadena de suministro que se infiltra y compromete los entornos de los clientes. Estos ataques son similares a incidentes previos observados en vulneraciones de la cadena de suministro de software, como la de SolarWinds. Las implicaciones de un ataque de este tipo pueden ser graves, causando daños generalizados y afectando a múltiples organizaciones dentro de la cadena de suministro.
Hubo una PoC de escalada de privilegios similar por parte de Laboratorios de seguridad de Rhino, que explotaba de otra manera los privilegios excesivos de la cuenta predeterminada de Cloud Build.
¿Por qué es peligroso?
La gravedad de esta vulnerabilidad radica en su potencial para que los atacantes exploten el Registro de artefactos e introduzcan código malicioso en los artefactos. Como resultado, cualquier aplicación creada a partir de estas imágenes comprometidas se vuelve susceptible a diversos efectos adversos.
Estos efectos incluyen la posibilidad de ataques de denegación de servicio, robo de datos y propagación de malware. Además, si estas aplicaciones comprometidas se implementan posteriormente... on-premise En un entorno semi-SaaS, el riesgo se extiende más allá de la organización víctima y afecta también a sus clientes. Este escenario se asemeja al ataque a la cadena de suministro observado en el incidente de SolarWinds, lo que pone de relieve las posibles consecuencias tanto para la organización como para su base de clientes.
-
Recomendación de Xygeni
Aplicar el principio de privilegio mínimo
- Sensor Xygeni monitorea las acciones del usuario en los sistemas donde está implementado y las comparte con nuestra plataforma principal, que identifica comportamientos inusuales o desviaciones de los patrones normales, como comportamientos inusuales. login horarios o ubicaciones, grandes transferencias de datos o cambios en los derechos de acceso de los usuarios que están fuera del rango del comportamiento "normal" del usuario modelado.
Las políticas y auditorías de Xygeni aplican las mejores prácticas en controles de acceso, requisitos de autenticación multifactor y aplicaciones de permisos basados en roles para limitar el acceso de los usuarios a sistemas y datos críticos.
Estas herramientas monitorean las acciones del usuario, como cambios de código, acceso al sistema o transferencias de datos, y las comparan con políticas y patrones de comportamiento predefinidos. También señalan actividades sospechosas, como acceso no autorizado, privilegios excesivos o patrones inusuales de transferencia de datos..
Cómo se manejó la vulnerabilidad
Al notificar la vulnerabilidad al equipo de seguridad de Google, tomaron medidas revocando el permiso logging.privateLogEntries.list de la cuenta predeterminada del servicio Cloud Build. Reconocieron que, si bien los registros de auditoría de setIamPolicy son relevantes para fines de auditoría, era innecesario otorgar acceso a estos registros desde la perspectiva de la cuenta de servicio de compilación en la nube.
Sin embargo, es fundamental comprender que esta respuesta no abordó directamente la vulnerabilidad raíz dentro del Registro de artefactos. Como resultado, el vector de escalada de privilegios y el riesgo potencial de un ataque a la cadena de suministro no se vieron afectados. Básicamente, la solución de Google limitó el problema, pero no lo eliminó por completo, lo que dejó a las organizaciones aún expuestas a importantes riesgos en la cadena de suministro de software.
En respuesta a la situación, Google aconsejó a sus clientes que modificaran los permisos de la cuenta de servicio Cloud Build predeterminada eliminando cualquier credencial de derechos que se desviara del principio de mínimo privilegio (PoLP). Esta medida tiene como objetivo mejorar la seguridad garantizando que las cuentas solo tengan los privilegios mínimos necesarios para realizar las tareas previstas.
Para defenderse de este ataque de escalada de privilegios, es necesario restringir los permisos otorgados a la cuenta del servicio Cloud Build y tener cuidado al otorgar los permisos. cloudbuild.builds.create permiso a cualquier usuario de su organización. Lo más importante es que debe saber que cualquier usuario al que se le conceda cloudbuild.builds.create, también se le otorgan indirectamente todos los permisos otorgados a la cuenta de servicio Cloud Build. Si le parece bien, es posible que no tenga que preocuparse por este vector de ataque, pero aun así se recomienda encarecidamente modificar los permisos predeterminados otorgados a la cuenta de servicio Cloud Build.
Google recomienda esto sucintamente, pero no proporciona más detalles:
"Si no planea realizar una acción como parte del proceso de compilación, le recomendamos que revoque el permiso correspondiente de la cuenta del servicio Cloud Build para cumplir con el principio de seguridad de privilegio mínimo".
Cronograma
Sin embargo, es esencial tener en cuenta que la solución de Google no eliminó por completo el vector de escalada de privilegios (PE) descubierto. En cambio, restringió su impacto, transformándolo efectivamente en un defecto de diseño que aún expone a las organizaciones al riesgo más amplio de un ataque a la cadena de suministro. En consecuencia, son necesarias medidas adicionales para que los equipos de seguridad se protejan contra este riesgo persistente.
Conclusión
Los adversarios podrían aprovechar los privilegios excesivos otorgados a la cuenta predeterminada de Google Cloud Build para montar un ataque utilizando una cuenta de desarrollador que permita crear una compilación en la nube. Los atacantes pueden filtrar una imagen de contenedor, manipularla con comportamiento malicioso y luego enviarla al Registro de artefactos, en un ataque a la cadena de suministro de software que puede tener consecuencias devastadoras.
La respuesta de Google deja la tarea de mitigación en manos de las organizaciones que utilizan el servicio Cloud Build, quienes deben revocar los privilegios para controlar el riesgo. Se podría solicitar a Google ayuda adicional en el futuro para gestionar los problemas de seguridad con sus... CI/CD .
Referencias
- Funcionamiento según lo previsto: escalada de privilegios de RCE a IAM en GCP Cloud Build. Laboratorios de seguridad de Rhino.
- Bad.Build: vulnerabilidades de PE y RCE en Google Cloud Build. Seguridad de las Orcas.
- Boletín de seguridad. Nube de Google.
Conozca más sobre la Plataforma Xygeni, descargue la ficha técnica de la plataforma Xygeni
