Investigadores de ciberseguridad han revelado una falla de seguridad que afecta a Microsoft Azure Kubernetes Services que, si se explota con éxito, podría permitir a un atacante aumentar sus privilegios y credenciales de acceso para los servicios utilizados por el clúster.
«Un atacante con ejecución de comandos en un Pod que se ejecuta dentro de un clúster de Azure Kubernetes Services afectado podría descargar la configuración utilizada para aprovisionar el nodo del clúster, extraer los tokens de arranque de seguridad de la capa de transporte (TLS) y realizar un ataque de arranque TLS para leer todos los secretos dentro del clúster», dijo Mandiant, propiedad de Google. dicho.
Se ha descubierto que los clústeres que utilizan «Azure CNI» para la «Configuración de red» y «Azure» para la «Política de red» se ven afectados por el error de escalada de privilegios. Microsoft ha abordado el problema después de una divulgación responsable.
La técnica de ataque ideada por la empresa de inteligencia de amenazas se basa en acceder a un componente poco conocido llamado Azure WireServer para solicitar una clave utilizada para cifrar valores de configuración protegidos («wireserver.key») y usarla para decodificar un script de aprovisionamiento que incluye varios secretos como los siguientes:
- KUBELET_CLIENT_CONTENT (clave TLS de nodo genérico)
- KUBELET_CLIENT_CERT_CONTENT (Certificado TLS de nodo genérico)
- KUBELET_CA_CRT (Certificado CA de Kubernetes)
- TLS_BOOTSTRAP_TOKEN (Token de autenticación de arranque TLS)
«KUBELET_CLIENT_CONTENT, KUBELET_CLIENT_CERT_CONTENT y KUBELET_CA_CRT se pueden decodificar en Base64 y escribir en el disco para usar con la herramienta de línea de comandos de Kubernetes kubectl para autenticarse en el clúster», dijeron los investigadores Nick McClendon, Daniel McNamara y Jacob Paullus.
«Esta cuenta tiene permisos mínimos de Kubernetes en clústeres de Azure Kubernetes Service (AKS) implementados recientemente, pero puede enumerar nodos en el clúster».
TLS_BOOTSTRAP_TOKEN, por otro lado, podría usarse para habilitar un Ataque de arranque TLS y, en última instancia, obtener acceso a todos los secretos utilizados por las cargas de trabajo en ejecución. El ataque no requiere que el pod se ejecute como raíz.
«Adoptar un proceso para crear políticas de red restrictivas que permitan el acceso solo a los servicios requeridos previene toda esta clase de ataque», afirmó Mandiant. «Se evita la escalada de privilegios a través de un servicio no documentado cuando no se puede acceder a él en absoluto».
La revelación se produce cuando la plataforma de seguridad de Kubernetes ARMO destacó una nueva falla de alta gravedad de Kubernetes (CVE-2024-7646Puntuación CVSS: 8,8) que afecta al controlador ingress-nginx y podría permitir que un actor malintencionado obtenga acceso no autorizado a recursos confidenciales del clúster.
«La vulnerabilidad se debe a una falla en la forma en que ingress-nginx valida las anotaciones en los objetos Ingress», dijo el investigador de seguridad Amit Schendel. dicho.
«La vulnerabilidad permite a un atacante inyectar contenido malicioso en ciertas anotaciones, evadiendo las comprobaciones de validación previstas. Esto puede provocar la inyección de comandos arbitrarios y el posible acceso a las credenciales del controlador ingress-nginx, que, en las configuraciones predeterminadas, tiene acceso a todos los secretos del clúster».
También se produce tras el descubrimiento de un fallo de diseño en Kubernetes. proyecto git-sync que podría permitir la inyección de comandos en Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) y Linode.
«Esta falla de diseño puede provocar la exfiltración de datos de cualquier archivo en el pod (incluidos los tokens de la cuenta de servicio) o la ejecución de comandos con los privilegios de usuario git_sync», dijo el investigador de Akamai, Tomer Peled. dicho«Para explotar la falla, todo lo que un atacante necesita hacer es aplicar un archivo YAML en el clúster, lo cual es una operación que requiere pocos privilegios».
No se están planificando parches para la vulnerabilidad, por lo que es crucial que las organizaciones auditen sus pods git-sync para determinar qué comandos se están ejecutando.
«Ambos vectores se deben a una falta de limpieza de la entrada, lo que resalta la necesidad de una defensa sólida en lo que respecta a la limpieza de la entrada del usuario», dijo Peled. «Los miembros del equipo azul deben estar atentos a comportamientos inusuales provenientes del usuario gitsync en sus organizaciones».