La puerta trasera de XZ CVE-2024-3094

El 29 de marzo de 2024, un actor malicioso llevó a cabo una campaña prolongada y con una gran inversión para instalar una puerta trasera en la biblioteca de software de Linux liblzma y obtener acceso a varios sistemas operativos mediante distribuciones de Linux. Podría decirse que tuvo éxito, hasta que un ingeniero observador notó una anomalía.

Software upstream afectado conocido hasta la fecha y medidas de mitigación propuestas:

¿Qué es XZ?

XZ, también conocido como XZ Utils, ofrece una interfaz de línea de comandos para comprimir y descomprimir archivos. Suele venir incluido en distribuciones de Linux como Debian, Ubuntu y muchas otras.

// Example usage of XZ for context:
$ xz llm_rag_context.json

// Results in a new compressed file on disk:
$ ls -al llm_tag_context.json.xz
.rw-r--r--   81k lirantal 31 Mar 10:29   -N  llm_tag_context.json.xz

¿Qué es Liblzma?

Liblzma es la biblioteca de software que implementa el algoritmo de compresión y descompresión LZMA y ofrece enlaces para que otros lenguajes de programación puedan integrarse con ella, como el programa CLI xz.

¿Qué es CVE-2024-3094?

El identificador de vulnerabilidad CVE-2024-3094 se publicó el 29 de marzo de 2024 para reflejar la puntuación de gravedad crítica de 10.0 asignada al paquete liblzma.

El informe de CVE atribuye el riesgo de seguridad a código malicioso descubierto en la biblioteca de software liblzma. Este código permitía modificar datos al interactuar con la biblioteca, lo que comprometía su integridad y podía tener consecuencias más graves.

¿Qué impacto tiene la puerta trasera de XZ?

El protocolo SSH y las herramientas que lo acompañan en Linux permiten el acceso remoto entre hosts. Como la puerta trasera de XZ permite interceptar y modificar datos, y algunas distribuciones de Linux ponen liblzma a disposición del programa SSH, podemos suponer inicialmente que uno de los impactos de CVE-2024-3094 podría ser la omisión de la autenticación en el programa sshd.

En términos simples, una persona que tenga una clave RSA podría autenticarse de forma remota en cualquier servidor SSH abierto y con la puerta trasera.

Ahora se especula que la puerta trasera de XZ podría permitir la ejecución remota de código. Sin embargo, hay una investigación en curso para analizar el código de la puerta trasera insertado en liblzma y rastrear todas las contribuciones realizadas y vinculadas con el actor malicioso involucrado.

Cronología para ponerlo en contexto:

• El archivo de compilación malicioso se agregó a Debian xz-utils el 24 de febrero de 2024.

• La versión 5.6.0 del archivo tar de xz-utils se publicó el 24 de febrero, y la versión 5.6.1, el 9 de marzo de 2024.

• La versión 5.6.0 se agregó a Fedora el 27 de febrero de 2024.

La historia de la puerta trasera de XZ

El 29 de marzo de 2024 se reportó una importante brecha de seguridad. Andres Freund, colaborador de la lista de correo oss-security de Openwall, reveló que la biblioteca liblzma, parte del paquete XZ utils de uso extendido, podría estar comprometida.

Freund hizo este descubrimiento después de notar un uso inusualmente alto de CPU por parte del proceso sshd, lo que motivó una investigación más profunda.

El problema se origina en archivos de prueba comprimidos y manipulados de forma maliciosa que se incluyeron en las versiones 5.6.0 y 5.6.1 de liblzma. El objetivo era establecer una puerta trasera mediante cambios en el script configure de los archivos tar. Aunque el exploit permanece inactivo en condiciones normales, se activa en sistemas que usan un parche específico para el servidor SSH, lo que permite eludir la autenticación de sshd y obtener acceso remoto no autorizado al sistema.

La siguiente captura de pantalla se tomó del análisis del malware XZ de Andres, enviado a la lista de correo OSS-Security de Openwall:

Este sofisticado exploit aprovecha el mecanismo IFUNC de la biblioteca GNU C, conocida como glibc, para agregar un resolver para el método crc64_resolve que instala un hook de auditoría y sustituye la función RSA_public_decrypt de OpenSSH por una versión comprometida. Por lo general, OpenSSH no necesita liblzma. Sin embargo, el exploit aprovecha una situación de carga en cadena en la que un parche de terceros hace que se cargue libsystemd, que luego carga la biblioteca de software afectada liblzma. Al momento de escribir esto, la puerta trasera solo afecta a sshd en algunas distribuciones de Linux que aplican este parche para habilitar las notificaciones de systemd.

Un aspecto particularmente astuto de este ataque fue la introducción de un archivo build-to-host.m4 modificado en la versión tar alojada en GitHub. El archivo no estaba en el repositorio Git, por lo que no se podía rastrear su origen en el control de código fuente.

Este archivo de compilación M4 extrae e inyecta el código malicioso durante el proceso de compilación en sistemas específicos: plataformas x86-64 Linux que usan glibc y GCC, y compilan con dpkg o rpm, herramientas populares para compilar paquetes en las distribuciones Debian y Red Hat Linux.

Tras la brecha, GitHub archivó el repositorio que alojaba XZ utils por infringir los términos del servicio. La investigación sobre el origen de la puerta trasera apunta a Jia Tan, responsable del proyecto xz, aunque aún no está claro si el acto fue intencional o si alguien comprometió la cuenta de esa persona. Todavía falta determinar la identidad real detrás de esta cuenta de responsable.

Este ataque a la cadena de suministro afectó a varias distribuciones de Linux, entre ellas Debian 13 y unstable, Fedora Rawhide, Fedora 40, Kali Linux y OpenSUSE Tumbleweed. Arch Linux instó a sus usuarios a actualizar cuanto antes. La mayoría de las distribuciones que siguen un protocolo de actualizaciones estables no se vieron afectadas, ya que usaban versiones anteriores de XZ que no estaban comprometidas. FreeBSD tampoco se vio afectado, gracias a que incluía versiones de XZ anteriores al incidente y a que el ataque estaba dirigido a glibc de Linux. Por otro lado, si automatizaste la implementación de imágenes de contenedor con las actualizaciones más recientes disponibles de Fedora o Debian, estarías distribuyendo el programa XZ vulnerable.

Registrado como CVE-2024-3094 y con una puntuación CVSS de 10, la máxima posible, este incidente subraya la importancia crítica de proteger la cadena de suministro y las complejidades de confiar en las contribuciones de código abierto y verificarlas.

Reparar el daño: la operación de limpieza de XZ

Cuando se dio a conocer la historia, Lasse Collin, responsable original de la biblioteca XZ Utils, se apresuró a confirmar una corrección del código fuente en la configuración de compilación de la biblioteca. Esta diferencia de código muestra el trabajo ingenioso y elaborado que hizo el actor malicioso para llevar a cabo su campaña de puerta trasera. El carácter de punto (.) provocaba un error en la herramienta de compilación, lo que hacía que esta desactivara un entorno aislado de seguridad y eludiera los controles de seguridad.

Detecta la vulnerabilidad de XZ con Snyk

Hay varias formas de detectar la vulnerabilidad de XZ gratis con Snyk. Puedes probar tus proyectos de forma local con Snyk CLI:

• Para las aplicaciones, ejecuta snyk test --unmanaged desde Snyk CLI para comparar las dependencias no administradas de tu repositorio y detectar paquetes individuales y sus vulnerabilidades.

• Para los contenedores, ejecuta snyk container test para detectar paquetes de sistemas operativos compatibles que dependan de versiones vulnerables de XZ.

También puedes analizar todos tus proyectos en tus repositorios de Git para obtener un informe de todas las dependencias directas y transitivas que usas. 

En este informe, podrás ver si usas XZ y en cuántas rutas de tu grafo de dependencias aparece. También puedes buscar rápidamente "CVE-2024-3094" en todos tus proyectos. 

El cruce entre la seguridad de la cadena de suministro y el código abierto

La puerta trasera de XZ repercutió en las comunidades de código abierto y ciberseguridad, y desató debates y preocupación por la integridad del software de código abierto y los constantes riesgos de los ataques a la cadena de suministro. Este incidente es un claro recordatorio de la brecha de SolarWinds y de los diversos paquetes maliciosos detectados en registros de software como npm y PyPI, y pone de relieve un patrón de vulnerabilidades en la cadena de suministro con graves consecuencias para la ciberseguridad global.

Jia Tan, quien apareció con el nombre de usuario JiaT75 en GitHub, y personajes asociados como Jigar Kumar y Dennis Ens, han dejado en evidencia una sofisticada campaña de varios años para insertar código malicioso en XZ Utils, una herramienta de software esencial que se usa en numerosas distribuciones de Linux. La estrategia comenzó con contribuciones que parecían inofensivas y escaló hasta presionar directamente a los responsables del proyecto para obtener acceso de confirmación de cambios. Se valió de tácticas ingeniosas y de técnicas de ingeniería tanto técnica como social para explotar la confianza y la colaboración propias de la comunidad de código abierto.

Los antecedentes de la participación de Jia Tan en XZ Utils, que comenzó con actividad sospechosa en otros proyectos como libarchive, pintan un panorama complejo de acciones premeditadas que culminaron con el descubrimiento de CVE-2024-3094. Estas acciones, entre ellas la creación de infraestructura de pruebas y los intentos deliberados de ocultar la intención maliciosa mediante el uso indebido de implementaciones de ifunc, demuestran un nivel inquietante de previsión y manipulación.

Este incidente plantea preguntas cruciales sobre la sostenibilidad de la confianza y la seguridad en el software de código abierto. La propia naturaleza del código abierto —su transparencia y su dependencia de las contribuciones de la comunidad— se convierte en su talón de Aquiles cuando actores maliciosos se infiltran con intención de causar daño. El incidente también pone de relieve el estrés considerable y los desafíos de salud mental que enfrentan quienes mantienen estos proyectos y que, a menudo, ofrecen su tiempo y experiencia de forma voluntaria y bajo una presión inmensa para mantenerlos seguros y actualizados.

No se pueden ignorar las similitudes con incidentes anteriores, como la extensa brecha de SolarWinds o el flujo constante de paquetes contaminados en repositorios públicos de software. Todos comparten un factor: la explotación de la confianza y la complejidad de las cadenas de suministro de software modernas. Son un contundente recordatorio de la sofisticación de los adversarios cibernéticos y de las vulnerabilidades de las infraestructuras digitales de las que dependemos cada vez más.

A la luz de CVE-2024-3094 y de los precedentes históricos, la comunidad de código abierto y el sector tecnológico en general deben reevaluar y reforzar las prácticas de seguridad relacionadas con el desarrollo y la distribución de software. Esto incluye revisar las contribuciones con más rigor, implementar procesos de verificación más sólidos para quienes mantienen los proyectos y promover una mayor colaboración en torno a las mejores prácticas de seguridad. Además, es urgente desarrollar modelos de financiamiento sostenibles para los proyectos de código abierto y garantizar que quienes los mantienen cuenten con los recursos y las herramientas necesarios para proteger el software de forma eficaz.

Mientras enfrentamos las consecuencias de este incidente y otros similares, debemos mantener conversaciones abiertas y críticas sobre el equilibrio entre los valores del código abierto y la necesidad de seguridad. La resiliencia del software de código abierto y del ecosistema digital en general depende de nuestra capacidad colectiva para adaptarnos y reforzar nuestras defensas contra quienes buscan socavarlo.

¿Quién es Jia Tan? ¿Se trata de una persona o de un actor patrocinado por un Estado-nación? ¿Qué otros proyectos pudo haber comprometido y manipulado? Investigadores de seguridad y desarrolladores están rastreando activamente las huellas de la actividad de Jia Tan en Git, su origen, zona horaria y cualquier otra información que puedan recopilar para reconstruir lo sucedido.

Cómo pueden ayudar las SBOM a mitigar CVE-2024-3094

• Las listas de materiales de software permiten conocer los componentes y las versiones del software, incluidas las dependencias transitivas.

• Las SBOM ayudan a seguir el avance de las tareas de corrección para garantizar que se solucionen todos los proyectos afectados.

• Una vez actualizadas, las SBOM se pueden usar para demostrar que se aplicaron correctamente los parches o las correcciones necesarias.

¿Qué hacer ahora?

• Sigue las recomendaciones de este informe de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) sobre las actualizaciones para CVE-2024-3094.

• Prueba tu SBOM con SBOM Checker de Snyk.

• Lee esta actualización de Dark Reading