Esta puerta trasera de Linux pudo ser una catástrofe de seguridad

Un ingeniero de Microsoft descubrió por casualidad una puerta trasera implantada en XZ Utils, una popular herramienta de sistemas Linux que, si hubiera sido explotada, podría haber traído consecuencias catastróficas a la seguridad de miles de equipos en todo el mundo. Un golpe de suerte que, sin dudas, ha evitado un sinfín de dolores de cabeza, pero que también ha expuesto una trama bastante turbia sobre las amenazas de ciberseguridad contra proyectos de código abierto.

¿Qué ha sucedido? La historia es un tanto compleja y revuelve sobre asuntos bastante técnicos que pueden resultar confusos para quienes no están inmiscuidos en el mundo Linux. Es por ello que trataremos de mantener este artículo lo más sencillo posible, y enlazaremos a distintos textos de expertos en los que se estudia y analiza el incidente con más propiedad.

Hecha esa aclaración, avancemos. El viernes pasado, el ingeniero Andres Freund, de Microsoft, estaba realizando pruebas en un sistema basado en Debian, cuando notó algo extraño. El desarrollador descubrió que el rendimiento del protocolo SSH, o Secure Shell, que permite conectarse a servidores remotos de forma segura a través de internet, no era óptimo. Un análisis más profundo lo llevó a encontrar que estaba consumiendo más recursos de lo habitual en su CPU, y a detectar errores al ejecutar Valgrind, un software para depurar problemas de memoria y performance.

Si bien Freund no es un experto en ciberseguridad, las sospechas no se hicieron esperar. Al estudiar el asunto en más detalle, llegó a la conclusión de que se había topado con una puerta trasera implantada en XZ Utils, una herramienta muy popular en Linux para comprimir y descomprimir datos sin pérdida.

XZ Utils, el blanco de una peligrosa puerta trasera en Linux

Lo que el ingeniero descubrió por absoluta casualidad fue que XZ Utils había sido modificado para incluir código malicioso en sus versiones 5.6.0 y 5.6.1. Según las pistas que se han recabado durante el fin de semana, la puerta trasera que se implementó en esta herramienta de Linux fue producto de un trabajo de hormiga.

Los primeros registros de esto datan de 2021. Por entonces, uno o más usuarios operando bajo el usuario «JiaT75» comenzaron a presionar para hacerse cargo de continuar con el mantenimiento de esa utilidad. Según explican desde DoublePulsar, los aparentes piratas informáticos habrían usado «ingeniería social» para que el antiguo encargado del software les delegara su gestión.

Los cambios en el código de XZ Utils, que permitieron implantar una puerta trasera en Linux, comenzaron a implementarse con asiduidad desde comienzos de 2023. Sin embargo, nadie se percató de ello hasta que Freund descubrió por casualidad la vulnerabilidad el viernes pasado.

¿Qué hacía esta puerta trasera de Linux? Según la información disponible hasta ahora, el código malicioso de XZ Utils se ejecutaba al lidiar con archivos comprimidos en el formato .lmza. Si alguna de esas tareas implicaba el uso del protocolo SSH, los ciberdelincuentes que contaran con una llave de cifrado predeterminada podrían conectarse de forma remota a los equipos a través de ese backdoor. Una vez logrado eso, serían capaces de ejecutar cualquier tipo de comando con privilegios de root, como si fueran un administrador legítimo del equipo. Esto les daría, por ejemplo, la autoridad para concretar ataques sin ningún tipo de restricción.

Una vulnerabilidad que, por suerte, no llegó a ser masiva

Afortunadamente, la versión maliciosa de XZ Utils no se llegó a implementar de forma masiva. La puerta trasera se detectó en un número limitado de distribuciones de Linux, como Kali Linux, openSUSE Tumbleweed, openSUSE MicroOS, Fedora Rawhide y versiones inestables y experimentales de Debian. Red Hat, por ejemplo, ha encontrado que la beta de Fedora Linux 40 incluye las variantes maliciosas de la utilidad de compresión. Es por ello que están recomendando a los usuarios que reviertan a la versión 5.4 de XZ Utils.

La detección de esta puerta trasera en Linux se dio justo a tiempo, puesto que si hubiera pasado desapercibida, podría haber traído consecuencias calamitosas. Con OpenSSH ejecutándose actualmente en unos 20 millones de direcciones IP en todo el mundo, si una vulneración de este tipo hubiese llegado a explotarse de forma masiva, estaríamos hablando de un problema gravísimo.

¿Cómo pudo pasar desapercibido algo tan problemático? Los responsables de alterar XZ Utils con código malicioso sabían lo que hacían, evidentemente. Según menciona Ars Technica, la puerta trasera implantada en Linux usaba un cargador de cinco etapas para mantenerse indetectable. Además, indica que el ataque parecía apuntar a un tipo específico de equipos: aquellos basados en AMD64 y con software derivado de Debian o Red Hat, que ejecutaran la biblioteca de C de GNU, conocida popularmente como glibc. La etapa final del backdoor se explotaba solo si se cumplían esas condiciones, según parece.

Nada para celebrar

La detección temprana de esta puerta trasera de Linux no es para celebrar, advierten expertos. El calibre de la vulnerabilidad pudo ser tal que, de no ser por la corazonada de Andres Freund, esto pudo haber escalado a niveles muy complejos.

Filippo Valsorda, un ingeniero y experto en criptografía, fue contundente sobre su relevancia. «Este podría ser el ataque a la cadena de suministro mejor ejecutado que hemos visto descrito abiertamente, y es un escenario de pesadilla: malicioso, competente y autorizado en una biblioteca ampliamente utilizada», publicó.

El investigador Damien Miller también enfatizó sobre el peligro que hubiera supuesto una explotación masiva de esta puerta trasera en Linux. «Este es el más cercano de los casi accidentes. Cualquiera que sugiera que esto fue algún tipo de éxito es un tonto. Ningún sistema se dio cuenta de esto. Fue suerte y heroísmo individual. Eso no es aceptable cuando el acceso no autorizado a prácticamente todos los servidores de internet está sobre la mesa. Necesitamos encontrar una manera de hacerlo mejor», indicó.

Si quieren adentrarse en la cuestión más técnica de esta vulnerabilidad, a continuación les dejo algunos links de interés (en inglés):