20 de agosto de 2024Ravie LakshmananVulnerabilidad / Seguridad de contenedores Los 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 escalar 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. 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. Desde entonces, Microsoft ha abordado el problema tras 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 TLS Bootstrap) «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 evita toda esta clase de ataque», dijo Mandiant. «Se evita la escalada de privilegios a través de un servicio no documentado cuando no se puede acceder al servicio en absoluto». La divulgación se produce cuando la plataforma de seguridad de Kubernetes ARMO destacó una nueva falla de Kubernetes de alta gravedad (CVE-2024-7646, puntaje 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 un fallo en la forma en que ingress-nginx valida las anotaciones en los objetos de Ingress», dijo el investigador de seguridad Amit Schendel. «La vulnerabilidad permite a un atacante inyectar contenido malicioso en ciertas anotaciones, omitiendo 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 sigue al descubrimiento de un fallo de diseño en el proyecto git-sync de Kubernetes 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. «Este fallo 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. «Para explotar la falla, todo lo que un atacante necesita hacer es aplicar un archivo YAML en el clúster, que es una operación de bajo privilegio». No se están planeando 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 desinfección de la entrada, lo que resalta la necesidad de una defensa sólida con respecto a la desinfección de la entrada del usuario», dijo Peled. «Los miembros del equipo azul deben estar atentos a un comportamiento inusual proveniente del usuario gitsync en sus organizaciones». ¿Le resultó interesante este artículo? Síganos en Twitter  y LinkedIn para leer más contenido exclusivo que publicamos.