El primer secuestro del internet: Un voluntario casi derriba Linux

Quinientos milliseconds.

Medio segundo.

El margen por el que internet no fue secuestrado.

Marzo de 2024. San Francisco.

Un ingeniero de Microsoft de treinta y ocho años llamado Andres Freund está evaluando el rendimiento de PostgreSQL en un sistema de desarrollo Debian. Es una tarea rutinaria. Freund es un committer del proyecto PostgreSQL. Prueba el rendimiento de las bases de datos en distribuciones Linux de pre-lanzamiento como parte habitual de su trabajo.

Algo anda mal en el entorno de prueba.

Los intentos fallidos de inicio de sesión SSH —los que golpean constantemente a todos los servidores públicos, bots automatizados que prueban combinaciones aleatorias de nombres de usuario y contraseñas— están utilizando mucha más CPU de la que deberían. Un inicio de sesión fallido debería terminar rápidamente. Estos no están terminando rápidamente.

Freund lo nota.

Investiga más a fondo. Los inicios de sesión SSH exitosos, en su propia máquina local, están tardando quinientos milliseconds más que el tiempo base de aproximadamente cien milliseconds.

Medio segundo.

Freund ejecuta la conexión bajo Valgrind, una herramienta de depuración de memoria. Valgrind arroja errores que apuntan a liblzma —una biblioteca de compresión que el demonio SSH no tiene ninguna razón legítima para invocar.

Es entonces cuando la investigación se vuelve urgente.

Durante los siguientes días, Freund rastrea los errores. Descubre que el proceso sshd en su máquina de prueba está ejecutando código de liblzma durante la autenticación. Disecciona el código fuente de xz-utils en el repositorio git. El código fuente está limpio. Pero el tarball de la versión —el archivo fuente comprimido que Debian realmente descarga y desde el que compila— contiene un archivo llamado build-to-host.m4 que no está en el código fuente de git.

Ese archivo contiene un script ofuscado. El script decodifica un script bash oculto dentro de un archivo de prueba llamado bad-3-corrupt_lzma2.xz —un archivo disfrazado como una entrada de prueba dañada para el manejo de errores de la biblioteca de compresión. El script bash decodifica un segundo archivo, good-large_compressed.lzma, utilizando ofuscación personalizada combinada con descifrado RC4.

Lo que sale al final de la cadena es un objeto compartido compilado.

El objeto compartido es una puerta trasera.

En la tarde del veintinueve de marzo de 2024 —mientras, según su propio relato, escuchaba un podcast de seguridad durante una pausa para cocinar— Andres Freund publica sus hallazgos en la lista de correo oss-security en Openwall.

En 24 horas, Red Hat le asignó un número CVE. La puntuación de gravedad es de diez punto cero. La más alta posible. CISA emite una advertencia de emergencia. Debian, SUSE, Fedora, Arch y Kali revierten los paquetes afectados. GitHub suspende la cuenta del mantenedor que comprometió la puerta trasera.

La puerta trasera, resulta, estaba programada para enviarse con distribuciones Linux estables en aproximadamente dos semanas.

Freund la descubrió por accidente.

Este es el expediente del caso sobre lo que pasó. Sobre lo que casi pasó. Y sobre la operación en sí.

El objetivo del ataque era xz-utils.

xz-utils es un conjunto de herramientas de compresión. Su herramienta principal, el comando xz, produce archivos .xz —el equivalente Unix de los archivos .zip, con mayores índices de compresión. Debajo de la herramienta de línea de comandos hay una biblioteca llamada liblzma, que proporciona el algoritmo de compresión a otros programas que lo necesitan.

liblzma es cargada, directa o indirectamente, por una enorme cantidad de software de sistema Linux. Los gestores de paquetes se enlazan con ella. Las utilidades del sistema se enlazan con ella. Y —a través de una cadena que los atacantes diseñaron específicamente— el demonio OpenSSH se enlaza con ella.

La cadena funciona así. En la mayoría de las principales distribuciones Linux, sshd está parcheado para soportar el mecanismo de notificación de servicios de systemd, llamado sd_notify. Ese parche hace que sshd cargue una biblioteca llamada libsystemd. Y libsystemd, a su vez, carga liblzma.

El resultado: en la mayoría de los servidores Linux de producción, el demonio SSH —el proceso que acepta inicios de sesión remotos— carga una biblioteca de compresión al inicio, aunque SSH no comprima el tráfico de autenticación.

Si se compromete la biblioteca de compresión, se compromete el demonio que controla el acceso remoto a cada servidor Linux en internet.

En el momento del casi despliegue de la puerta trasera, Linux ejecutaba aproximadamente el noventa y seis por ciento del millón de servidores web más importantes del mundo. Los quinientos superordenadores más potentes del mundo. Aproximadamente el noventa y dos por ciento de las máquinas virtuales en Amazon Web Services, Google Cloud y Microsoft Azure. Android, que impulsa alrededor del ochenta y cinco por ciento de los smartphones del mundo, está construido sobre el kernel Linux.

La puerta trasera de xz-utils, de haberse enviado a distribuciones estables, habría estado presente en una fracción sustancial de todo lo anterior.

Alex Stamos, el exdirector de seguridad en Facebook, describió el resultado previsto en una frase: una clave maestra para cualquier servidor SSH en la Tierra.

Esta es la razón por la que la CVE obtuvo una puntuación de diez punto cero.

El diseño técnico de la puerta trasera merece ser entendido con precisión.

El atacante explotó el hecho de que los tarballs de las versiones contienen archivos autogenerados que no existen en el código fuente de git con control de versiones. Específicamente, el archivo build-to-host.m4 en el tarball contenía una sola línea que había sido modificada para inyectar un script ofuscado en el paso de configuración del proceso de compilación.

Esto significaba que cualquiera que leyera el código fuente de git no podía ver la puerta trasera. Cualquiera que compilara desde git no podía activarla. Solo las distribuciones Linux, que compilan desde los tarballs publicados —que son efectivamente todas ellas— ejecutarían la inyección.

La cadena de inyección tenía tres etapas. La primera etapa extraía un script bash de un archivo disfrazado como una entrada de prueba de compresión corrupta. La segunda etapa usaba ese script bash para decodificar un segundo archivo de prueba en un objeto compartido compilado. La tercera etapa enlazaba el objeto compartido al binario compilado de liblzma.

El objeto compartido utilizaba una característica legítima de glibc llamada IFUNC —resolvedores de funciones indirectas— para secuestrar una función específica de OpenSSH llamada RSA_public_decrypt.

RSA_public_decrypt es la función de OpenSSH que valida firmas RSA durante la autenticación de certificados. Cada vez que un cliente intenta conectarse utilizando un certificado RSA, sshd llama a esta función para verificar la firma.

Con la puerta trasera activa, sshd llamaba al código del atacante en su lugar.

El código del atacante inspeccionaba el módulo público RSA —el valor entero grande pasado en el certificado del cliente. Normalmente, este valor se utiliza en la verificación RSA estándar. En la puerta trasera, era en realidad un contenedor de carga útil. El código descifraba la carga útil utilizando una clave simétrica ChaCha20 codificada. Luego verificaba la firma de la carga útil descifrada utilizando una clave pública Ed448 codificada.

Si la firma se verificaba —lo que significaba que la carga útil estaba firmada por la clave privada del atacante— el código ejecutaba los comandos de shell incrustados como root.

Esto es lo que los investigadores de seguridad llaman ejecución remota de código con puerta. La puerta trasera se activa solo cuando el atacante presenta una firma criptográfica válida. Un atacante común que tropezara con la puerta trasera no podría explotarla. Solo el poseedor de la clave privada Ed448 podría activarla.

Este detalle importa. Un actor criminal que crea una vulnerabilidad para venderla la hace utilizable por quien la compra. Un actor estatal que crea una capacidad de acceso persistente la hace exclusiva. Solo ellos, y cualquiera que autoricen explícitamente, pueden usar la clave.

La puerta trasera de xz-utils fue diseñada para uso exclusivo. No era una vulnerabilidad. Era un activo estratégico.

La operación que produjo la puerta trasera comenzó el veintiséis de enero de 2021.

En esa fecha, se creó una cuenta de GitHub bajo el nombre de usuario JiaT75. El nombre de visualización era Jia Tan. La cuenta no tenía huella digital previa. Sin presencia en redes sociales bajo ese nombre. Sin charlas en conferencias. Sin contribuciones anteriores de código abierto. Sin apariciones en filtraciones de datos. El nombre parece ser un pseudónimo.

La primera contribución pública de JiaT75 a xz-utils ocurrió el veintinueve de octubre de 2021 —nueve meses después de la creación de la cuenta. Fue un parche menor para un archivo de configuración del editor. Inocuo. Sin importancia. El tipo de contribución que establece presencia sin atraer escrutinio.

Durante los siguientes dos años y cinco meses, JiaT75 fue autor de más de quinientos commits a proyectos de código abierto. La gran mayoría fueron mejoras legítimas —revisiones de código, traducciones, mantenimiento de integración continua, correcciones de errores. Trabajo útil. Genuinamente útil.

Aproximadamente ocho de esos commits fueron maliciosos.

La proporción importa. Sesenta a uno. Por cada commit malicioso, el operador produjo sesenta piezas de trabajo real y útil. Esto es lo que hizo imposible detectar el patrón mediante el análisis de anomalías estadísticas. El atacante dedicó dos años y medio de esfuerzo dedicado a producir contribuciones genuinamente valiosas, puramente para acumular la confianza necesaria para realizar los ocho cambios que finalmente importaron.

La operación no trabajó sola.

A principios de abril de 2022, un usuario que se hacía llamar Jigar Kumar apareció en la lista de correo xz-devel. Kumar no tenía historial en la lista antes de abril de 2022. Toda su presencia consistió en correos electrónicos de presión al mantenedor principal del proyecto, quejándose de los lentos tiempos de respuesta y exigiendo que se agregara un nuevo mantenedor.

En mayo de 2022, apareció una segunda cuenta —Dennis Ens— preguntando sobre el estado de mantenimiento de la versión Java de xz-utils, y siguiendo con mensajes de presión adicionales.

Ambas cuentas tenían el mismo perfil. Sin presencia digital antes de 2022. Sin actividad fuera de la lista de correo xz-devel. Sin participación en ningún otro proyecto antes o después de la campaña de presión.

En febrero de 2024 —semanas antes de que se cometiera la puerta trasera— apareció una tercera cuenta. Hans Jansen. El papel de Jansen era presionar a los mantenedores de Debian para que adoptaran la versión comprometida de xz-utils lo antes posible. El veinticinco de marzo de 2024, Hans Jansen presentó un informe de error de Debian solicitando explícitamente la actualización.

Cuatro días después, Andres Freund publicó sus hallazgos en oss-security.

Dos cuentas de apoyo adicionales —krygorin4545 y misoeater91— proporcionaron presión de fondo en varios hilos, siguiendo el mismo patrón. Sin presencia previa a la operación. Participación solo durante ventanas de presión específicas. Desaparición después de que se lograron los objetivos.

El análisis post-incidente de Kaspersky señaló que el estilo geográfico de los nombres de los sock-puppets era inconsistente —Singaporean, European, Indian— sugiriendo que el operador había dispersado deliberadamente las identidades encubiertas para evitar la apariencia de coordinación. Pero el patrón de comportamiento —el momento de las apariciones, los puntos de presión sincronizados, la desaparición colectiva después de cada objetivo— sugería un único operador o un equipo estrechamente coordinado.

La presión funcionó.

El veintinueve de junio de 2022, el mantenedor principal de xz-utils —un desarrollador de software finlandés llamado Lasse Collin— respondió a la lista de correo y afirmó que Jia Tan tendría un papel más importante en el proyecto en el futuro, y que, en la práctica, ya funcionaba como co-mantenedor.

Este fue el traspaso.

Para entender lo que acababa de pasar, es necesario entender cuál era la posición de Lasse Collin.

Collin había mantenido xz-utils, solo, desde 2009. El proyecto no era remunerado. Trabajaba en él en su tiempo libre. A principios de ese mismo mes, en una respuesta a la lista de correo de junio de 2022, Collin había reconocido públicamente que estaba lidiando con problemas de salud mental a largo plazo. Se refirió al proyecto, en sus propias palabras, como un proyecto de hobby no remunerado.

Lasse Collin no es responsable de lo que sucedió. La comunidad de seguridad ha sido unánime en este punto. Collin estaba realizando un trabajo de hobby no remunerado. Estaba lidiando con desafíos de salud documentados. Estaba bajo una presión sostenida y coordinada de lo que resultó ser una operación de inteligencia a nivel estatal. El sistema que lo colocó en esa posición le falló. Él no falló al sistema.

Lo que la operación explotó no fue la competencia de Collin. Fue su posición estructural —solo, sin remuneración, lidiando con estresores del mundo real, responsable de mantener infraestructura utilizada por miles de millones de personas, sin apoyo institucional.

El atacante profesional identificó esa estructura y la tomó como objetivo.

Una vez completado el traspaso, comenzó la preparación de la infraestructura.

En octubre de 2022, Jia Tan fue añadido a la organización Tukaani en GitHub. En diciembre de 2022, creó la estructura organizativa del repositorio e hizo su primera publicación. En marzo de 2023, cambió el correo electrónico de contacto de seguridad principal en Google's OSS-Fuzz —la plataforma automatizada de escaneo de vulnerabilidades— de la dirección de Lasse Collin a la suya propia. A partir de ese momento, cualquier informe de error relevante para la seguridad llegaría a Jia Tan antes que a cualquier otra persona.

En junio de 2023, Jia Tan introdujo la infraestructura de resolución IFUNC en liblzma. Los commits parecían ser un trabajo legítimo de optimización de rendimiento. En retrospectiva, eran los ganchos a través de los cuales la puerta trasera finalmente sería inyectada.

En julio de 2023, Jia Tan abrió una pull request en OSS-Fuzz para deshabilitar el fuzzing de IFUNC para xz. El cambio estaba destinado a evitar que la pipeline de prueba de fuzz detectara anomalías en la puerta trasera basada en IFUNC cuando finalmente se lanzara.

En febrero de 2024, un commit separado rompió la detección del sistema de compilación de Landlock —una característica de seguridad del kernel Linux que restringe los privilegios de los procesos. El commit deshabilitó el propio sandbox de xz en sistemas que de otra manera lo habrían aplicado.

Los días veintitrés de febrero y nueve de marzo de 2024, la puerta trasera en sí fue comprometida en dos etapas, empaquetada como parte de las versiones xz-utils 5.6.0 y 5.6.1.

Diecinueve días después, Andres Freund notó un retraso de 500 milliseconds en SSH.

Los investigadores que analizaron los metadatos de los commits dejados por la operación notaron un patrón.

Los timestamps de los commits de Jia Tan se agruparon principalmente en las zonas horarias de Europa Central o Europa del Este. Las horas de trabajo correspondían aproximadamente de las nueve de la mañana a las cinco de la tarde hora de Europa Central. La actividad continuó durante los principales días festivos chinos y se detuvo durante varios europeos.

El nombre, y la geografía operativa declarada, era de Asia Oriental. El patrón de trabajo real era europeo.

Esto es lo que los analistas de inteligencia llaman fuga de firma. Un operador pasó más de treinta meses manteniendo una identidad de fachada. Pero los timestamps automáticos incrustados en cada commit de git revelaron periódicamente la ubicación real de la máquina que estaba realizando el commit.

Han aparecido tres posibles atribuciones en análisis públicos de investigadores de seguridad con experiencia relevante.

El investigador de seguridad estadounidense Dave Aitel, ex científico informático de la NSA, evaluó públicamente que la operación encaja en el patrón atribuible a APT29 —el grupo de amenaza persistente avanzada atribuido por los gobiernos de United States y United Kingdom al Foreign Intelligence Service de Russia. APT29 es conocido por campañas de espionaje de larga duración, incluida la vulneración de la cadena de suministro de SolarWinds revelada en 2020. Los horarios de trabajo alineados con la zona horaria de Moscú coinciden con el patrón de Jia Tan.

Costin Raiu —exdirector del Global Research and Analysis Team de Kaspersky, con tres décadas de experiencia atribuyendo operaciones sofisticadas— identificó tres candidatos plausibles en una entrevista de podcast de febrero de 2026. El APT29 de Russia fue uno. El APT41 de China, asociado con el Ministry of State Security, fue un segundo. El Lazarus Group de North Korea, ya presentado en una cobertura anterior de Fragment Zero, fue un tercero.

Hasta abril de 2026, ningún servicio de inteligencia ha atribuido públicamente la operación. No se han presentado acusaciones. No se han realizado arrestos. La verdadera identidad de Jia Tan sigue siendo desconocida.

Lo que no está en disputa, entre los investigadores con experiencia relevante en el oficio, es que la paciencia de la operación, la seguridad operativa, la sofisticación criptográfica y el compromiso de recursos son consistentes con un servicio de inteligencia de un estado-nación —o un equivalente funcional cercano— y son inconsistentes con la actividad criminal individual o hacktivista.

Este no fue el trabajo de un hacker solitario.

La operación xz-utils fue posible gracias a una característica estructural de cómo la civilización tecnológica moderna construye su infraestructura crítica.

El software que alimenta internet fue construido, en gran medida, por voluntarios que trabajaban en su propio tiempo. Las empresas que se benefician de este software han contribuido con una pequeña fracción de su valor económico.

xz-utils se incluyó en cada distribución principal de Linux y se ejecutó en una enorme fracción de servidores globales. Su mantenedor no era remunerado. OpenSSL, la biblioteca que proporciona criptografía a la mayor parte de internet, notoriamente carecía de personal antes de la vulnerabilidad Heartbleed en 2014. Log4j, la biblioteca de registro Java detrás de la vulnerabilidad Log4Shell en 2021, fue mantenida por un puñado de voluntarios —detrás de la infraestructura empresarial a nivel mundial.

En todos los casos, una biblioteca tratada como infraestructura crítica por empresas multimillonarias fue mantenida con recursos de proyectos de hobby.

La operación xz-utils no inventó esta vulnerabilidad estructural. La explotó.

El once de abril de 2024 —dos semanas después de la revelación de Freund— la U.S. Cybersecurity and Infrastructure Security Agency publicó una declaración formal reconociendo el problema estructural. La posición de CISA: la carga de asegurar la infraestructura de código abierto no puede recaer en mantenedores individuales no remunerados, y las empresas que consumen software de código abierto deben contribuir, ya sea financieramente o con tiempo de desarrolladores, para producir un ecosistema sostenible.

Las recomendaciones no eran vinculantes. Eran mejores prácticas. Dependían de la adopción voluntaria por parte de empresas cuya estructura de incentivos no había recompensado históricamente la inversión.

En el plazo de un mes, la Linux Foundation y la Open Source Security Foundation publicaron una alerta conjunta advirtiendo que ya estaban en curso intentos similares de toma de control por ingeniería social contra múltiples otros proyectos de código abierto. La OpenJS Foundation —que mantiene Node.js, jQuery y la infraestructura JavaScript relacionada— divulgó públicamente que había recibido una campaña de presión coordinada siguiendo el mismo patrón que xz-utils, y la había rechazado solo porque la divulgación de xz-utils había enseñado a la comunidad qué buscar.

Un informe de la Linux Foundation de 2026 documentó el patrón más amplio en todo el ecosistema. El hallazgo central del informe: lo que sucedió con xz-utils no fue un incidente singular. Fue un método. El método se está intentando a escala. La mayoría de las detecciones exitosas se están produciendo porque el caso xz-utils proporcionó una firma para comparar.

Cuántas detecciones fallidas hay —operaciones ya en curso que aún no han sido detectadas— es por construcción imposible de contar a partir de fuentes públicas.

Hace dos episodios de Fragment Zero, el expediente del caso sobre la hipótesis del Dark Forest se cerró con una observación. La doctrina que Liu Cixin formalizó en 2008 —el silencio como supervivencia, el ocultamiento como necesidad estratégica, la revelación como peligro existencial— es el principio de seguridad operativa más antiguo en la historia del conflicto humano.

Toda fuerza que ha operado bajo condiciones de amenaza incierta y capacidad asimétrica ha llegado a la misma conclusión.

Guarda silencio. Muévete con cuidado. Asume que estás siendo observado.

La operación xz-utils es el Dark Forest ejecutado dentro de una relación de confianza humana.

El atacante no vulneró un firewall. El atacante no explotó una vulnerabilidad de día cero. El atacante no eludió ninguna protección criptográfica. El atacante hizo algo mucho más simple. El atacante se escondió a plena vista durante tres años, produciendo trabajo útil, construyendo credibilidad genuina, comportándose exactamente como cualquier otro colaborador útil, mientras preparaba —en silencio, pacientemente, con una paciencia estratégica inimaginable para la mayoría de las organizaciones técnicas— el momento en que la infraestructura preparada sería utilizada.

El ataque tuvo éxito casi por completo porque fue silencioso. Fue detectado no por ninguna herramienta de seguridad, ni por ninguna auditoría, ni por ninguna defensa institucional, sino por la observación accidental de un ingeniero de quinientos milliseconds de latencia inexplicada.

La declaración de Andres Freund sobre su propio descubrimiento, publicada en Mastodon semanas después de la divulgación, debería cerrar el expediente.

Confiar en la suerte en el futuro es una mala estrategia.

La puerta trasera de xz-utils fue capturada.

La versión Dark Forest de la operación —aquella que se dirige a las relaciones de confianza en lugar de a los sistemas informáticos— se está intentando ahora mismo, en este preciso momento, contra un número indeterminado de otros proyectos críticos de código abierto. El patrón funciona. Los incentivos económicos que lo hacen funcionar no han cambiado de manera significativa. Las respuestas institucionales han sido reales pero insuficientes.

El ingeniero que encuentre el próximo también necesitará suerte. Necesitará estar mirando el benchmark correcto en el momento adecuado en el sistema correcto. Necesitará importarle lo suficiente como para rastrear una anomalía hasta su origen. Necesitará publicar sus hallazgos antes de que el principal de la operación haya enviado la carga útil a las versiones estables.

Necesitarán, específicamente, los quinientos milliseconds.

Ese intervalo es lo que se interpuso entre internet en marzo de 2024 y una única clave criptográfica en manos de un actor desconocido que habría desbloqueado cada servidor Linux que ejecutara SSH en la Tierra.

Fragment Zero seguirá el expediente.

El expediente no se cierra. Espera.