xz backdoor
Hablamos estos días de seguridad en el sentido más amplio y de excepciones y esta es una de ellas: un problema que está sobresaliendo frente a los demás es el que ha afectado a las utilidades de XZ, un formato de compresión bastante extendido entre los sistemas tipo Unix en general y Linux en particular.
El problema de seguridad detectado por un ingeniero de Microsoft en las utilidades de la versión 5.6 de XZ no es la típica vulnerabilidad, sino que es una puerta trasera (backdoor) que ha sido introducida de manera intencionada por una persona que usa Jia Tan como nombre y JiaT75 como pseudónimo. El proceso de introducción de la puerta trasera parece que no fue sencillo, sino que requirió de bastante picardía por parte de esta persona malintencionada. Sin embargo, logró salirse con la suya y el único consuelo que queda es que la puerta trasera fue detectada antes de que la cosa fuera demasiado lejos.
Sobre las capacidades de la puerta trasera y según explica el blog de Red Hat, el binario resultante de la compilación del código fuente tiene la capacidad de interferir en la autenticación de SSH a través de systemd, abriendo así la puerta a que un actor malicioso pueda romper la autenticación de de sshd (el daemon de SSH) para obtener acceso en remoto a una computadora de manera no autorizada.
Tras destaparse el escándalo, GitHub decidió inhabilitar el repositorio de XZ por violar sus términos de servicio. Esta medida, que se espera sea temporal, se ha tomado con el propósito de prevenir y evitar la propagación de la puerta trasera a más sistemas aparte de los afectados, que al final han sido unos cuantos y no precisamente de la escena underground de Linux.
Imagen mostrando que el repositorio de código de XZ ha sido cerrado en GitHub
Imagen mostrando que el repositorio de código de XZ ha sido cerrado en GitHub.
El hecho de que la puerta trasera fuera introducida en la versión más reciente XZ, o al menos así consta de momento, ha minimizado el impacto a distribuciones de perfil bleeding edge. Dentro del ecosistema de Red Hat, en un principio fue detectada en Fedora 41 y la rama Rawhide de la distribución comunitaria, pero una investigación más exhaustiva detectó que los usuarios de la versión 40 también se vieron afectados si habían habilitado los repositorios de prueba.
En caso de no haber habilitado los repositorios de prueba en Fedora 40, el usuario se habría quedado en el repositorio estable y no habría recibido la versión maliciosa de XZ, la cual tampoco está presente en Fedora 39, RHEL 9 ni debería estar en derivadas como AlmaLinux, Rocky Linux y Oracle Linux.
En lo que respecta a openSUSE, los encargados de la distribución del camaleón han reconocido que introdujeron XZ 5.6.0 en Tumbleweed y MicroOS entre los días 7 y 28 de marzo. Como medida de mitigación se ha revertido la versión de XZ y se han publicado nuevas imágenes de los dos sistemas. Como es de esperar, SUSE Linux Enteprirse y Leap no se han visto afectadas debido a que son mantenidas aparte por su enfoque más empresarial y hacia el suministro de un software más estanco.
Arch Linux también ha distribuido la versión maliciosa de XZ. Los responsables han recomendado actualizar cuanto antes las instalaciones en máquina física y máquina virtual y la imagen de contenedor para Podman y Docker. Los medios que tienen implementada la puerta trasera son el medio de instalación 2024.03.01, las imágenes para máquinas virtuales 20240301.218094 y 20240315.221711 y las imágenes de contenedor de entre el 24 de febrero de 2024 y el 29 de marzo de 2024. La versión de XZ que contiene la mitigación es la 5.6.1-2. Si el usuario tiene instalada la 5.6.0-1 o la 5.6.1-1, debe actualizar cuanto antes a través de vía estándar: pacman -Syu
Versión XZ presente en Fedora Silverblue 39
Canonical ha publicado que es consciente del problema que ha afectado a las utilidades de XZ y ha eliminado la versión afectada de la biblioteca de las propuestas de compilación de Ubuntu 24.04 LTS. La compañía ha anunciado que está investigando el asunto, cosa normal viendo la gravedad y por lo tanto la prudencia que requiere, y ha mostrado su agradecimiento a los miembros de la comunidad que están contribuyendo al respecto. El hilo de Discourse donde se ha publicado esto ha sido cerrado, así que no hay más información presente en el mismo medio.
Y como no, Debian también se ha visto afectada. Andres Freund, el ingeniero de Microsoft detrás del hallazgo, descubrió la puerta trasera después de detectar problemas de rendimiento en un sistema Debian que estaba usando SSH. Siendo más concretos, vio que el daemon consumía demasiados ciclos del procesador y que Valgrind, un marco con herramientas capaces de detectar automáticamente fallos en la gestión de la memoria y los procesos, le estaba arrojando errores. Las ramas afectadas, siguiendo lo visto en los casos anteriores, son Testing, Unstable y Experimental.
El fallo de seguridad introducido en SSH, que es seguido como CVE-2024-3094, parece atajado, pero ante una situación como esta es preferible mantener la prudencia mientras no se tenga claro que todo está solucionado. Si se quiere comprobar qué versión de XZ está instalada, el usuario puede ejecutar el siguiente comando:
xz --version
Debido a que la puerta trasera está dirigida a SSH, la inhabilitación total de su daemon o su desinstalación del sistema es otra medida de mitigación que debería poder contemplarse, pero aquí entramos en las circunstancias de cada uno. A estas alturas no hace falta decir que toda distribución que suministre XZ 5.6 está afectada si los responsables no han tomado medidas, algo que las grandes del sector ya han hecho.
https://www.muylinux.com/2024/04/01/pue ... emd-linux/Si bien ya está corregido, lo detectó un "ingeniero de microsoft". Notó algo raro cuando probando una cosa, tardaba algo más de lo normal e investigó
Ahora otro que no es malware, pero algo peor incluso:
Hablábamos el otro día de cómo la Snap Store se va a poner un poco más seria con la prevención del malware y toca ampliar un poco la perspectiva, porque el mal ware se puede dar donde menos te lo esperas. Esta vez le ha tocado a la KDE Store, la tienda de «complementos» de KDE Plasma y aunque no se trata de un suceso para nada común, puede pasar. Hablemos de seguridad, pues.
Lo cierto es que es que de tanto en cuando se lee por ahí de vulnerabilidades en Linux, de los métodos de explotación y tal, y si casi nunca nos hacemos eco de esas noticias es por algo: por lo general, es complicado que estas amenazas tengan un efecto considerable en los usuarios, por la serie de elementos y circunstancias que deben coincidir para ello; y la gran mayoría de las veces, cuando se da a conocer el problema, ya se están enviando los parches que lo solucionan.
Para entenderlo más fácilmente, sería como hacer una noticia por cada parche para agujeros de seguridad considerados como críticos de los que se incluyen en cada actualización de una aplicación -este es el pan de cada día en el desarrollo de los navegadores web- o sistema. En mi opinión, no merece la pena perder el tiempo con esas cosas: es preferible repetir de vez en cuando la tradicional lista de buenas prácticas (mantener el software actualizado, no instalar nada raro de fuentes no fiables, etc).
Las excepciones son estos casos. Casos como el mencionado de la Snap Store, en el que se les coló software de minado de criptomonedas en segundo plano, como el del malware en los repositorios de Arch Linux de hace unos años, también con el mismo perfil de software malicioso (sí, un minero oculto es malware). O como este que nos ocupa, mucho más serio en mi opinión, aun cuando no se puede categorizar de la misma manera.
Según cuenta un usuario en Reddit, procedió a instalar un tema global de Plasma (estos incluyen un montón de cosas: tema del escritorio, de las aplicaciones, colores, wallpapers, pantallas de bienvenida y más elementos) cuando le apareció un diálogo pidiendo su contraseña de administrador. Fue entonces cuando le olió mal el asunto y canceló la instalación, pero para ese entonces ya se había borrado todos sus datos de usuario: «Todas las unidades montadas bajo de mi usuario habían desaparecido, hasta 0 bytes, juegos, configuraciones, datos del navegador, carpeta de inicio, todo había desaparecido», explica.
seguridad
Por lo que cuenta, la instalación de este tema habría ejecutado un script con el comando «rm -rf» (un borrador recursivo) que le limpió el almacenamiento al que tenía acceso (por lo general, todo menos la raíz y sus directorios base) y se pregunta, obviamente, qué habría sucedido de poner su contraseña y darle vía libre al mismo. Si lo que le pasó a este usuario (ojo: casa 4.000 descargas tenia este tema, así que a saber cuántos se vieron afectados) hubiese sido premeditado, estaríamos hablando de malware de la vieja escuela, del que no quiere robarte nada, sino amargarte la existencia destruyendo tu sistema o, como ha sido el caso, tus datos.
Pero no fue así. Como es normal, el tema ha generado revuelo y varios desarrolladores de KDE han salido a dar explicaciones. Así, David Edmundson comenta en su blog que este tema, el cual fue eliminado de la KDE Store, no era software malicioso como tal: su autor cometió un error en el código. El error concreto no se detalla, pero es fácil imaginar que se lió con lo que debía ser el borrado del tema o algo similar. Ahora bien, no es excusa porque la faena que le hizo al tipo es tremenda.
Edmundson expone el problema específico y sus pormenores, apunta hacia la advertencia que aparece cada vez que alguien quiere instalar algo desde la KDE Store (se suele hacer directamente desde las aplicaciones del sistema, por ejemplo, a través de «Preferencias del sistema > Aspecto y estilo > Colores y temas > Tema global > Obtener novedades…»; y así con otras complementos, como los widgets del escritorio); habla de las expectativas de seguridad realistas al instalar cosas y, claro de qué pueden hacer mejor para evitar estos problema…
A todo esto, un apunte adicional: es normal que muchos temas globales pidan la contraseña de administrador porque pueden tener la opción de instalarse para todos los usuarios del sistema, o porque se meten tan adentro de la personalización que tocan elementos que precisan de permisos para ser modificados. La cuestión es que, como como he mencionado y menciona Edmundson, si bien hay que poner más medidas para que estas cosas no pasen, también lo tiene que hacer el usuario por su parte, con lo también mencionado: las buenas prácticas.
En este caso, aplicar unas buenas prácticas habría sido revisar los comentarios de este tema, probarlo en un entorno seguro (una máquina virtual, un usuario de pruebas…) y, de tener los conocimientos, revisar el paquete y sus contenidos, además de, por supuesto, tener implantado un buen sistema de copias de seguridad. Pero seamos honestos: ¿quien hace tanto rollo para probar un tema de Plasma que además se consigue a través del propio escritorio? Ya te lo digo yo: nadie.
Pero nadie. Ni siquiera el que hizo el tema se molestó en comprobarlo, antes de subirlo, que ya tiene delito. Por suerte, cabe repetir, no es algo que suela pasar habitualmente. Lo cual no le quita responsabilidad ni al autor de tamaño descalabro, ni a la KDE Store, ya que estamos, por más advertencias que se den. Es clamoroso que no se pongan medidas que prevengan estas situaciones, a pesar de que la seguridad total no exista. Un mensajito de alerta es poca cosa.
Por cierto, formatos como Snap y Flatpak (Edmundson pone de ejemplo a Flatpak) pueden ayudar en este terreno, aunque la supervisión del usuario seguirá siendo necesaria para optimizar la seguridad. Y es que de seguridad va la historia.
Este es un caso aislado, pero también es una buena muestra de que la seguridad tiene más de un cara. No todo es cibercrimen. A ver quién no prefiere que se le cuele un minero que lo único que hace es quitarle un poco de procesador, a que le borren los datos. En ambos casos, però, la seguridad ha fallado… y estamos a expensas de esos fallos en múltiples ámbitos: en el mismo sistema, las aplicaciones, nuestra actividad…
seguridad
Así que, he aquí una buena práctica elemental por definición: copias de seguridad, siempre. Claro que, visto lo visto, tendremos que repasar el resto un día de estos.
Para terminar, un apunte para los curiosos: lo más probable es que, de haber introducido el usuario siniestrado su contraseña de administrador, no hubiese pasado nada, porque las distribuciones modernas suelen tener seguros contra acciones de ese tipo. Si alguien quiere comprobarlo, eso sí, que lo haga con las debidas precauciones.
https://www.muylinux.com/2024/03/29/mal ... les-caras/Un tipo se descarga un tema de kde desde el propio KDE y le aplicó el comando rm -rf. No dio permisos de administrador y a pesar de eso, le borró todo lo que tenía montado. Las carpetas personales y todos los discos duros que tuviera montados.
Sobre esto último. De nada sirve no tener permisos de root, si por una puerta trasera pueden acceder a tus datos principales. Es igual que en android. La gente guarda sus cosas personales (fotos, vídeos,pdfs...) en el directorio corriente. No con permisos root. Si te dañasen el root, pues con rescatar datos y formatear datos, sería suficiente. Pero si te borran tus cosas, que no tengan acceso a root, es secundario. Te podrían sacar las contraseñas del navegador web, si las tienes ahí por ejemplo.
Sobre el backdoor. Es un caso muy similar a android. En android han colado bichos en la playstore. Validan una app y en siguientes versiones la meten con bicho. Esto es similar. Era un formato de compresión, que en breve iría para ubuntu 24.04, basadas en arch, fedora y otras... Los repos los mantiene el creador y no siempre revisa todo lo que se publica. Por lo que podrías tener bicho incluso en flatpak o en la snap store de ubuntu.
¿Qué quiero decir con esto?. En gnu/linux se lleva años viviendo con una falsa seguridad. Hay sitios donde ponen resoluciones de vulnerabilidades y algunas tardan años en resolverse. Lo que pasaba es que era un S.O minoritario y no era factible para los hackers estos sistemas. Pero ahora parece que sí y si llegase a la cuota de Mac OS o superior, pues tendríamos más cosas de éstas.
Por mi experiencia. En windows, la mayoría de bichos y vulnerabilidades, suelen darse al ejecutar algo que no debes. Normalmente camuflado en otra cosa. Incluido el famoso ramsonware.
Pero si afecta a repos oficiales de la distro de linux, es mucho peor. Ya que en este caso, imaginad el daño si se descubre el bicho meses más tarde. El sistema de permisos, no sirve de mucho, a no ser que lo necesites hasta para montar un pendrive. Si te cuelan bicho en chromium y lo tienes instalado. Pueden acceder a los cookies y las contraseñas y suplantar tu identidad en diferentes sitios web. Sobre el código abierto. La idea es muy buena. Pero es como vivir en una urbanización de lujo y que todo el mundo tenga acceso a los planos, a la rotación de los guardias de seguridad, etc...A su vez, no todo el mundo es programador, ni tiene tiempo para repasar todas las líneas de código. Se basa mucho en la buena fe de los demás.
En resumen. La gente pensaba que con ubuntu o fedora, iban a estar más seguros que con winbug. Pero la realidad es que también son sistemas vulnerables y peor, ya que todo va vía oficial repositorio.
Decir que el fondo da igual lo que uses. Si tiene internet, si alguien se propone, entra en tu sistema. Como ya ha pasado a muchos políticos por ejemplo.
