XZ Utils Backdoor: El Ataque de 2 Años que Casi Rompe Internet (CVE-2024-3094)

“500 milisegundos. Eso fue lo que salvó Internet. Un retraso apenas perceptible en un login SSH que un ingeniero decidió investigar.”

📖 Índice

1. ¿Por qué existe este ataque?
2. ¿Qué es XZ Utils y por qué importa?
3. La Historia: El Infiltrado que se Ganó la Confianza
4. La Cadena de Ataque Paso a Paso
5. Análisis Técnico Detallado: El Mecanismo IFUNC
6. Cómo Replicarlo en un Entorno Controlado
7. Cómo Detectar y Protegerse
8. Lecciones Aprendidas
9. Conclusión
10. Referencias

🎯 ¿Por qué existe este ataque?

El 29 de marzo de 2024, Andres Freund, ingeniero de Microsoft y desarrollador de PostgreSQL, publicó un mensaje en la lista de correo de seguridad de Openwall con un asunto que helaba la sangre: “backdoor in upstream xz/liblzma leading to ssh server compromise”.

Lo que había descubierto era el ataque a la cadena de suministro más sofisticado jamás documentado contra el ecosistema open source.

El descubrimiento fue totalmente accidental. Freund estaba realizando pruebas de rendimiento de PostgreSQL en su sistema Debian Sid (la rama inestable de Debian) cuando notó algo anómalo: las conexiones SSH eran inexplicablemente lentas. En lugar de los 100 milisegundos habituales, tardaban cerca de 500 milisegundos y consumían una cantidad desproporcionada de CPU.

”No era un problema de red. No era un problema de disco. Era algo dentro de liblzma, la librería de compresión proporcionada por XZ Utils.”

Ese medio segundo adicional llevó a Freund a investigar a fondo con herramientas de diagnóstico como valgrind y perf, desenmarañando una trama de infiltración silenciosa. La vulnerabilidad recibió el identificador CVE-2024-3094 y la puntuación máxima en la escala: CVSS 10.0.

🧩 ¿Qué es XZ Utils y por qué importa?

Para Todos los Públicos

Imagina que el sistema operativo de tu servidor es una gran metrópoli. Cada programa necesita transferir grandes volúmenes de datos optimizando el espacio. Para que esa comunicación sea eficiente, usan un servicio de compresión que empaqueta y desempaqueta información al vuelo. Ese servicio es XZ Utils (y su núcleo, liblzma).

XZ Utils es como el servicio postal fundamental de Linux. Está instalado en prácticamente todos los servidores del mundo. Se utiliza a diario para:

• Comprimir paquetes de software (.deb, .rpm, .tar.xz).
• Comprimir logs del sistema y volcados de depuración.
• Copias de seguridad de bases de datos.
• Archivos del núcleo e imágenes initramfs.

La Cadena de Dependencias que lo Hizo Posible

El backdoor no atacó a OpenSSH directamente; explotó una cadena de dependencias indirecta introducida por algunas distribuciones:

OpenSSH (sshd)
     ↓
libsystemd (añadido en parches de distros para notificaciones de servicio)
     ↓
liblzma (compresión de XZ Utils)

Esta cadena no existe en el código original (upstream) de OpenSSH. Es un parche que distribuciones como Debian, Ubuntu y Fedora añadían para integrar el demonio sshd con el sistema de inicio systemd.

• Distribuciones afectadas en pruebas: Debian Sid/Testing, Fedora Rawhide y Fedora 41, openSUSE Tumbleweed/MicroOS, Kali Linux y Arch Linux.
• Por qué no fue una catástrofe global: Las versiones comprometidas (5.6.0 y 5.6.1) aún no habían aterrizado en las ramas estables de producción (Debian Stable, Ubuntu LTS, RHEL o SUSE Enterprise). Se detectó a tiempo por puro timing de lanzamiento.

🕵️ La Historia: El Infiltrado que se Ganó la Confianza

El backdoor de XZ Utils no fue un simple despiste de programación. Fue una operación encubierta de ingeniería social planificada durante casi tres años.

El Personaje: Jia Tan

La identidad Jia Tan (usuario JiaT75 en GitHub) apareció en la escena open source a finales de 2021. Durante más de dos años, esta cuenta siguió una estrategia de infiltración metódica:

1. Contribución con parches legítimos: Resolvió bugs reales, optimizó algoritmos y se comportó como un colaborador modelo para ganarse la simpatía de la comunidad.
2. El relevo del mantenedor: Lasse Collin, creador y único mantenedor de XZ Utils, gestionaba el proyecto de forma voluntaria sin remuneración y sufría problemas de agotamiento laboral (burnout).
3. Campaña coordinada de presión: Aparecieron cuentas fantasma en las listas de correo (nombres como “Jigar Kumar” o “Dennis Ens”) presionando a Lasse Collin para que delegara el mantenimiento:

   “Los parches se están pudriendo, el proyecto se muere… hace falta un nuevo mantenedor ya.”

4. Acceso total: Para 2023, Jia Tan se convirtió en co-mantenedor oficial, obtuvo permisos de commit directo y fue designado contacto de seguridad en OSS-Fuzz de Google.

La Línea de Tiempo del Ataque

⛓️ La Cadena de Ataque Paso a Paso

El diseño técnico del backdoor fue tan meticuloso como su ingeniería social:

Fase 1: El Código Fantasma fuera de Git

Si alguien revisaba el repositorio de GitHub de XZ Utils, no encontraba ni una sola línea de código malicioso.

El payload se inyectaba exclusivamente en los tarballs oficiales de release (.tar.gz o .tar.bz2), que son los archivos que los empaquetadores de Linux descargan y verifican con sumas SHA para compilar los paquetes de las distribuciones.

Fase 2: Los Archivos de Prueba Camuflados

El código binario malicioso estaba oculto dentro de dos archivos en el directorio de pruebas:

• tests/files/bad-3-corrupt_lzma2.xz
• tests/files/good-large_compressed.lzma

A simple vista parecían archivos corruptos estándar usados para comprobar que el descompresor gestionaba errores sin caerse. En realidad, contenían bloques binarios ensamblados y cifrados.

Fase 3: La Inyección en Tiempo de Compilación

Durante la ejecución del script ./configure en el tarball, un script modificado (m4/build-to-host.m4):

1. Extraía bytes concretos de esos archivos de prueba.
2. Los desofuscaba utilizando secuencias de comandos Unix (tr, sed, head, cut).
3. Ensamblaba un archivo objeto binario que se enlazaba silenciosamente durante la compilación de liblzma.so.
4. El mecanismo incluía comprobaciones de entorno: solo se activaba si se compilaba en arquitecturas x86-64 con glibc bajo Linux, y dentro del contexto de empaquetado de paquetes .deb o .rpm.

⚙️ Análisis Técnico Detallado: El Mecanismo IFUNC

Una vez que la librería infectada liblzma.so.5 era cargada por sshd, ¿cómo tomaba el control sin levantar sospechas? La respuesta está en GNU IFUNC (Indirect Functions).

¿Qué es un IFUNC Resolver?

En sistemas Linux con glibc, un IFUNC es un mecanismo del enlazador dinámico que permite elegir la versión más optimizada de una función en tiempo de ejecución (por ejemplo, seleccionar una versión acelerada por AVX2 o AVX-512 si el procesador lo soporta).

El atacante utilizó este punto de enganche porque los resolvers IFUNC se ejecutan muy temprano, antes de que se completen las protecciones de reubicación de memoria en solo lectura (relro).

[ Inicio de sshd ]
        ↓
[ Carga dinámica de libsystemd ]
        ↓
[ Carga dinámica de liblzma ]
        ↓
[ Ejecución de IFUNC Resolver malicioso ]
        ↓
[ Modificación de tabla GOT (Global Offset Table) ]
        ↓
[ Hook sobre RSA_public_decrypt() de OpenSSL ]

El Secuestro de RSA_public_decrypt

1. Hook: El IFUNC resolver sobrescribe el puntero a la función criptográfica RSA_public_decrypt de OpenSSL.
2. Intercepción: Cuando un cliente SSH intenta iniciar sesión mediante clave pública, sshd llama a RSA_public_decrypt para verificar el certificado.
3. Verificación de la firma del atacante: La función troyanizada analiza la clave pública entrante. Si contiene una carga útil cifrada y firmada específicamente con la clave privada ED448 del atacante, la función la procesa.
4. Ejecución Remota de Comandos (RCE): Si la firma es válida, extrae el comando y lo pasa directamente a system(), ejecutándolo con los privilegios máximos de root antes de que el proceso de autenticación de OpenSSH siquiera finalice.
5. Paso transparente: Si el usuario es legítimo, la función pasa la solicitud al RSA_public_decrypt original, evitando caídas o alertas en los registros.

🧪 Cómo Replicarlo en un Entorno Controlado

⚠️ ADVERTENCIA LEGAL Y ÉTICA: La experimentación con vulnerabilidades debe realizarse exclusivamente en máquinas virtuales o contenedores sin acceso a redes productivas.

1. Demostración Educativa del Hooking con IFUNC

Para comprender cómo un resolver IFUNC puede desviar el flujo de un programa de manera legítima para el enlazador, podemos analizar este ejemplo básico en C:

// ifunc_demo.c - Demostración didáctica de resolución indirecta
// Compilar con: gcc -shared -fPIC -o libdemo.so ifunc_demo.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Función legítima estándar
void original_function(const char *input) {
    printf("[ORIGINAL] Procesando petición normal: %s\n", input);
}

// Función interceptora que implementa la lógica condicional
void hooked_function(const char *input) {
    if (strstr(input, "SECRET_TRIGGER_KEY") != NULL) {
        printf("[HOOK] Payload autenticado por atacante. Ejecución arbitraria:\n");
        system("whoami");
    } else {
        original_function(input);
    }
}

// Resolver IFUNC: se ejecuta durante la carga dinámica
void *resolve_function(void) {
    // El atacante devolvía el puntero a la función hookeada
    return hooked_function;
}

// Declaración del atributo ifunc vinculado al resolver
void process_request(const char *input) __attribute__((ifunc("resolve_function")));

2. Programa de prueba consumidor

// test_app.c
// Compilar con: gcc -o test_app test_app.c -L. -ldemo

#include <stdio.h>

extern void process_request(const char *input);

int main(void) {
    printf("--- Caso 1: Solicitud habitual ---\n");
    process_request("sesion_usuario_normal");

    printf("\n--- Caso 2: Solicitud con token de activación ---\n");
    process_request("peticion_con_SECRET_TRIGGER_KEY_123");

    return 0;
}

Al ejecutar con LD_LIBRARY_PATH=. ./test_app, se aprecia cómo la función es interceptada de forma invisible para el ejecutable principal.

🛡️ Cómo Detectar y Protegerse

1. Comprobar la versión instalada de XZ Utils

Ejecuta en tu terminal Linux:

xz --version

O en distribuciones Debian / Ubuntu:

dpkg -l | grep -E "xz-utils|liblzma"

En distribuciones Red Hat / Fedora:

rpm -qa | grep -E "xz|liblzma"

• Versiones vulnerables: 5.6.0 y 5.6.1.
• Versiones seguras: 5.4.x (como 5.4.6) o versiones parcheadas 5.6.1+ y posteriores distribuidas por los repositorios oficiales.

2. Escaneo automatizado de firmas

Puedes utilizar el script de detección de la comunidad para verificar las librerías cargadas en memoria:

git clone https://github.com/Juul/xz-backdoor-scan
cd xz-backdoor-scan
chmod +x xz-backdoor-scan.sh
./xz-backdoor-scan.sh

📚 Lecciones Aprendidas

1. La ingeniería social es el vector de ataque más potente: No atacaron la criptografía de SSH; agotaron psicológicamente a un voluntario solitario durante años para heredar las llaves del repositorio.
2. El peligro de los proyectos con Bus Factor = 1: Gran parte de la infraestructura crítica de Internet sigue dependiendo de pequeñas librerías mantenidas por una o dos personas en su tiempo libre sin apoyo institucional.
3. El código en Git no garantiza el artefacto final: Auditar repositorios es insuficiente si los procesos de compilación y empaquetado (release pipelines) no son 100% reproducibles e inmutables.
4. La importancia de monitorizar anomalías mínimas: Si Andres Freund no se hubiera molestado por medio segundo de latencia, este backdoor estaría hoy instalado en millones de servidores en producción.

🎯 Conclusión

El caso de XZ Utils pasará a la historia de la ciberseguridad como el ataque más cercano a comprometer la columna vertebral de Linux a escala global. Demuestra que la seguridad no es solo cuestión de escribir código libre de desbordamientos de búfer, sino de proteger y auditar a las personas y procesos detrás de la cadena de suministro.

📚 Referencias

• CVE-2024-3094 - National Vulnerability Database (NVD)
• Alerta original de Andres Freund en Openwall
• Análisis y autopsia técnica del backdoor de XZ - Safeguard.sh
• Repositorio de detección comunitaria: Juul/xz-backdoor-scan
• Entorno de análisis y reproducción CVE-2024-3094 en GitHub