El desarrollo de software tiene muchos desafíos y brindar soporte es una tarea compleja que, en teoría, debería contar con un equipo 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 software liderado por una sola persona, se suelen cometer errores al lanzar una nueva actualización. Pero, ¿qué pasaría si alguien de la nada decidiera echarte una mano con esto?
A principios de abril, Andred Freund, ingeniero de Microsoft y desarrollador de PostgreSQL, reveló una vulnerabilidad crítica que afectó la cadena de suministro de una utilidad de compresión de datos XZ. Implementado en todos los sistemas operativos basados en Linux/UNIX. Esto permitiría a un atacante eludir la autenticación de un shell seguro y obtener acceso completo al sistema afectado.
El descubrimiento de este ataque a la cadena de suministro, uno de los más grandes hasta la fecha, fue accidental. ¿Qué hubiera pasado si la nueva actualización hubiera 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 Linux?
A continuación repasamos, según el historial de versiones (logs de GitHub), el paso a paso de cómo el atacante utilizó diferentes técnicas para infiltrarse en el proyecto y poner en riesgo la seguridad de miles de servidores en el mundo.
El arte de la guerra se basa en el engaño: “títeres de calcetines” mal utilizados
En posts anteriores hemos mencionado la importancia de contar con Sock Puppets como herramientas OSINT que permitan 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 en grandes proyectos de software y ganarse la confianza de los desarrolladores para poder introducir código malicioso, no existen límites.
Esto es lo que les pasó a quienes apoyan los accesorios XZ. Analizando al responsable de introducir deliberadamente este código malicioso 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 XZ fue la siguiente:
En 2021, JiaT75 creó su cuenta en GitHub y sus primeros aportes no fueron al proyecto de utilidad de compresión, sino a otros de menor impacto, es decir, pretendía ser alguien desinteresado en busca del “bien de la comunidad”. Perfil bajo, pero bastante informado.
Para principios de 2022, JiaT75 logra realizar su primer compromiso con el repositorio XZ: este aporte se debió al envío de un parche a través de una lista de correo, aquí es donde comienza la presión al equipo de desarrolladores para incorporar el parche lanzado por JiaT75.
Unos días más tarde y tras presiones, Lasse Collin (actual y único desarrollador que apoya el proyecto XZ) admite JiaT75 para realizar pruebas sobre las funciones del hardware.
En junio de 2023, JiaT75 prueba la biblioteca “liblzma” e implementa el puntero llamado “crc64_fast.c” en el método “ifunic”.
En julio de 2023, se abre un Pull Request en OSS-FUZZ (un proyecto que tiene como objetivo hacer que el software común de código abierto sea más seguro y estable combinando técnicas modernas de fuzzing) y el método “ifunc” se desactiva debido a problemas introducidos por los cambios anteriores. . Esto parecía ser deliberado para enmascarar cambios maliciosos que se introducirán pronto.
A principios de 2024, Google cambia la URL del proyecto de “tukaani.org/xz/” a “xz.tukaani.org/xz-utils/”, este último alojado en Finlandia y dando a JiaT75 un mayor control sobre el proyecto desde de la versión “5.44.245.25xz”
En febrero de 2024, JiaT75 agrega el primer archivo malicioso “build-to-host.m4” que luego se incorporará al paquete de actualización.
Poco después, en marzo de 2024, JiaT75 añade dos archivos de prueba ofuscados y cifrados (bad-3-corrupt_lzma2.xz y good-large_compressed.lzma) donde Andrés Freund encontraría la puerta trasera.
El descubrimiento, al igual que pasó con Alexander Fleming y la penicilina, se produjo cuando Andrés Freund estaba realizando unas micro pruebas de rendimiento, al darse cuenta de que la CPU y la biblioteca “liblzma” consumían más recursos que en versiones anteriores.
Así, el 29 de marzo de 2024, Andrés Freund decide reportar este incidente en openwall para que el repositorio y las versiones 5.6.0 y 5.6.1 de XZ sean inmediatamente eliminados de GitHub.
Lecciones aprendidas
Como resumen de lo que se puede aprender de este ataque podemos decir que:
- Cuando los ciberdelincuentes tienen un objetivo, pueden llegar a niveles extremos para infiltrarse en proyectos, empresas o cadenas de suministro.
- Ya lo decía Sun Tzu en El arte de la guerra: La paciencia es la virtud del guerrero. La dedicación y paciencia por parte de JiaT75 para ganarse la confianza de Lasse Collin y empezar a ser uno de los referentes en el proyecto XZ es algo que hay que tomar con mucho cuidado.
- Este evento no es el primero ni el último que puede ocurrir, también está el de Apache Log4j donde una vez más hay dependencia del software de código abierto y de proyectos gestionados por voluntarios y comunidades cuyas intenciones son mayoritariamente el bienestar digital, pero como podría ser Como se ve, también hay quienes buscan lo contrario.
- Las organizaciones, desarrolladores y comunidades deben contar con herramientas y procesos que les permitan identificar la manipulación e inserción de códigos maliciosos en el desarrollo de software, evitando que afecten a una gran cantidad de dispositivos.
