Bebes agua del grifo todos los días, ¿verdad? ¿Sabes quién inventó el mecanismo de filtrado que hace que su agua esté pura y limpia?… bueno, ¿de verdad te importa?
¿Sabes que ese mecanismo es exactamente el mismo en todos los grifos de todas las casas de cualquier país?, ¿sabes que esa pieza, especializada, es obra de un ingeniero que lo hace por amor al arte?, ¿te imaginas que puede pasar si esta persona tiene un mal día?
Hablemos de la librería XZ Utils y por qué no es buena idea depender de un único proveedor y encima tocarle las narices. Hablemos de la librería XZ Utils y de su último desarrollador, Jia Tan.
Sí, el software de código abierto nos puede ofrecer una serie de beneficios en términos de precio (sí, porque es “gratis”), transparencia, colaboración y adaptabilidad, pero también entraña un riesgo respecto a la seguridad y confianza excesiva que depositamos como usuarios.
¿Qué ocurrió?
El pasado 29 de marzo, Red Hat, Inc. daba a conocer la vulnerabilidad CVE-2024-3094, contando con una puntuación de 10 en la escala de Common Vulnerability Scoring System, y, por lo tanto, una vulnerabilidad crítica, la cual comprometía a los servidores SSH afectados.
Esta vulnerabilidad afectaba al paquete XZ Utils, que es un conjunto de herramientas de software que proporcionan compresión y descompresión de archivos mediante el algoritmo LZMA/LZMA2, y que se incluye en las principales distribuciones de Linux. De no haber sido descubierta, podría haber sido muy grave, ya que se trataba de un código malicioso de tipo backdoor el cual otorgaría acceso remoto no autorizado a los sistemas afectados mediante SSH.
La vulnerabilidad daba comienzo en la versión 5.6.0 de XZ, y afectaría también a la versión 5.6.1.
Durante el proceso de compilación de liblzma extraería un archivo de prueba camuflado existente en el código fuente, posteriormente utilizado para modificar funciones específicas en el código liblzma. El resultado es una librería liblzma modificada, que puede ser usada por cualquier software enlazado a la misma, interceptando y modificando la interacción de datos con la librería.
Este proceso de implementar una backdoor en XZ es la parte final de una campaña que se ha extendido durante 2 años de operaciones, principalmente de tipo HUMNIT (inteligencia humana) por parte del usuario Jia Tan.
El usuario Jia Tan creó su cuenta de Github en 2021, realizando su primer commit al repositorio de XZ el día 6 de febrero de 2022. Más recientemente, el 16 de febrero de 2024 se añadiría un fichero malicioso bajo el nombre de “build-to-host.m4” en .gitignore, posteriormente incorporado junto al lanzamiento del paquete, para finalmente el día 9 de marzo de 2024 incorporar el backdoor oculto en dos ficheros de testeo:
- tests/files/bad-3-corrupt_lzma2.xz
- tests/files/good-large_compressed.lzma
¿Cómo se dieron cuenta?
La principal persona encargada de localizar este problema es Andres Freund.
Se trata de uno de los ingenieros de software más importantes en Microsoft, quien se encontraba realizando tareas de micro-benchmarking. Durante sus pruebas, se dio cuenta de que los procesos de sshd estaban usando una cantidad de CPU poco normal a pesar de que no se establecieran las sesiones.
Tras perfilar sshd, vio mucho tiempo de CPU en la librería liblzma. Esto a su vez le recordó a una reciente y extraña queja de Valgrind sobre las pruebas automatizadas en PostgreSQL. Este comportamiento podría haberse pasado por alto y no ser descubierto, lo que hubiera originado una gran brecha de seguridad en servidores SSH Debian/Ubuntu
Según comenta el propio Andres Freund, se requirieron de una serie de coincidencias para poder encontrar esta vulnerabilidad, vamos que fue cuestión de suerte haberlo encontrado.
Lo que encendió las alarmas de Freund fue un pequeño retraso de tan solo 0.5 sec en las conexiones ssh, que aunque parece muy poco, fue lo que lo llevó a investigar más a fondo y encontrarse con el problema y el potencial caos que pudo haber generado.
Esto recalca la importancia de vigilar la ingeniería de software y las prácticas de seguridad. La buena noticia es que, la vulnerabilidad se ha encontrado en releases muy tempranas del software, por lo que en el mundo real no ha tenido prácticamente ningún efecto, gracias a la rápida detección de este código malicioso. Pero nos hace pensar en lo que habría podido pasar, de no haberse detectado a tiempo. No es la primera vez que ocurre ni la última que ocurrirá. La ventaja del Open Source es que esto se ha hecho público y se puede evaluar el impacto, en otros casos donde no hay dicha transparencia, el impacto puede ser más difícil de evaluar y por tanto, la remediación.
Reflexión
Con lo sucedido, podemos destacar tanto puntos positivos como negativos relacionados con el uso del código abierto.
Como puntos positivos podemos encontrar transparencia y colaboración entre desarrolladores de todo el mundo. Tener una comunidad vigilante, encargada de detectar y reportar posibles amenazas de seguridad, y contar con flexibilidad y adaptabilidad, ya que la naturaleza del código abierto permite adaptar y modificar el software según las necesidades específicas.
En cuanto a lo malo, encontramos la vulnerabilidad a ataques maliciosos, como es este caso con la actuación de desarrolladores con intenciones malignas. Los usuarios confían en que el software no contenga código malicioso, lo que puede llevar a una falsa sensación de seguridad. Además, debido a la cantidad de contribuciones que existen y a la propia complejidad del software, se puede decir que es muy difícil verificar de manera exhaustiva el código.
Si a esto le añadimos la existencia de librerías que son mantenidas por una persona o un muy pequeño grupo de personas, el riesgo de punto único de falla es mayor. En este caso, esa necesidad o beneficio de disponer de más gente aportando es lo que causó el problema.
En conclusión, si bien el software de código abierto nos puede ofrecer una serie de beneficios en términos de transparencia, colaboración y adaptabilidad, también puede presentar desventajas o desafíos en cuanto a la seguridad y confianza que depositamos como usuarios.
El equipo de redacción de Pandora FMS está formado por un conjunto de escritores y profesionales de las TI con una cosa en común: su pasión por la monitorización de sistemas informáticos. Pandora FMS’s editorial team is made up of a group of writers and IT professionals with one thing in common: their passion for computer system monitoring.
