👻 La Newsletter de @weareDMNTRs 👻
A ver, hoy no había newsletter.
Porque yo iba a estar tocando con la banda por muchos rincones de Andalucía durante toda la semana y hoy estaría descansando.
PERO, la cosa no ha venido como estaba planificada.
Básicamente, hemos acabado con la sequía en una semana de lluvia, lluvia y más lluvia. 🌧️🌧️🌧️
Y claro, la verdad es que cansado, cansado no estoy. Así que una vez de vuelta de los preceptos del Domingo de Resurrección y vistos los sucesos acaecidos, me he decidido a preparar este número especial de la newsletter.
¿Y de qué voy a hablar hoy?
Pues si... ¡Del proyecto XZ!
¿Qué no te has enterado? ¿De verdad?
A ver, pues voy a intentar explicarlo:
Imagina que te llamas Andrés Freund y trabajas como ingeniero para Microsoft.
Mientras realizas tareas de actualización "sientes" que el acceso SSH a determinados servidores con Debian Sid "de repente" es un poquito más lento y que tira algunos errores no esperados.
Así que te pones a hacer tareas de "microbenchmarking" del tema y observas, que sí, que estás en lo cierto, que algo pasa.
Cuando investigas un poquito más a fondo te das cuenta de que el repositorio upstream de la librería XZ contiene UN BACKDOOR.
Y te das cuenta de que esa puerta trasera afecta al servicio sshd, por lo que cada vez que se inicia sesión en la máquina la librería hace "algo que no debería hacer".
¡Y encima te das cuenta de que las versiones afectadas ya están desplegadas en muchas distros! La mayoría en versiones de prueba, eso sí, pero el código malicioso ya está paseándose por ahí...
Pero... WTF! ¿Qué está pasando?
¡Esto es MUY GRAVE! Así que una vez recopilas toda la información del tema, lo publicas en una lista de correo de seclist.org y... ¡Lo demás ya es historia!
Pero a ver, ¿qué es XZ Utils (antes llamada LZMA Utils)? Básicamente, se trata de una librería, ampliamente utilizada, para realizar la compresión de datos sin pérdida. Vamos para ahorrar ancho de banda o espacio en disco, por ejemplo, disponible en Linux, Mac o Windows.
El código malicioso se ha localizado en las versiones 5.6.0 y 5.6.1 de XZ y ha sido ofuscado, por lo que todavía se está estudiando que es lo que hace, aunque parece claro que podría lanzar un shell remoto e intentar dar al atacante la posibilidad de ejecutar código malicioso remoto en la máquina infectada.
Básicamente dicho código se añade en la etapa de compilación, de manera que la librería XZ envenenada resultante es utilizada involuntariamente por software, como por ejemplo systemd, después de que la misma se haya distribuido e instalado.
El malware parece haber sido diseñado para alterar el funcionamiento de los demonios del servidor OpenSSH que emplean la xz a través de systemd.
Es posible que este compromiso de la "cadena de suministro" se haya detectado lo suficientemente temprano como para evitar una explotación generalizada, y es posible que solo afecte principalmente a las distribuciones de última generación que adoptaron las últimas versiones de xz de inmediato.
Pero la cosa es lo suficientemente grave como para que Debian, RedHat o Fedora hayan lanzado avisos del tipo: "PLEASE IMMEDIATELY STOP USAGE OF ANY FEDORA RAWHIDE INSTANCES for work or personal activity".
El CVE generado, el CVE-2024-3094, tiene una puntuación base de 10 sobre 10. ¡10 sobre 10!
¿Miedito eh?
El nivel de sofisticación del Back-Door es tal que necesitaríamos un par de newsletters para resumirlo, aunque el amigo Thomas Roccia ha lanzado en twitter esta infografía explicativa, que lo mismo puede serviros para enteraros de cómo va el tema.
¿Y cómo entro el Backdoor en XZ? 🤔🤔🤔
Bueno, aquí la historia se vuelve truculenta y muy interesante. Lo que viene siendo salseo del friki, así que voy a intentar explicarlo todo:
En abril de 2022, un usuario de git, JiaT75, también conocido como Jia Tan, comienza a "ayudar" en el proyecto. Poco después, aparece un nuevo actor, llamado "Jigar Kumar", y comienza a quejarse del lento ritmo de desarrollo de XZ:
"Jigar Kumar" sigue presionando al desarrollador original, Lasse Colin, para que agregue más mantenedores al repositorio y claro, el mejor colocado en ese momento era Jia.
Así que el 8 de junio de 2022, Lasse Collins coloca a Jia Tan como "segundo de abordo". ‼️‼️‼️
Desde entonces, Jia se convirtió en un colaborador habitual del proyecto:
En el transcurso de los siguientes 21 meses, Jia realiza casi 750 contribuciones al proyecto, pero, curiosamente, la mayoría de ellos en días laborables, ninguno en sábado o domingo. ¿Cuánto tiempo libre no?
El 6 de enero de 2023, JiaT75 ya había ganado suficiente confianza de Lasse, que además pasaba por un mal momento en lo que a salud mental se refiere, como para poder realizar merges del código por su cuenta.
¡Qué alegría encontrar gente que ayuda! ¡Bien! 🤪🤪🤪
El 23 de junio de 2023, "Hans Jansen", otro colaborador del proyecto ahora en entredicho, que incluso podría ser el mismo Jia Tan, ofrece un nuevo commit que afirma mejorar el rendimiento entre un 4 y un 5% en algunas plataformas, al reemplazar el constructor crc64 con ifunc. Ello hace que surjan "cositas inesperadas" en algunos sistemas, en forma de segmentations faults.
Así que el 27 de junio, el parche con Ifuncs se mergea en el proyecto, con una nota importante que pedía a los usuarios que simplemente deshabilitaran la implementación de ifunc si causaba problemas. Con ifunc deshabilitado, xz se ejecutará en su código constructor crc64 original como solía hacerlo.
Básicamente, esto creó 2 comportamientos diferentes de la herramienta xz. Si la plataforma se ejecuta con ifunc deshabilitado, se llama a un constructor CRC64, mientras que de forma predeterminada, se llamará a la implementación de Ifunc. ¡Volveremos a esto más adelante!
Ahora viene la cosa más rara de todas, el proyecto Oss-fuzz de Google, que ayuda a los desarrolladores a automatizar las pruebas de su software, utiliza xz para algunas de las tareas relacionadas con la compresión/descompresión, por lo que los cibercriminales debian evitar que Google pudiera entrar "a fondo" en el código de XZ y encontrar lo que estaban preparando
Así que ni corto ni perezoso, Jia abrió un bug en el repositorio oss fuzz de Google y les pidió que deshabilitaran ifuncs al usar xz como parte de oss-fuzz, para evitar los segfaults de los que hablamos antes. Este cambio fue aceptado. ¡El Jia este es un mastodonte!
Es decir, cuando xz se ejecuta como parte de oss-fuzz, se ejecuta como su versión anterior y no infectada según la implementación del constructor crc64. Mientras que en la mayoría de los otros lugares, se ejecuta a través de ifunc. Con ello se aseguraban de que Google no iba a entrar a ver la implementación de ifunc, que era la que estaba "preparada para hacer el mal".
Varios meses más tarde, y después de seguir manteniendo el proyecto sin levantar sospechas, Jia finalmente envió los archivos maliciosos al proyecto XZ y los integró en la release un poco después. Exactamente el 23 de febrero de 2024.
Desde este momento, XZ se convierte en un "mecanismo de entrega de malware" que, cuando se ejecuta en condiciones adecuadas, permitiría a los ciberdelincuentes acceder al sistema infectado de manera remota.
¿Cómo te has quedado con todo esto? 🤪🤪🤪
Si Andrés Freund no hubiera sentido esa "conmoción en el ssh" dentro de nada hubiéramos tenido un problema MUCHO MÁS serio aún del actual, que bueno, que no es moco de pavo, pero imagínate que la librería se lanza en todas las versiones estables y tal...
Por poner un ejemplo en estos momentos Debian está considerando downgradear XZ al código de hace 2 años, antes de que Jia Tan hiciera alguna aportación al proyecto, lo cual tiene muchas implicaciones tanto de política de desarrollo como de testeo del sistema.
¿Y esto porque?
Pues porque al ponerse a examinar con detenimiento los commits de Jia, se han encontrado más modificaciones "raras".
Por ejemplo, hay código extraño en cómo XZ usa Landlock, una característica del kernel de linux que permite restringir los derechos(por ejemplo, global sistema de archivos o acceso a la red) para un conjunto de procesos. Toca auditarlo TODO. 😱😱😱
Total que ya no se fía ni Dios de lo que hay en ese repositorio... pero... ¿QUIÉN ES ESTE TÍO? ¿Quien es Jia Tan?
Bueno, pues hay teorías de todo tipo y gente haciendo OSINT a lo bestia para localizarlo.
Se dice que puede ser un actor state-sponsored, se habla de China, de Rusia, de megacorporaciones... ¡DE LOCOS! Pero a ciencia cierta nadie sabe nada, excepto que alguien se ha pasado 2 puñeteros años preparando todo esto. ¡2 años!
Y la cosa es que esta vez la pelota ha rozado el poste, pero... ¿Cuántos Jia Tans hay actualmente en otros proyectos? ¿Cuántas operaciones de este tipo pueden estar en marcha? ¿Es esto solo la punta del iceberg? ¿Apagamos ya los servidores?
Aquí lo dejo, disfruten de la paranoia dominical...
¡Feliz Domingo de Resurrección a todos!
Newsletter patrocinada por:
Cybersec - Networks - Sysadmin - Hosting
🔗 Cajón desastre... 🔗
Los enlaces que he ido recopilando sobre el tema del día:
Y fin...
Bueno, pues acabó esta Semana Santa tan atípica en lo meteorológico y en lo personal.
En 33 años que llevo tocando no he vivido una decepción similar y, a día de hoy, no sé si volveré siquiera a intentarlo.
Así que ahora toca reflexionar y disfrutar de la primavera o del invierno o lo que quiera que sea en lo que estamos ahora.
¡El tiempo está roto!
Mientras tantos nos seguimos por los canales habituales de Twitter y Telegram (ji ji ji).
¡Esto no es serio! ¡Ahora hay newsletter! ¡Ahora no hay newsletter!
