El Viernes Santo, el desarrollador de Microsoft, Andrés Freund, lanzó una bomba de Pascua. Mientras solucionaba algunos problemas de rendimiento aparentemente inofensivos en un sistema Debian Linux, se topó con lo que había sido descrito como el ataque a la cadena de suministro "mejor ejecutado" jamás visto.

Tendrá importantes implicaciones para los equipos de seguridad de TI y para cómo gestionan el riesgo de código abierto en el futuro.

¿Que pasó?

El ataque fue increíblemente complejo. Pero parece haber sido un intento patrocinado por el estado de insertar una puerta trasera en un componente popular de código abierto conocido como xz Utils. La utilidad de compresión de datos se puede encontrar en casi todos los sistemas Linux. La puerta trasera y la vulnerabilidad asociada, CVE-2024-3094, están diseñadas para inyectar código malicioso en un servidor OpenSSH (SSHD) que se ejecuta en la máquina de la víctima. Hay más detalles aquí, pero el tl;dr es que permitiría a atacantes remotos en posesión de una clave privada específica secuestrar de forma remota una máquina específica.

En resumen, es lo más serio posible, razón por la cual el CVE recibió una puntuación CVSS de 10.0. Afortunadamente, el ataque se detectó antes de que la actualización maliciosa xz Utils se fusionara con las principales distribuciones de Linux. En ese momento, podría haberle dado al actor de amenazas detrás de él acceso remoto a un número desconocido de máquinas globales.

La sofisticación y la planificación paciente que se utilizaron en este ataque apuntan al respaldo de un Estado-nación. Podemos deducir esto porque:

  • La puerta trasera en sí tiene una cadena de ejecución compleja que comprende múltiples etapas.
  • La puerta trasera se introdujo a través de múltiples confirmaciones.
  • Estas confirmaciones solo se incluyeron en las versiones de código fuente tarball en lugar de enviarse al repositorio público de git, para mantenerlas ocultas del escrutinio.
  • La operación tardó al menos dos años en realizarse. Fue entonces cuando el 'desarrollador' malicioso conocido como 'Jia Tan' se unió al proyecto de código abierto.
  • Parece que el grupo detrás de Jia Tan presionó deliberadamente al mantenedor original, Lasse Collin, para que incorporara a Tan. Probablemente personajes falsos, incluidos 'Jigar Kumar' y 'Dennis Ens', aumentaron la presión al bombardear a Lasse con solicitudes de funciones y quejas de errores.

El desafío de la seguridad del código abierto

La mala noticia es que se sabe que Jia Tan ha trabajado en varios otros proyectos de código abierto. No está claro si ya se ha insertado código malicioso de forma encubierta en estos y cuál podría ser el impacto.

El código abierto es tanto el problema como la solución aquí. Su enfoque de “muchos ojos” para el desarrollo de software debería, en teoría, significar que los problemas se detectan a tiempo. Pero como se ve con este ataque, los actores de amenazas están haciendo todo lo posible para introducir código malicioso en los proyectos sin ser visto.

El desafío para los equipos de seguridad y los desarrolladores que utilizan componentes de código abierto son las dependencias intransitivas que a menudo introducen involuntariamente en el código, como lo destaca el saga log4j. Obtener visibilidad de dicho riesgo es fundamental, según Jamie Scott, gerente de producto fundador de Endor Labs.

"Cuando confías en un paquete Maven, en promedio, hay 14 dependencias adicionales en las que confías implícitamente", le dice a ISMS.online. “Este número es aún mayor en ciertos ecosistemas de software como npm, donde, en promedio, se importan otros 77 componentes de software para todas las personas en las que confía. Esta relación de confianza se establece con todos los mantenedores de todos los componentes del software”.

Entonces, ¿cuál es la respuesta? En un nivel, es necesario que los gobiernos, las grandes empresas de software que utilizan código abierto y la propia comunidad de código abierto hagan más.

"La industria y la comunidad de código abierto necesitan trabajar más estrechamente para proteger el ecosistema más amplio de software de ciberseguridad", dice Chris Hodson, CSO de Cyberhaven, a ISMS.online. “La línea entre el software comercial y el de código abierto es opaca. A todos les conviene hacerlo mejor”.

Scott, de Endor Labs, añade que la industria podría ayudar adoptando la firma de artefactos.

"La firma de artefactos proporciona cierta resistencia a este tipo de ataque al garantizar que sólo los canales autorizados puedan producir artefactos firmados y válidos", argumenta.

"Si bien esto no proporcionará una protección perfecta, aumenta significativamente el costo para un adversario de lograr que se adopten paquetes maliciosos y también ayuda a una respuesta efectiva a incidentes al permitir que los respondedores bloqueen de manera rápida y precisa el uso del paquete malicioso una vez que se identifica".

Otras iniciativas industriales muy necesarias incluyen la adopción por defecto de metadatos de seguridad como listas de materiales de software (SBOM) y niveles de cadena de suministro para artefactos de software (SLSA), que pueden ayudar a los CISO a comprender mejor el riesgo en sus cadenas de suministro. También hay más financiación para organizaciones como OpenSSF, que a su vez financia importantes iniciativas de seguridad.

Próximos pasos para los equipos de seguridad

En última instancia, para los equipos de CISO y DevSecOps, la clave es ganar visibilidad de su código fuente abierto, especialmente de las dependencias intransitivas, según Hodson.

“Es importante que los CISO aprecien la cadena de confianza y las interdependencias de una biblioteca de software y un ejecutable. Xz Utils, de forma aislada, parece un componente de software de bastante bajo riesgo, pero los adversarios buscarán explotar dicho software para alcanzar su objetivo”, argumenta. “Los CISO necesitan comprender mucho mejor su cadena de suministro, no sólo los proveedores que utilizan para el software comercial, sino también los componentes de código abierto en sus aplicaciones y servicios. Por no hablar de los de sus terceros”.

Andrew Rose, CSO de SoSafe, comparte esta lista de tareas pendientes para gestionar el riesgo con ISMS.online:

  • Cree una biblioteca de software y recursos aprobados para garantizar barreras de seguridad claras para los desarrolladores y limitar el código y el software no aprobados. El software debe ser validado y aprobado, quizás por proveedores que hayan evaluado sus riesgos.
  • Cree lagos de datos falsos con fines de prueba e implemente la segmentación de la red. Esto significa que todos los entornos de desarrollo, o lugares con compilaciones no controladas, no deberían tener acceso a datos reales ni a sistemas y servicios de producción.
  • Utilice únicamente compilaciones aprobadas y publicadas en producción y revíselas periódicamente para garantizar que se supervise cualquier actividad sospechosa.
  • Los CISO deben permanecer conectados con las comunidades de desarrolladores para conocer las vulnerabilidades, las puertas traseras y los problemas que surjan.
  • Escanee los entornos con regularidad, incluso después de que los CISO hayan limpiado la casa. Se debe aplicar un modelo de "ganado, no mascotas" para gestionar servicios o software, lo que significa evaluar y reconstruir continuamente para garantizar que se estén utilizando las versiones aprobadas correctas.

 

Scott de Endor Labs agrega los siguientes consejos de defensa en profundidad para reducir la probabilidad de explotación en caso de que una cadena de suministro de software se vea comprometida:

  • Implementar privilegios mínimos: en el caso de xz Utils, habría sido útil un enfoque de privilegios mínimos para la configuración del servidor y el contenedor. Las claves SSH de puerta trasera le permiten acceder a SSH cuando los servicios SSH están accesibles. No exponga los puertos SSH a Internet.
  • Cree políticas de gobernanza para el uso de código abierto: pueden ir desde "Fijar todas las versiones de software de código abierto utilizadas para no descargar siempre la última versión" hasta "no utilizar versiones de software de código abierto con menos de 60 días de antigüedad".
  • Elimine el software no utilizado para reducir el riesgo en la cadena de suministro: el software no utilizado puede crear un exceso innecesario en su software e introducir riesgos en la cadena de suministro con el tiempo. Es solo cuestión de tiempo antes de que se descubra el próximo ataque de tipo xz Utils. Al tomar más precauciones ahora, las organizaciones pueden desarrollar resiliencia de manera proactiva y garantizar que su camino hacia la recuperación sea más rápido y menos traumático.