Error de Containerd expone credenciales en la nube

El defecto (CVE-2020-15157) se encuentra en el proceso de extracción de imágenes del contenedor. Containerd se anuncia a sí mismo como una herramienta en tiempo de ejecución que «gestiona el ciclo de vida completo del contenedor de su sistema host, desde la transferencia y el almacenamiento de imágenes hasta la ejecución y supervisión del contenedor, […]

El defecto (CVE-2020-15157) se encuentra en el proceso de extracción de imágenes del contenedor.

Containerd se anuncia a sí mismo como una herramienta en tiempo de ejecución que «gestiona el ciclo de vida completo del contenedor de su sistema host, desde la transferencia y el almacenamiento de imágenes hasta la ejecución y supervisión del contenedor, el almacenamiento de bajo nivel, los adjuntos de red y más». Como tal, ofrece una visibilidad profunda en el entorno de nube de un usuario, a través de múltiples proveedores.

El error (CVE-2020-15157) se encuentra en el proceso de extracción de imágenes del contenedor, según Gal Singer, investigadora de Aqua. Los adversarios pueden aprovechar esta vulnerabilidad creando imágenes de contenedor diseñadas para robar el token del host y luego usando el token para hacerse cargo de un proyecto en la nube, explicó.

Por lo tanto, los atacantes pueden aprovechar el problema creando una imagen maliciosa en un registro remoto y luego convenciendo al usuario de que acceda a ella a través de un contenedor (esto se puede hacer a través del correo electrónico y otras vías de ingeniería social).

Explotación no trivial

El investigador Brad Geesaman de Darkbit, que realizó una investigación original sobre la vulnerabilidad (que él llama «ContainerDrip»), armó una vulnerabilidad de prueba de concepto (PoC) para un vector de ataque relacionado.

Uno de los obstáculos para la explotación es el hecho de que los clientes en contenedores que extraen imágenes pueden configurarse para autenticarse en un registro remoto con el fin de obtener imágenes privadas, lo que evitaría que accedan al contenido malicioso. En cambio, un atacante necesitaría colocar la imagen contaminada en un registro remoto en el que el usuario ya se autentica.

“La pregunta fue: ‘¿Cómo hago para que me envíen sus credenciales [para la autenticación de registro remoto]?’”, Dijo en una publicación a principios de este mes. «Resulta que todo lo que tienes que hacer es hacer la pregunta correcta».

Google Kubernetes Engine (GKE) es un entorno administrado para ejecutar aplicaciones en contenedores, que se pueden integrar con containerd. Cuando los clústeres de GKE que ejecutan COS_CONTAINERD y GKE 1.16 o una versión inferior reciben una implementación para ejecutar, aparece un encabezado de autenticación básica, que cuando se decodifica en base64, resulta ser el token de autenticación para el Google Compute Engine subyacente, que se usa para crear máquinas virtuales. Este token está adjunto al clúster / grupo de nodos de GKE.

«De forma predeterminada, en GKE, la cuenta de servicio [Google Cloud Platform] adjunta al grupo de nodos es la cuenta de servicio de procesamiento predeterminada y se le otorga el Editor de proyectos», explicó Geesaman.

Dicho esto, también de forma predeterminada, una función llamada GKE OAuth Scopes «reduce el alcance» de los permisos disponibles de ese token. Geesaman también encontró una solución para eso.

«Si se modificaran los valores predeterminados al crear el clúster para otorgar el alcance [» cualquier «] al grupo de nodos, este token no tendría restricciones de alcance de OAuth y otorgaría el conjunto completo de permisos de IAM del editor de proyectos en ese proyecto de GCP», explicó.

Y a partir de ahí, los atacantes pueden escalar los privilegios a «Propietario del proyecto» utilizando un vector de ataque conocido demostrado en DEF CON 2020.