Una cadena de exploits podría permitir a un usuario malicioso de Azure infiltrarse en las instancias de nube de otros clientes dentro de la oferta de contenedores como servicio de Microsoft.
Los investigadores han descubierto una vulnerabilidad de seguridad crítica que permite a los atacantes realizar una toma de posesión de contenedores entre cuentas en la nube pública de Microsoft, denominada «Azurescape».
El problema existe en Azure Container Instances (ACI), que es la oferta de contenedores como servicio (CaaS) de Microsoft (que permite a los usuarios ejecutar contenedores en la nube sin tener que ocuparse de gestionar la infraestructura subyacente). Parte de la infraestructura que aloja ACI consiste en clústeres Kubernetes multitenant, que pueden ser comprometidos para permitir a los ciberatacantes obtener el control total de los contenedores de otros usuarios, explicaron los investigadores del equipo Unit 42 de Palo Alto Networks.
«Un usuario malicioso de Azure podría haber aprovechado estos problemas para ejecutar código en los contenedores de otros usuarios, robar los secretos de los clientes y las imágenes desplegadas en la plataforma, y posiblemente abusar de la infraestructura de ACI para la minería de criptomonedas», dijeron en una publicación del jueves.
Microsoft ha lanzado un parche para ACI, pero los usuarios deben revocar cualquier credencial privilegiada que se haya desplegado en la plataforma antes del 31 de agosto para evitar el peligro. También deberían revisar los registros de acceso para detectar cualquier irregularidad, recomendó Unit 42.
ACI Multitenant Architecture – Buenas vallas, buenos vecinos
In the multitenant architecture, each customer’s container is hosted in a Kubernetes pod on a dedicated, single-tenant node virtual machine (VM), according to the analysis, and the boundaries between customers are enforced by this node-per-tenant structure.
“Since practically anyone can deploy a container to the platform, ACI must ensure that malicious containers cannot disrupt, leak information, execute code or otherwise affect other customers’ containers,” explained researchers. “These are often called cross-account or cross-tenant attacks.”
The Azurescape version of such an attack has two prongs: First, malicious Azure customers/adversaries must escape their container; then, they must acquire a privileged Kubernetes service account token that can be used to take over the Kubernetes API server.
The API Server provides the frontend for a cluster’s shared state, through which all of the nodes interact, and it’s responsible for processing commands within each node by interacting with Kubelets. Each node has its own Kubelet, which is the primary “node agent” that handles all tasks for that specific node.
Thus, the end result of an API server compromise is “establishing complete control over the multitenant cluster and all customer containers running within it,” according to Unit 42.
Escape de contenedores Kubernetes
El primer paso del ataque resultó más fácil de lo esperado. Los investigadores de Unit 42 descubrieron que Azure utiliza RunC, el tiempo de ejecución de contenedores estándar del sector, para alimentar ACI. Por desgracia, se trata de una versión antigua de la tecnología (RunC v1.0.0-rc2), que se publicó el 1 de octubre de 2016.
Fiel a la forma del software heredado, alberga al menos dos errores de escape de contenedores. Los investigadores de Unit 42 utilizaron uno de ellos (CVE-2019-5736) para escapar de un contenedor ACI de prueba, obteniendo un shell inverso que se ejecuta como root en el nodo Kubernetes subyacente.
«Aunque escapamos de nuestro contenedor, todavía estábamos dentro del límite del inquilino: la VM del nodo», explicaron los investigadores. «Las plataformas CaaS están diseñadas para resistir a atacantes sofisticados que poseen vulnerabilidades en el kernel que permiten la escalada de privilegios y la fuga del contenedor. Un contenedor malicioso que se escapa es una amenaza algo esperada, tolerada a través del aislamiento a nivel de nodo.»
Obtención de un token de cuenta privilegiada de Kubernetes
Escapar de esta VM de nodo subyacente -la frontera con otros clientes- significa encontrar una forma de acceder al servidor de la API y obligarlo a ejecutar comandos en los nodos vecinos. La mejor manera de hacerlo es obtener un token de acceso privilegiado para el servidor de la API, descubrieron pronto los investigadores.
En la búsqueda de una forma de obtener tales privilegios, los investigadores observaron que ACI admite la ejecución de comandos de VM de nodo en contenedores cargados a través del comando exec «az container» a un Kubelet, que es manejado por un pod de puente dedicado en lugar del propio servidor API (los investigadores dijeron que la implementación del pod de puente es una solución para una vulnerabilidad anterior).
Curiosamente, los investigadores descubrieron que estas solicitudes de ejecución que llegaban al nodo incluían una cabecera de autorización que llevaba un token de cuenta de servicio de Kubernetes para esta cuenta de servicio «puente».
«Encontrar un token aquí fue sorprendente», según el análisis. «Los Kubelets en el clúster estaban configurados para permitir el acceso anónimo, por lo que no había necesidad de que las solicitudes se autenticaran a través de un token. Quizás esto era una reliquia de una implementación más antigua».
Los investigadores examinaron entonces los permisos del token y descubrieron que podía utilizarse para ejecutar comandos en cualquier pod del clúster, incluido el pod del servidor API.
A partir de ahí, la explotación fue sencilla, dijeron – y rápidamente tuvieron éxito en el uso del token para abrir un shell en el contenedor del servidor de la API como un administrador del clúster, con pleno control sobre el clúster multitenant y todos los contenedores de los clientes dentro de ella.
«Si ejecutas Kubernetes, ten cuidado a quién envías tus tokens de cuenta de servicio: Cualquiera que reciba un token es libre de utilizarlo y hacerse pasar por su propietario», señalaron los investigadores. «Es probable que los ladrones de tokens estén muy interesados en los permisos de sus tokens robados».
Pasos del Exploit Azurescape
En resumen, el exploit Azurescape funcionaba así, como se demuestra en este vídeo:
- Despliegue de una imagen que explota CVE-2019-5736 en ACI. La imagen maliciosa se rompe al ejecutarse y establece la ejecución de código en el nodo subyacente;
- En el nodo, supervisa el tráfico en el puerto Kubelet, el puerto 10250, y espera una solicitud que incluya un token JWT en la cabecera Authorization;
- Emita el comando exec «az container» para ejecutar un comando en el contenedor cargado. El pod puente enviará ahora una petición exec al Kubelet en el nodo comprometido; y
- En el nodo, extraiga el token de puente de la cabecera Authorization de la solicitud y utilícelo para abrir un shell en el servidor de la API.
La solución era sencilla: Microsoft simplemente se aseguró de que el pod de puente ya no enviara su token de cuenta de servicio a los nodos al emitir solicitudes de ejecución.
Cómo prevenir los ataques cruzados en la nube
Azurescape puede ser mitigado, pero es probable que haya otras vías para lograr este tipo de explotación, advirtieron los investigadores de Unit 42.
«Las vulnerabilidades de cuentas cruzadas se describen a menudo como un escenario de ‘pesadilla’ para la nube pública», concluyeron. «Azurescape es una prueba de que son más reales de lo que nos gustaría pensar. Los proveedores de la nube invierten mucho en asegurar sus plataformas, pero es inevitable que existan vulnerabilidades desconocidas de día cero que pongan en riesgo a los clientes.»
Para proteger los activos de Kubernetes de uno, los usuarios pueden implementar las siguientes mejores prácticas, aconsejó la firma:
- Mantenga la infraestructura del clúster parcheada;
- No envíe tokens de cuentas de servicio privilegiadas a nadie más que al servidor de la API para evitar que los atacantes se hagan pasar por el propietario del token;
- Habilitar la función «BoundServiceAccountTokenVolume»: Cuando un pod termina, su token deja de ser válido, minimizando el impacto del robo de tokens;
- Despliegue de aplicadores de políticas para supervisar y prevenir la actividad sospechosa dentro de los clusters, especialmente las cuentas de servicio o los nodos que consultan las API SelfSubjectAccessReview o SelfSubjectRulesReview para sus permisos.
Sobre este último punto: «Vemos que los adversarios abusan activamente de las API SelfSubjectReview para inspeccionar los privilegios de las credenciales de Kubernetes robadas», según el análisis. «[Hemos] observado recientemente que el malware Siloscape aprovecha estas API para recuperar los permisos del nodo que ha comprometido, y luego los utiliza para determinar si debe continuar su campaña contra el clúster».
