Lecciones aprendidas de la vulnerabilidad de día cero de Argo CD (CVE-2022-24348)

El 30 de enero de 2022, el equipo de Argo CD recibió un aviso de investigadores de Apiiro sobre una vulnerabilidad que habían descubierto en la popular plataforma de entrega continua, que podía permitir que actores maliciosos robaran información confidencial de las implementaciones. El equipo de Argo CD pudo desarrollar rápidamente correcciones para las tres versiones que aún reciben soporte y publicarlas para sus usuarios en un plazo de 48 horas. En su artículo sobre la CVE, Dan Garfield, cofundador de CodeFresh y responsable del proyecto Argo, atribuye la rápida respuesta a que el proyecto había mantenido un enfoque de seguridad en toda la plataforma durante los últimos 18 meses.

En este artículo, hablaremos sobre la vulnerabilidad y sus implicaciones más amplias para protegerte contra el tipo de ataque a la cadena de suministro que esta vulnerabilidad podría haber provocado.

¿Qué es la vulnerabilidad de Argo CD?

En esencia, CVE-2022-24348 es una vulnerabilidad de recorrido de directorios/rutas que permite que un atacante use un chart de Helm malicioso para acceder a datos de otras aplicaciones. Esto podría conducir a una escalada de privilegios y a una mayor explotación del clúster de Kubernetes en el que se ejecuta Argo CD.

¿Cómo sabemos si somos vulnerables?

Si usas Argo CD 0.5.0 a 2.1.12, 2.2.7 o 2.3.1, eres vulnerable y debes actualizar de inmediato a las versiones más recientes. Al 24 de marzo de 2022, son:

• 2.3.2

• 2.2.8

• 2.1.14

¿Cuál es el riesgo?

Este es otro ejemplo de los vectores de la creciente lista de ataques a la cadena de suministro, en los que los actores maliciosos intentan infiltrarse en el software mientras se desarrolla, en lugar de asaltar las puertas de entrada una vez que se publica. Algunos ejemplos recientes incluyen ataques a CodeCov, la App Store de iOS y, el más famoso, SolarWinds. En este incidente reciente, un atacante podría crear un chart de Helm malicioso que explote la vulnerabilidad y le permita acceder a datos confidenciales de otras aplicaciones en el reposerver de Argo CD.

Los detalles sobre cómo funciona esta vulnerabilidad están en la divulgación original de la CVE, así que no repetiremos todo aquí. Basta con decir que, al crear un chart de Helm que incluya un URI con una ruta de archivo absoluta, específica y predecible, un atacante podría exfiltrar datos confidenciales del sistema de archivos en esa ruta del reposerver de Argo, incluidos datos de los ámbitos de otras aplicaciones y usuarios.

¿Cuál es la solución?

Si llegaste aquí buscando la solución para CVE-2022-24348 en tus clústeres, es sencillo: deja de leer y actualiza de inmediato tus implementaciones de Argo CD. Luego regresa y sigue leyendo para conocer el panorama general.

¿Listo? ¡Bien! Ahora hablemos de los desafíos más amplios que enfrentamos en torno a la seguridad de la cadena de suministro de software.

Cómo mitigar los ataques a la cadena de suministro

¿Cómo podemos protegernos del próximo ataque de día cero como este? Como la naturaleza de la vulnerabilidad es específica de la aplicación Argo CD, no hay una respuesta fácil ni genérica, pero puedes implementar algunas prácticas de alto nivel para evitar que archivos creados maliciosamente, como el chart de Helm en este caso, lleguen a tus sistemas:

1. Procura que los commits sean pequeños y fáciles de revisar

La práctica ágil de hacer cambios pequeños e iterativos no solo es una buena forma de mantener un desarrollo ordenado; también facilita detectar cambios inseguros o cuestionables cuando se envían. No decimos que alguien en tu organización copiaría y pegaría código cuestionable de Stack Overflow, pero sería mucho más fácil detectarlo en una revisión de código si no estuviera oculto en un commit de mil líneas.

2. Trata todos tus sistemas del SDLC como si fueran de producción

Muchos somos culpables de tratar nuestros servidores de compilación —sobre todo los que armamos por nuestra cuenta— como juguetes. Ya sabes: ese servidor de Jenkins, GitLab o RunDeck que está en una computadora de escritorio adicional en el cuarto de red, con una contraseña de administrador conocida y un par de cientos de complementos que usan las credenciales de algún desarrollador para conectarse a servicios externos. Sí… ¡ese! (No estamos señalando a estos proyectos en particular; cualquier herramienta mal administrada es una oportunidad fácil para un atacante).

Históricamente, los servidores de compilación y despliegue se han considerado de baja prioridad y no se han reforzado lo suficiente contra ataques. Los ataques a SolarWinds y CodeCov, por ejemplo, demuestran que estos sistemas deben tratarse con la misma seriedad que los servidores de producción que alojan los datos de tus usuarios.

• No uses credenciales compartidas.

• No uses complementos, acciones ni módulos personalizados que no hayan sido evaluados.

• Asegúrate siempre de usar RBAC centralizado y adecuado para limitar los accesos como corresponde.

3. Conoce tu cadena de suministro

Es fundamental conocer el origen de los artefactos que crean tus sistemas y qué contienen. Implementar una cadena de suministro segura es un tema que podría llenar varios libros. De hecho, ¡hay conferencias enteras dedicadas a estos temas! Estas son algunas áreas clave a las que debes prestar atención:

• No confíes a ciegas en imágenes de contenedores, paquetes de sistemas operativos, bibliotecas de código ni charts de Helm que provengan de fuentes fuera de tu control. Los repositorios privados y administrados, con artefactos evaluados y firmados, son esenciales para garantizar que las dependencias de tus aplicaciones sean confiables. Un patrón común que hemos visto implementar con éxito en este escenario consiste en tener un repositorio de “cuarentena”, donde los equipos pueden importar los artefactos recién adquiridos para que Seguridad los evalúe y se realicen pruebas funcionales. Después, pueden trasladarlos a un repositorio al que los desarrolladores y los sistemas de compilación tengan acceso general. Por supuesto, esta evaluación debe equilibrarse con la necesidad del equipo de avanzar rápido; por eso, el proceso debe adaptarse al contexto del negocio y establecer medidas de protección. Naturalmente, los equipos también deben analizar estos artefactos en busca de vulnerabilidades. Siempre que sea posible, esto incluye los archivos de configuración de IaC. También es importante volver a analizarlos con regularidad, por si se descubren nuevas vulnerabilidades. Snyk puede ayudarte a analizar y corregir vulnerabilidades y errores de configuración.

• Implementa una lista de materiales de software (SBoM) para tus aplicaciones. Este es un campo que evoluciona rápidamente y, por suerte, está recibiendo mucha atención gracias a los requisitos establecidos en una orden ejecutiva presidencial de Estados Unidos de 2021.

• Otro tema interesante: los commits de Git firmados, que permitirían detectar cambios de código realizados por terceros no verificados. Para ser sincero, no los he visto usar de forma generalizada y no son la solución mágica que podrían parecer. Dan Lorenc, experto en este campo, explica muy bien sus ventajas y desventajas en su artículo de julio de 2021: ¿Deberías firmar los commits de Git?.

Todo se trata de DevSecOps

Las herramientas y prácticas que describimos aquí apuntan a un hecho importante: para proteger nuestras cadenas de suministro, necesitamos a todo el equipo, desde los desarrolladores hasta los SRE y todos los demás. Cuanto más empoderemos a los desarrolladores y les proporcionemos herramientas y procesos que los incluyan, en lugar de limitarlos o controlarlos, más éxito tendremos al proteger nuestras aplicaciones. Al integrar herramientas como Snyk en el SDLC, podemos ayudar a los desarrolladores a encontrar fácilmente vulnerabilidades de seguridad en su trabajo, ¡antes incluso de lanzar una versión! De eso se tratan shift-left y DevSecOps; me hace recordar esa declaración de Dan sobre el enfoque del equipo de Argo CD en la seguridad. Aunque no conozco de primera mano cómo trabaja su equipo, es evidente que su rapidez de respuesta y la conversación transparente sobre esta vulnerabilidad influyeron directamente en la velocidad con la que la abordaron.

En nuestro Informe sobre el estado de la seguridad de las aplicaciones nativas de la nube de 2021, descubrimos que las empresas que automatizan ampliamente las pruebas en su SDLC tienen el doble de probabilidades de implementar pruebas de seguridad. Más del 72 % de ellas informó que el tiempo promedio para corregir vulnerabilidades era de menos de una semana, ¡y el 36 % promediaba un día o menos! Según la documentación del proyecto Argo, está claro que siguen estas prácticas. Su rápida respuesta ante este problema lo demuestra.

Para seguir leyendo

Aquí tienes algunos recursos adicionales sobre los temas que tratamos:

• Más información sobre las vulnerabilidades de recorrido de directorios

• Cómo proteger tu cadena de suministro de software moderna

• Cómo prevenir paquetes maliciosos y ataques a la cadena de suministro con Snyk

• SnykCon 2021: seguridad de la cadena de suministro, el futuro de la ciberseguridad, la automatización como facilitador y más