El desarrollo de software tiene muchos retos y dar soporte es una tarea compleja que, en teoría, debaría contar con un equipoo dedicado a corregir errores y garantizar que no haya vulnerabilidades. Es bien sabido que dos o más cabezas piensan mejor que una. En un ciclo de desarrollo de un software liderado por una sola persona se tiende a cometer errores al momento de lanzar una nueva actualización. ¿Pero, qué pasaría si alguien de la nada decide darte una mano con esto?
A principios de abril, Andred Freund, ingeniero de Microsoft y desarrollador de PostgreSQL, dio a conocer una vulnerabilidad crítica que afectó a la cadena de suministro de una utilería de compresión de datos XZ. implementada en todos los sistemas operativos basados en Linux/UNIX. Esto permitiría a un atacante evadir la autenticación de una Shell segura y obtener acceso completo al sistema afectado
El descubrimiento de este ataque a la cadena de suministro, uno de los más importantes hasta la fecha, fue accidental. ¿Qué hubiera pasado si la nueva actualización hubiese llegado a miles de servidores en el mundo? ¿Podría haber sido un grave desastre de seguridad si se hubiera integrado en las versiones estables de las distribuciones de Linux?
A continuación repasamos, de acuerdo al historial de versiones (logs de GitHub), el paso a paso de cómo el atacante utilizó distintas técnicas para infiltrarse en el proyecto y poner en riesgo de la seguridad de miles de servidores en el mundo.
El arte de la guerra se basa en el engaño: Los "Sock Puppets" usados indebidamente
En post pasados se ha mencionado la importancia de contar con Sock Puppets como herramientas de OSINT las cuales permiten a los investigadores actuar sin ser descubiertos ni dejar rastro de su trabajo; estos perfiles evitan acceder desde sus cuentas personales y ser rastreados. Sin embargo, cuando la intención es adentrarse a proyectos enormes de software y ganarse la confianza de los desarrolladores para poder introducir código malicioso, no existen límites.
Tal es lo que le sucedió a quienes dan soporte a la utilería de XZ. Haciendo un análisis del responsable de introducir este código malicio deliberadamente en las versiones 5.6.0 y 5.6.1 es el usuario de GitHub cuyo seudónimo es Jia Tan (también conocido como Jia Cheong Tan o JiaT75).
La historia de cómo Jia Tan (JiaT75) pudo infiltrarse en el proyecto de XZ se dio de la siguiente manera:
En el año del 2021 JiaT75 crea su cuenta en GitHub y sus primeras contribuciones no eran hacia el proyecto de la utilería de compresión, sino a otros de menor impacto, es decir, simuló ser alguien desinteresado en busca del “bien de la comunidad”, de bajo perfil, pero con bastantes conocimientos.
Para principios de 2022, JiaT75 logra hacer su primer commit al repositorio de XZ: esta contribución se debió a envío un parche a través de una lista de correo, es aquí donde se comienza a presionar al equipo de desarrolladores para incorporar el parche liberado por JiaT75.
Pocos días después y tras la presión ejercida, Lasse Collin (actual y único desarrollador que da soporte al proyecto XZ) admite a JiaT75 para realizar pruebas en funciones de hardware.
En junio del 2023, JiaT75 hace pruebas sobre la librería “liblzma" e implementa en el método de "ifunic" el apuntador llamado "crc64_fast.c"
En julio del 2023, se abre un Pull Request en OSS-FUZZ (proyecto que tiene como objetivo hacer que el software de código abierto común sea más seguro y estable mediante la combinación de técnicas modernas de fuzzing) y se deshabilita el método "ifunc"vdebido a problemas introducidos por los cambios anteriores. Esto parecía ser deliberado para enmascarar los cambios maliciosos que se introducirán pronto.
A principio del 2024, Google cambia la URL del proyecto de "tukaani.org/xz/" a "xz.tukaani.org/xz-utils/" este último alojado en Finlandia y dándole un mayor control a JiaT75 sobre el proyecto a partir de la versión "5.44.245.25xz"
En febrero del 2024, JiaT75 agrega el primer archivo malicioso "build-to-host.m4" para luego ser incorporado al paquete de actualizaciones.
Poco tiempo después, en marzo del 2024, JiaT75 agrega dos archivos de prueba ofuscados y cifrados (bad-3-corrupt_lzma2.xz y good-large_compressed.lzma) en donde Andres Freund encontraría la puerta trasera (backdoor).
El descubrimiento al igual que ocurrió con Alexander Fleming y la penicilina, se da cuando Andres Freund realizaba unas micro pruebas de rendimiento dándose cuenta de que la CPU y la librería "liblzma" estaban consumiendo más recursos que en versiones anteriores.
Así el 29 de marzo del 2024, Andres Freund decide reportar este incidente en openwall para que de inmediato el repositorio y versiones 5.6.0 y 5.6.1 de XZ sean eliminados de GitHub.
Lecciones aprendidas
A modo de resumen sobre qué es lo que se puede aprender de este ataque podemos decir que::
- Cuando los ciberdelincuentes tienen un blanco, se pueden llegar a niveles extremos para lograr infiltrarse a proyectos, empresas o cadenas de suministros.
- Ya lo dijo Sun Tzu en el Arte de la Guerra: La paciencia es la virtud del guerrero. La dedicación y paciencia por parte de JiaT75 de ganarse la confianza de Lasse Collin y empezar a ser uno de los referentes en el proyecto XZ, es algo de lo que se debe tener mucho cuidado.
- Este suceso no es el primero ni el último que se pueda dar, también se encuentra el de Apache Log4j donde una vez más existe la dependencia del software de código abierto y de los proyectos gestionados por voluntarios y comunidades cuyas intenciones en su mayoría son el bienestar digital, pero como se pudo observar también existen aquellos que buscan todo lo contrario.
- Las organizaciones, desarrolladores y comunidades deben de contar con herramientas y procesos que les permitan identificar la manipulación e inserción de código malicioso en el desarrollo de software, evitando a que puedan llegar a afectar a un gran número de dispositivos.
