XZ Utils backdoor (CVE-2024-3094): anatomía del supply chain attack que casi compromete Linux

Esta semana se hizo público uno de los incidentes de seguridad más importantes de la última década. Andres Freund, ingeniero de Microsoft trabajando en PostgreSQL, detectó por casualidad un comportamiento anómalo en sus pruebas de rendimiento: ssh tardaba aproximadamente 500 ms más de lo esperado. Investigando esa lentitud, descubrió un backdoor sofisticado en XZ Utils, una librería de compresión usada en prácticamente todas las distribuciones de Linux.

El detalle escalofriante: el ataque no fue una intrusión externa. Fue un insider attack a largo plazo. La cuenta "Jia Tan" llevaba aproximadamente dos años ganando la confianza del mantenedor original de XZ Utils, contribuyendo código legítimo, hasta volverse co-mantenedor con permisos de commit. Solo entonces, en las versiones 5.6.0 (febrero) y 5.6.1 (marzo de 2024), insertó código malicioso dirigido contra sshd que habría dado acceso remoto silencioso a millones de servidores.

Si Freund no hubiera notado los 500 ms de lentitud y decidido investigar, este artículo no se estaría escribiendo. Aquí va la anatomía completa y las lecciones para empresas mexicanas, especialmente para quienes corren cargas críticas en Linux.

Qué es XZ Utils y por qué importa tanto

XZ Utils es una librería open source para compresión de archivos (algoritmo LZMA/LZMA2). Es una de esas piezas invisibles que sostienen todo:

• Viene preinstalada en prácticamente todas las distribuciones Linux (Debian, Ubuntu, Fedora, RHEL, Arch, openSUSE, Alpine).
• La usan herramientas críticas como dpkg, rpm, tar, kernel build tools.
• Y, relevante para este ataque: se enlaza en runtime con sshd a través de la dependencia con liblzma.

XZ Utils tenía hasta hace poco un solo mantenedor activo, Lasse Collin, que llevaba años pidiendo ayuda públicamente debido a problemas de salud y carga personal. Esa fue la grieta que el atacante explotó.

Cómo se construyó el ataque (cronología)

Lo que se ha podido reconstruir hasta ahora:

2021: aparece "Jia Tan"

La cuenta JiaT75 (Jia Tan) empieza a contribuir a varios proyectos open source con commits legítimos y útiles. Construye reputación de buen colaborador.

2022: presión social al mantenedor

En una thread de issues de XZ Utils, otras cuentas (que después se sospecha podrían haber sido coordinadas) presionan a Lasse Collin a aceptar más ayuda, criticando lentitud en respuestas. La presión es psicológica: aprovechar que el mantenedor está agotado y solo.

2023: Jia Tan se vuelve co-mantenedor

Tras meses de contribuciones útiles y ante la presión, Collin acepta a Jia Tan como co-mantenedor con permisos de commit y release.

Febrero de 2024: versión 5.6.0

Se publica XZ Utils 5.6.0 con cambios en el sistema de build (autogen) que incluyen archivos binarios disfrazados como casos de prueba. Esos binarios contenían el payload malicioso.

Marzo de 2024: versión 5.6.1

Se publica 5.6.1 con refinamientos al backdoor. Empieza a propagarse a versiones de pre-release de Debian, Fedora 40, openSUSE Tumbleweed, Kali Linux. Las versiones estables aún no estaban afectadas (Debian stable, Ubuntu LTS, RHEL).

29 de marzo de 2024: el descubrimiento

Andres Freund, investigando latencia de PostgreSQL en Debian sid, encuentra el backdoor. Lo reporta inmediatamente a la lista de seguridad de Debian y a la comunidad. Se publica CVE-2024-3094 con score CVSS de 10.0 (máximo).

Cómo funcionaba el backdoor

El detalle técnico es elegantemente diabólico:

1. Durante el build de XZ Utils, scripts en el tarball de release (no en el repositorio Git) modificaban el código generado.
2. El binario resultante de liblzma incluía código que, cuando se cargaba en sshd vía la cadena de dependencias sshd -> libsystemd -> liblzma, hookeaba la función de verificación de claves SSH.
3. Si un atacante con la llave privada correcta intentaba autenticarse, el backdoor permitía bypass total. Si no, se comportaba como sshd normal.
4. El ataque era silencioso (no dejaba logs visibles) y dirigido (solo el atacante con la llave podía explotarlo).

En resumen: cualquier servidor Linux corriendo sshd con liblzma 5.6.0 o 5.6.1 podría haber sido accesible remotamente al atacante con un esfuerzo de cero. Decenas de millones de servidores potencialmente expuestos.

Quién es Jia Tan

Aquí es donde el caso se vuelve geopolítico. La identidad real es desconocida, pero el análisis forense apunta a:

• Patrón de actividad consistente con zona horaria UTC+8 (China, posiblemente).
• Uso de VPN y técnicas de operations security sofisticadas durante años.
• Coordinación con otras cuentas que aparecieron y desaparecieron en el momento estratégico.
• Inversión de tiempo y planeación consistente con actor estatal o grupo APT.

La hipótesis dominante en círculos de seguridad: operación de inteligencia estatal con paciencia para construir trust durante años antes de ejecutar. No hay atribución oficial confirmada al cierre de marzo.

Por qué casi funciona

Tres factores que casi le permiten al ataque pasar desapercibido:

1. Economía del open source. Mucho software crítico depende de mantenedores voluntarios sin recursos. El sistema de incentivos premia contribuir, no auditar paranoicamente cada commit.
2. Tarballs de release vs Git. El payload estaba en el tarball publicado, no en el repositorio Git público. Quien revisaba el código en GitHub no veía nada raro.
3. Sofisticación del payload. El código malicioso estaba ofuscado, dividido en múltiples archivos, y solo se activaba en condiciones muy específicas.

Lecciones para empresas mexicanas

Para una empresa mediana con cargas en Linux, las acciones inmediatas y de mediano plazo:

Acciones inmediatas (esta semana)

1. Verifica versiones de XZ Utils en tu infraestructura. Comando: xz --version. Si tienes 5.6.0 o 5.6.1, downgrade a 5.4.x inmediatamente. Aplica a servidores, contenedores, imágenes base, runners de CI/CD.
2. Revisa imágenes Docker en tus registros. Cualquier imagen construida en marzo podría incluir versiones afectadas. Reconstruye con base actualizada.
3. Audita Debian sid, Fedora 40 (preview), openSUSE Tumbleweed, Kali en tu entorno. Las distribuciones estables (Debian 12, Ubuntu LTS, RHEL 8/9) no están afectadas, pero ambientes de desarrollo podrían sí.

Acciones de mediano plazo

Software Bill of Materials (SBOM)

Si no tienes SBOM (Software Bill of Materials) de cada aplicación en producción, este es el momento. Herramientas como syft, trivy, grype permiten generar SBOM automáticamente. Saber exactamente qué dependencia usas, qué versión, en cada servicio, es la base para responder a un CVE en horas en lugar de días.

Monitoreo de upstream dependencies

El supply chain de open source es un vector de ataque ya validado (XZ es 2024, log4shell fue 2021, event-stream fue 2018, SolarWinds fue 2020). Procesos a implementar:

• Renovate o Dependabot activado en todos los repositorios.
• Política de revisión antes de actualizar dependencias críticas.
• Suscripción a feeds de CVE y monitoreo activo.
• Plan de respuesta ante CVE crítico: quién, cómo, en cuántas horas.

Soporte económico al open source crítico

Una lección incómoda de XZ: el sistema descansa en mantenedores agotados. Empresas que dependen de software crítico open source deberían considerar contribuir económicamente (sponsorships en GitHub, fundaciones como Linux Foundation o OpenSSF, contratos con proveedores enterprise como Red Hat). No es solo ética; es seguridad.

Hardening de servidores Linux

Independiente de XZ, vale la pena revisar:

• ¿Tu sshd está configurado con keys (no passwords)?
• ¿Acceso ssh limitado por IP / VPN / bastion?
• ¿Logs de auth a SIEM con alertas?
• ¿Detección de comportamiento anómalo (procesos inusuales, tráfico saliente raro)?

Si el backdoor de XZ hubiera tenido un mes más de runway, quien hubiera tenido detección de anomalías en sshd habría notado actividad sospechosa antes de comprometerse.

Lo que vale la pena no perder de vista

Tres lecciones de fondo más allá de XZ:

• Trust no es transitivo. Que confíes en un proyecto no significa que automáticamente debas confiar en todos sus mantenedores actuales o futuros.
• El ataque vino de "dentro" del ecosistema, no de "fuera". El perímetro tradicional no aplica para supply chain attacks. La defensa requiere monitoring de comportamiento, no solo de borde.
• Detección casual es síntoma de problema sistémico. Que el descubrimiento haya sido por accidente (un benchmark de Postgres) muestra que no había proceso institucional de auditoría capaz de detectarlo. Eso tiene que cambiar.

La lectura larga

XZ Utils es la peor pesadilla del modelo open source que casi se materializa: un actor sofisticado dispuesto a invertir años para insertar una puerta trasera en software de confianza global. La buena noticia es que se detectó antes de propagación masiva. La mala es que esto ya pasó al menos una vez, y por estadística, es probable que esté pasando ahora con otras dependencias que aún no descubrimos.

Para empresas mexicanas, la lección operativa es clara: el supply chain es un vector de ataque legítimo y persistente. Las que tengan SBOM, monitoring activo y procesos de respuesta a CVE bien definidos van a poder reaccionar en horas. Las que no, van a estar en lista de afectados sin saberlo cuando pase el siguiente.

---

¿Tu pipeline tiene controles para supply chain attacks? Hagamos un assessment. En ALCA ayudamos a implementar SBOM, monitoring de dependencias y procesos de respuesta. Agenda 30 minutos sin costo.