Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Falla sin parchear en Repo-Server de Argo CD podría permitir el control total de clústeres de Kubernetes


Se ha descubierto una vulnerabilidad crítica sin parchear en el componente repo-server de Argo CD que permite la ejecución remota de código. Un atacante que acceda a la red interna puede tomar el control total del clúster manipulando la herramienta kustomize y envenenando la caché de Redis. La única defensa actual es activar estrictamente las políticas de red de Kubernetes para aislar los puertos internos.





Argo CD, una herramienta muy utilizada para desplegar software en Kubernetes, tiene un fallo sin parchear en su componente repo-server que permite a un atacante no autenticado ejecutar código, siempre que pueda acceder al puerto de la red interna del componente.

Synacktiv, que descubrió el error, afirma que puede conducir a la toma de control total del clúster. No hay solución ni CVE. La firma dice que informó del fallo a los mantenedores de Argo CD en enero de 2025; aproximadamente dieciocho meses después, sigue sin parchear, por lo que publicó los detalles para advertir a los usuarios.

El error reside en repo-server, el componente de Argo CD que lee los repositorios Git y construye los manifiestos de Kubernetes, los archivos que definen lo que despliega el clúster.

Su servicio gRPC interno no tiene autenticación; cualquier persona que pueda llegar a él puede enviar una solicitud manipulada para ejecutar un comando. Synacktiv demostró el ataque contra Argo CD v2.13.3 e informa que no hay una versión parcheada; no publicó una lista completa de las versiones afectadas.



La técnica abusa de kustomize, una herramienta estándar que Argo CD ejecuta para convertir los archivos del repositorio en manifiestos. Kustomize tiene una opción --helm-command que apunta al binario de helm que debe llamar.

Synacktiv descubrió que una solicitud no autenticada al servicio GenerateManifest del repo-server puede cambiar esa opción por un script, extraído de un repositorio Git controlado por un atacante. Cuando kustomize se ejecuta, ejecuta el script en lugar de helm.

Pero "interno" no significa aislado por defecto. Argo CD incluye políticas de red de Kubernetes que aíslan el repo-server de todo excepto de sus propios componentes.

Synacktiv descubrió que el Helm chart, una forma común de instalar Argo CD, desactiva esas políticas por defecto, con networkPolicy.create establecido en false. En esa configuración, un atacante que comprometa un solo pod en el clúster puede llegar al repo-server y activar el error.

Ejecutar código en el repo-server no es el final. Synacktiv utilizó ese acceso para leer la contraseña de Redis del clúster desde una variable de entorno, conectarse a la caché Redis de Argo CD y envenenar los datos de despliegue almacenados. En la siguiente sincronización automática, Argo CD desplegó una carga de trabajo suministrada por el atacante.

Ese paso revive el CVE-2024-31989, un fallo de 2024 que Cycode encontró donde el Redis de Argo CD no tenía contraseña, permitiendo que cualquier pod en el clúster envenenara la caché de despliegue. Argo CD lo solucionó añadiendo una contraseña de Redis, pero la caché en sí sigue sin estar firmada, por lo que robar la contraseña vuelve a abrir el mismo ataque.

Qué hacer

No hay una versión parcheada, por lo que la defensa es el aislamiento de la red. Activa las políticas de red de Kubernetes para que solo los componentes propios de Argo CD puedan llegar a los puertos de Redis y repo-server. Argo CD proporciona los archivos de política; los usuarios de Helm deben habilitarlos porque el chart los deja desactivados.

Comprueba qué está activo con: kubectl get networkpolicy -A. Una instalación saludable muestra una política de red por componente, incluidos repo-server y Redis. Si faltan esas políticas, los puertos de repo-server y Redis son accesibles desde el resto del clúster.

Synacktiv creó una herramienta, argo-cdown, que automatiza todo el ataque. Está reteniendo la herramienta por ahora para dar tiempo a los defensores a bloquear sus políticas de red, y dice que la publicará en GitHub más tarde para que los administradores puedan probar sus propios despliegues.

Esta no es la primera exposición de los internos de Argo CD. En septiembre de 2025, parcheó el CVE-2025-55190, donde un token de API con solo acceso de lectura básico podía extraer las credenciales del repositorio Git de un proyecto.




En mayo de 2026, otro error, CVE-2026-42880, permitió a los usuarios de solo lectura leer secretos de Kubernetes en texto plano. El patrón es difícil de ignorar: Argo CD concentra el acceso al clúster y los secretos del repositorio, y sus superficies internas siguen entregándolos, ya sea mediante una solicitud no autenticada en un error o un token de bajos privilegios en el siguiente.




Hasta que llegue un parche, tratar la red del clúster como hostil es la única defensa real.

Fuente:
THN

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.