En febrero de 2024, una cuenta que utilizaba el nombre "Jia Tan" introdujo una puerta trasera maliciosa en la compilación de Linux de la utilidad xz dentro de la biblioteca liblzma en las versiones 5.6.0 y 5.6.1. [b] [2] La puerta trasera otorga a un atacante que posee una clave privada Ed448 específica capacidades de ejecución remota de código en el sistema Linux afectado. El problema recibió el número de vulnerabilidades y exposiciones comunes CVE - 2024-3094 y se le asignó una puntuación CVSS de 10.0, la puntuación más alta posible. [3] [4]
Si bien xz está presente comúnmente en la mayoría de las distribuciones de Linux , en el momento del descubrimiento, la versión con puerta trasera aún no se había implementado ampliamente en los sistemas de producción , pero estaba presente en las versiones de desarrollo de las principales distribuciones. [5] La puerta trasera fue descubierta por el desarrollador de software Andres Freund, quien anunció sus hallazgos el 29 de marzo de 2024. [6]
El empleado de Microsoft y desarrollador de PostgreSQL, Andres Freund, informó sobre la puerta trasera después de investigar una regresión de rendimiento en Debian Sid . [7] Freund notó que las conexiones SSH estaban generando una cantidad inesperadamente alta de uso de CPU, además de causar errores en Valgrind , [8] una herramienta de depuración de memoria. [9] Freund informó su hallazgo a la lista de correo de seguridad de código abierto del Proyecto Openwall , [8] lo que lo llevó a la atención de varios proveedores de software. [9] El atacante hizo esfuerzos para ofuscar el código, [10] ya que la puerta trasera consta de múltiples etapas que actúan juntas. [11]
Una vez que la versión comprometida se incorpora al sistema operativo, altera el comportamiento del demonio del servidor SSH de OpenSSH abusando de la biblioteca systemd , lo que permite al atacante obtener acceso de administrador. [11] [9] Según el análisis de Red Hat , la puerta trasera puede "permitir que un actor malicioso rompa la autenticación sshd y obtenga acceso no autorizado a todo el sistema de forma remota". [12]
Una investigación posterior descubrió que la campaña para insertar la puerta trasera en el proyecto XZ Utils fue la culminación de aproximadamente tres años de esfuerzo, entre noviembre de 2021 y febrero de 2024, [13] por parte de un usuario con el nombre de Jia Tan y el apodo de JiaT75 para obtener acceso a una posición de confianza dentro del proyecto. Después de un período de presión sobre el fundador y el mantenedor principal para que entregaran el control del proyecto mediante una aparente manipulación , Jia Tan obtuvo el puesto de co-mantenedor de XZ Utils y pudo aprobar la versión 5.6.0, que introdujo la puerta trasera, y la versión 5.6.1, que corrigió algunos comportamientos anómalos que podrían haber sido evidentes durante las pruebas de software del sistema operativo. [9]
Algunos de los seudónimos sospechosos de ser manipulados incluyen cuentas con nombres de usuario como Jigar Kumar , krygorin4545 y misoeater91 . Se sospecha que los nombres Jia Tan , así como el supuesto autor del código Hans Jansen (para las versiones 5.6.0 y 5.6.1) son seudónimos elegidos por los participantes de la campaña. Ninguno de ellos tiene ningún tipo de presencia pública visible en el desarrollo de software más allá de los pocos años de la campaña. [14] [15]
La puerta trasera se destacó por su nivel de sofisticación y por el hecho de que el perpetrador practicó un alto nivel de seguridad operativa durante un largo período de tiempo mientras trabajaba para alcanzar una posición de confianza. El investigador de seguridad estadounidense Dave Aitel ha sugerido que se ajusta al patrón atribuible a APT29 , un actor de amenazas persistentes avanzadas que se cree que trabaja en nombre del SVR ruso . [13] El periodista Thomas Claburn sugirió que podría ser cualquier actor estatal o un actor no estatal con recursos considerables. [16]
Se sabe que el código malicioso se encuentra en las versiones 5.6.0 y 5.6.1 del paquete de software XZ Utils. El exploit permanece inactivo a menos que se use un parche específico de terceros del servidor SSH. En las circunstancias adecuadas, esta interferencia podría permitir potencialmente que un actor malicioso rompa la autenticación sshd y obtenga acceso no autorizado a todo el sistema de forma remota. [12] El mecanismo malicioso consta de dos archivos de prueba comprimidos que contienen el código binario malicioso. Estos archivos están disponibles en el repositorio git , pero permanecen inactivos a menos que se extraigan y se inyecten en el programa. [2] El código usa el mecanismo glibc para reemplazar una función existente en OpenSSH llamada con una versión maliciosa. OpenSSH normalmente no carga liblzma, pero un parche de terceros común usado por varias distribuciones de Linux hace que cargue libsystemd , que a su vez carga lzma. [2] Se incluyó una versión modificada de en el archivo tar de lanzamiento cargado en GitHub , que extrae un script que realiza la inyección real en . Este archivo m4 modificado no estaba presente en el repositorio git; solo estaba disponible en archivos tar publicados por el mantenedor por separado de git. [2] El script parece realizar la inyección solo cuando el sistema se está construyendo en un sistema Linux x86-64 que usa glibc y GCC y se está construyendo a través de dpkg o rpm . [2]IFUNCRSA_public_decryptbuild-to-host.m4liblzma
La Agencia Federal de Seguridad Cibernética y de Infraestructura de Estados Unidos ha emitido un aviso de seguridad recomendando que los dispositivos afectados vuelvan a una versión anterior no comprometida. [17] Los proveedores de software Linux, incluidos Red Hat, SUSE y Debian , han revertido los paquetes afectados a versiones anteriores. [12] [18] [19] GitHub deshabilitó los espejos para el repositorio xz antes de restaurarlos posteriormente. [20]
Canonical pospuso el lanzamiento de la versión beta de Ubuntu 24.04 LTS y sus variantes por una semana y optó por una reconstrucción binaria completa de todos los paquetes de la distribución. [21] Aunque la versión estable de Ubuntu no se vio afectada, las versiones originales sí lo fueron. Esta medida de precaución se tomó porque Canonical no podía garantizar antes de la fecha límite de lanzamiento original que la puerta trasera descubierta no afectara a paquetes adicionales durante la compilación. [22]
El informático Alex Stamos opinó que "ésta podría haber sido la puerta trasera más extendida y efectiva jamás instalada en un producto de software", y señaló que si la puerta trasera hubiera permanecido sin detectar, habría "dado a sus creadores una llave maestra para cualquiera de los cientos de millones de computadoras en todo el mundo que ejecutan SSH". [23] Además, el incidente también inició un debate sobre la viabilidad de que partes críticas de la ciberinfraestructura dependan de voluntarios no remunerados. [24]
