xz las dos últimas letras del abecedario, que podrían haber tenido grandes consecuencias a nivel de ciberseguridad en todo el mundo, de hecho, quizá es incluso un poco prematuro hablar de las no consecuencias, pero todo apunta a que se ha detectado a tiempo, como mínimo para que no se convierta en un gran desastre.

¿Qué se ha detectado a tiempo?, pues un “backdoor” o lo que es lo mismo una puerta trasera en el código de una librería open source que es utilizada por múltiples componentes del SO Linux (según parece hay varios otros paquetes con dependencias de este), aunque en este caso y en concreto se ha centrado por su gravedad en el sshd, por lo que implicaría poder usar esa puerta para poder entrar y tomar el control de un equipo.

Toda una genialidad sino tuviera objetivos oscuros, ya que al parecer se lleva dos años gestando en la mente de un actor malicioso que pretendía poder aprovecharse de este código una vez distribuido en todas las versiones de Linux, ya que aunque no todas son iguales, pero al final suelen converger en algún momento del tiempo conforme cada una decide actualizar sus componentes y dependencias. Pero todo apunta a que han dado con su plan al traste, la versión maliciosa de dicha librería ha estado disponible desde el 26 de febrero de 2024 y solo ha llegado a versiones inestables (de desarrollo de Debian), a Fedora y a Kali (a partir del 26 de marzo), más adelante doy más detalles.

xz es un paquete que contiene la librería liblzma utilizada para compresión, la vulnerabilidad, asignada como CVE-2024-3094, permite el acceso remoto no autorizado a los sistemas Linux afectados. Las versiones afectadas por la puerta trasera son las utilidades XZ y la biblioteca liblmza asociada en las versiones 5.6.0 desde finales de febrero y 5.6.1 desde el 9 de marzo. Estas versiones XZ comprometidas, introducidas por uno de los propios desarrolladores de XZ, eluden la autenticación SSH, lo que permite a un posible atacante hacerse con el control remoto total del sistema.

Una vez descubierta la noticia y en un primer reporte al que tuve acceso de la misma, se hablaba de que al haber unicamente dos desarrolladores conocidos de ese paquete e identificado el que había realizado la subida del mismo (como era un contribuidor habitual de código), se supuso que su equipo podría haber sido comprometido y que por tanto no había sido el mismo desarrollador el que había introducido intencionadamente esta vulnerabilidad, pero a fecha en que escribo este post, parece que todas las noticias apuntan a que no ha sido así y que ha sido una acción deliverada y planeada.

El desarrollador de software Andreas Freund escribe sobre su descubrimiento de la vulnerabilidad: “Tras observar algunos síntomas extraños en torno a liblzma (parte del paquete xz) en instalaciones Debian sid durante las últimas semanas (inicios de sesión con ssh que consumían mucha CPU, errores de valgrind)” y descubrió la respuesta mirando el código fuente. Según alguna fuente de investigación, todo empezó porque empezó a detectar que los inicios de sesión al sshd iban más lentos, en alguna noticia se menciona, aquí ya no sé si se trata de una exageración, se habla de 0,5 seg. más de lo habitual, que junto con el resto de síntomas explicados anteriormente llevó a este desarrollador a encontrar el código ofuscado introducido en el upstream de este paquete, es decir, que iba más allá de la propia distribución de Linux que él estaba utilizando. El código backdoor que sólo estaba parcialmente oculto se encontraba en el código fuente publicado en GitHub.

Las distribuciones de Linux afectadas, para las que ya hay actualizaciones disponibles, a excepción de Fedora Rawhide, son

• Debian Testing, Inestable y Experimental
• Fedora Rawhide
• Arch Linux
• openSUSE Tumbleweed

Distribuciones como Debian Stable, Fedora 39, openSUSE Leap o Red Hat Enterprise Linux (RHEL) no están afectadas por la vulnerabilidad en XZ Utilities. Si utiliza una de las distribuciones de Linux mencionadas, puede comprobar el número de versión de XZ Utilities en la consola con

xz -version.

De hecho, mi Kali Linux versión 2024.1 que recien había instalado hace unos días y actualicé (quien no quiere tener la última versión) contenía xz-utils 5.6.1 (por suerte, es una máquina virtual en mi red interna y que no tenía ningún puerto abierto), la solución disponible, a partir de que se conoció la noticia el 29 de marzo, era realizar un downgrade de dicho paquete.

Lo ideal es realizar una nueva instalación, especialmente si el acceso SSH está habilitado en el sistema Linux, por si acaso se hubiera podido estar expuesto a un ataque durante este tiempo en que no se había descubierto esta vulnerabilidad.

Seguramente si estáis al tanto de este tipo de noticias, esta infografia ya la habréis visto antes, pero creo que resume muy bien todo lo comentado anteriormente e incluso añade algunos detalles técnicos omitidos intencionadamente, para que cualquiera con mínimos conocimientos pueda hacerse cargo de lo ingeniosa y peligrosa que es esta vulnerabilidad, ingeniosa entre otras cosas por como se había planteado su distribución, un Supply Chain Attack en todo regla.