Puerta trasera en software de compresión (liblzma) que afecta a OpenSSH

Se ha incrustado una vulnerabilidad tipo "backdoor" (que permitiría un acceso al sistema infectado) en las últimas versiones de la librería de compresión liblzma, que es usada por las grandes distros de GNU/Linux en el paquete OpenSSH, que proporciona acceso a equipos remotos. Enlace al anuncio del desarrollador que ha encontrado la puerta trasera. Más info en el enlace.

[#9 pkreuzt]

Comunicado oficial del (otro, no involucrado) desarrollador principal:

tukaani.org/xz-backdoor/

En Debian están proponiendo ya eliminar completamente el paquete xz-utils y hacer una transición dura hacia ZSTD

[#25 anthk]

#9 En Hyperbola usan xz tan ricamente pero en una versión anterior.

[#27 pkreuzt]

#25 Se ha propuesto, pero tiene efectos colaterales importantes. En Debian, dpkg depende de versiones modernas de xz. En Red Hat creo que tienen un problema similar.

[#28 anthk]

#27 .pacman -Q xz
xz 5.2.4-2

En Slackware 15 (la current supongo que se lo habrá comido) será similar.
Slackware -stable con slapt-get y algunos repos (slapt-get maneja deps y prioridades) puede ser tan capaz como Arch pero siendo LTS.

Hay un repo que tiene compilados todos los paquetes de Slackbuilds.

[#74 cernicalo]

#9 #28 #61 se ha detectado "pronto", afortunadamente. El paquete no parece haber visto repositorios de versiones estables o LTS. En Debian se coló en Trixie (testing) o superiores, y ya han metido el fix, con un número de versión muy majo: packages.debian.org/search?keywords=xz-utils (5.6.1+really5.4.5-1)

En Ubuntu, la versión más nueva en 23.10 era la 5.4.1 (Mantic Minotaur), pero estaba la 5.6 en la que sale en abril, 24.04 (Noble Numbat), y ahora sale con el mismo fix…   

[#61 soberao]

#9 Del enlace, del email* del desarrollador que encuentra el backdoor:
"openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma."

El problema es de Systemd aunque lo que se ve afectado es OpenSSH. De un parche que muchas distros añaden para que OpenSSH funcione con el sistema de notificaciones de Systemd.
* www.openwall.com/lists/oss-security/2024/03/29/4

[#64 anthk]

#61 Como usuario de OpenBSD remoto lo corraboro:

objdump -x $(which ssh) | grep NEEDED:

termbin.com/f71c

[#14 Cuñado]

#13 Los commits siempre están autenticados, no puede ir cualquiera y añadir cosas a un repo sin permiso.

No es lo mismo firmado que autenticado. Sí puedes añadir cosas a un repo sin ningún permiso, otra cosa es que necesites autenticarte para hacer pull a una plataforma como GitHub.

Pero yo no hablo de eso, sino de la firma del commit, que es algo propio de git (no como la autenticación de plataformas remotas, aunque soportado por todas ellas). Git te permite firmar los commits (GPG, s/mime...), pero no todo el mundo lo hace. Y éste es uno de esos casos.

[#18 pkreuzt]

#14 Repito que el comunicado lo que dice es que las releases afectadas son las montadas por Jia Tan y que por tanto llevan su firma. El autor lo que trata es de separar la actividad de un desarrollador de la del otro, no le vaya a caer el marrón a él también:

* XZ Utils 5.6.0 and 5.6.1 release tarballs contain a backdoor. These tarballs were created and signed by Jia Tan.

* Tarballs created by Jia Tan were signed by him. Any tarballs signed by me were created by me.

De los commits no dice nada, pero se asume que si alguien se hace con el control de la cuenta de un desarrollador, potencialmente podría subir y firmar lo que quiera.

[#19 Cuñado]

#18 Sí, cierto. Ayer se estuvo comentando en el hilo del repo y di por hecho que hablaba del commit.

se asume que si alguien se hace con el control de la cuenta de un desarrollador, potencialmente podría subir y firmar lo que quiera

No tiene por qué. Te pueden comprometer la cuenta de GitHub pero no tener acceso a tu passphrase de GPG, de hecho hay que ser muy insensato para almacenarla en un lugar que no sea la mente de uno

[#20 pkreuzt]

#19 Hombre, si las releases estaban firmadas. . .

Pero bueno, te podría contar historias de miedo de gente que guarda todas sus contraseñas en un txt en el escritorio o que reutiliza contraseñas y extrayéndo las del navegador (harto sencillo) te haces con todas las llaves.

[#21 Cuñado]

#20 gente que guarda todas sus contraseñas en un txt en el escritorio

Y por supuesto en un fichero que se llama "contraseñas.txt"

Trabajo en ciberseguridad y no te puedes ni imaginar la cantidad de casos de esos que se encuentran en medio de muchos incidentes. Incluso de algunos bastante sonados... Empresas que gastan un pastizal en seguridad para que luego "alguien" anote en un txt las credenciales ssh de un túnel que "alguien" abrió contra el entorno de desarrollo desde el cual, misteriosamente, se llega al entorno de producción... La verdad es que poco pasa.

[#22 pkreuzt]

#21 Se lo suelo decir a la gente que me pregunta: las contraseñas, si hay que apuntarlas en alguna parte, están más seguras en un postit pegado al monitor que en un txt dentro

[#23 Cuñado]

#22 LOL. Ese comentario lo he hecho más de una vez ante la mirada atónita de alguien que las apuntaba en texto plano en su equipo

De hecho, hace años, la única manera de convencer a una empresa de que eliminase la clave privada de la CA root que tenían almacenada en su servidor de ficheros fue proponiéndoles escribirla en dos papeles, dividirlos a la mitad y guardarlos en cuatro lugares bajo llave distintos

[#51 frg]

#23 La CA root se tiene en una máquina apagada dentro de un armario con un backup en cinta en una caja fuerte.

[#58 Cuñado]

#51 Ahí lo tienen en cuatro cajas fuertes... Digamos que es un negocio que por cajas fuertes no será

[#35 superjavisoft]

#21 Bueno, yo tengo algo similar pero con una buena password, asi a ojo como de seguro es eso? Es muy comun ser infectado por un programa que te lea el teclado?

[#37 Cuñado]

#35 Los keyloggers software son bastante comunes y (aunque son relativamente fáciles de detectar por un antivirus) uno nunca puede estar seguro. Lo mejor para estos casos es un gestor de contraseñas como Bitwarden.

[#65 SuperPollo]

#37 el la web o autoalojado

[#83 Cuñado]

#65 Yo uso vauitwarden. Es mucho más ligero que el server oficial y va como un tiro.

[#88 SuperPollo]

#83 no lo conocía, muchas gracias

[#52 frg]

#35 O un teclado troyanizado, o un dongle que haga de keylogger, o ...

[#56 tableton]

#21 totalmente de acuerdo. En mi empresa (sector software banca) se están constantemente realizando auditorías y pentests altamente exigentes. Y luego ves, al compartirte pantalla por teams, q un compañero de India guarda sus passwords con accesso a producción en excel y no sabe que lo que es el icono de keepass q tiene en el escritorio

[#59 mre13185]

#21 Conozco en mi trabajo gente que lo hace así, cuando yo les he recomendado hasta el hartazgo que usen gestores de contraseñas. Yo uso el keepassx porque es una versión portable entre plataformas, pero en Linux el archivo de contraseñas lo tengo guardado en una caja fuerte gestionada por Plasma, así que para ver incluso el archivo de claves tendría que abrir la caja fuerte. Quizá hace falta recordar el incidente que hubo hace poco relacionado con el tráfico de una compañía, no sé si Vodafone u Orange.

[#46 santeloc]

#20 y qué ne cuentas del "claves.xls"???

ahí meten hasta los CCC de sus bancos.

Si es que el mundo sigue rodando por la inercia que lleva...

[#82 pkreuzt]

#46 No quiero dar muchos datos de esto por razones obvias, pero me he encontrado por ahí un par de empresas que manejan pasta y hacen eso. Peor aún, el archivo en esos casos estaba en la raíz del servidor de dominio de Windows

[#26 hrundil]

#19 si alguien consigue acceso a una cuenta de GitHub puede cambiar la clave privada que se usa para firmar los commits. Al dueño de la cuenta le llegaría un email de que se ha añadido una nueva firma que el atacante tendría que evitar de alguna forma que fuera visto.
Luego en la interfaz de GitHub los commits saldrían con el tick verde indicando que están firmados y nadie se daría cuenta.

[#32 Cuñado]

#26 si alguien consigue acceso a una cuenta de GitHub puede cambiar la clave privada que se usa para firmar los commits.

En absoluto. La claves privadas no se almacenan en la cuenta de GitHub, sólo las públicas.

Pero eso no es una particularidad de GitHub, es la base misma de la criptografía asimétrica. Almacenar la clave privada en el sitio que tiene que verificarla sería peor incluso que no firmar nada.

[#34 hrundil]

#32 no me has entendido. No es obtener la clave privada sino cambiarla por otra en posesión del intruso o añadir una nueva en las opciones de GH.

docs.github.com/en/authentication/managing-commit-signature-verificati

You can add multiple public keys to your account on GitHub. Commits signed by any of the corresponding private keys will show as verified.

[#36 Cuñado]

#34 Precisamente: You can add multiple public keys to your account on GitHub.

Claves públicas. Lo que no puedes añadir son claves privadas, ni por tanto cambiarlas por otras.

Podrías añadir claves públicas, pero sería obvio para cualquiera que no es la misma firma.

[#39 hrundil]

#36 No es la misma firma pero para GH como si lo fuera. GH va a permitir commits con la nueva firma y les va a poner el tick verde de verificado en la UI. Es muy poco probable que alguien se diera cuenta de que son claves distintas hasta que fuera tarde.

Tú me estás contando cosas de claves privadas, y públicas mientras que yo te hablo del caso específico de GitHub y su interfaz.

[#40 Cuñado]

#39 A ver, puedes pushear un commit sin firmar y, teniendo en cuenta que el usuario no firmaba los suyos... sería bastante más sospechoso que empezase a hacerlo. El tick es la misma validación por parte de GitHub que puede hacer cualquier usuario (o cualquier repo vinculado, como los que tienen) y, precisamente, es a posteriori cuando se evidenciaría (llegado el caso) si pudo ser un compromismo o no.

Tú me estás contando cosas de claves privadas, y públicas

Lo que te estoy contando es que no puede subir claves privadas a GitHub, por más que te empeñes en repetirlo.

[#41 hrundil]

#40 hay razones para usar una nueva clave. Por ejemplo que vaya a expirar la anterior. En mi empresa no podemos usar claves GPG con más de 2 años de duración. Lo que te digo es que posiblemente no levantaría sospechas hasta mucho tiempo después porque nadie mira eso más allá de que aparezca el icono.

> Lo que te estoy contando es que no puede subir claves privadas a GitHub, por más que te empeñes en repetirlo.

No me empeño en nada porque no lo he dicho nunca. Se puede cambiar la clave privada como ya te he explicado un par de veces pero eso no quiere decir que la subas a GitHub.

[#38 Cuñado]

#34 Me explico: en un sistema de cifrado asimétrico (como GPG) la clave pública (que es la que almacenas en GitHub) debe ser lo más pública posible (yo p. ej. tengo la mía en un gist público en GitHub, la añado a los correos -incluso a los que van firmados-, etc.), ya que es lo que permite a cualquiera verificar que en realidad eres tú quien firma.

La clave privada, el passphrase en este caso, idealmente no debería estar almacenada más que en tu cabeza, ya que es lo que te permite a ti (y quien la tenga) firmar en tu nombre.

[#1 azenbugranto]

Parece que se ha descubierto a tiempo. Aunque el paquete infectado estaba en las últimas versiones, pocas distros aún lo habían preparado en sus repositorios.

[#2 Cuñado]

#1 Tanto como a tiempo... Un mes llevaba la vulnerabilidad en el repo (lo deshabilitaron ayer) y muchas distros ya lo habían empaquetado (todas las basadas en Debian Unstable o las rolling release, entre ellas).

Lo cierto es que no era sencillo de detectar, estaba muy bien ofuscado entre los tests.

[#5 pkreuzt]

#1 #2 Peor aún, el notas que añadió el troyano era uno de los desarrolladores principales de XZ y llevaba dos años trabajando ahí. En las distros están tirándose de los pelos porque no están del todo seguros de si las versiones anteriores podrían tener algún regalito ya de antes. Están pidiendo retirar todos sus commits, y GitHub hasta ha deshabilitado el repo.

[#10 Cuñado]

#5 De hecho era el segundo de a bordo. No dio señales de vida entre la detección y la suspensión de la cuenta, lo cual en sí mismo ya es sospechoso, pero tampoco se puede descartar que le hubiesen comprometido la cuenta y alterado el commit.

De hecho, en el comunicado oficial se afirma que los commits estaban firmados, pero no es cierto.

[#11 Cuñado]

#5 #10 Nah, olvídalo. Llevaba meses preparándolo...

github.com/google/oss-fuzz/pull/10667

[#53 Pablosky]

#11 Esto prácticamente prueba que era algo a largo plazo y muy bien pensado.

¿Será de la CIA el colega este? (o cualquier otro servicio secreto)

[#55 Cuñado]

#53 No lo descartaría en absoluto.

[#13 pkreuzt]

#10 Los commits siempre están autenticados, no puede ir cualquiera y añadir cosas a un repo sin permiso. Pero lo que va firmado (con las claves de cada desarrollador según el caso) son los archivos de release. Los tarballs, quiero decir. Lo que dice el comunicado es que las releases supervisadas por Collin llevan su firma, y las de Jia Tan llevan la de Tan.

[#44 santeloc]

#10 yo a ese le comprobaba las cuentas bancarias, especialmente los ingresos de los último meses, y de dónde proceden...

Igual nos llevamos una sorpresa.

[#12 azenbugranto]

#2 Sí, bueno, a tiempo de que se fuera de las manos.

[#15 Cuñado]

#12 Desde luego pudo ser peor. No llegó a distros empresariales, aunque sí a muchas distros de uso personal.

[#62 anthk]

#15 Las empresariales usan LTS por norma. Tampoco a Slackware salvo -current, pero la mayoría usa la 15. En Hyperbola tampoco.

[#49 frg]

#2 "Unstable", quida todo dicho. Solo los camicaces tienen esta distribución en producción.

[#57 Cuñado]

#49 Bueno, hay que tener en cuenta que los estándares de estabilidad de Debian son extremos En realidad es una rolling release, como puede ser Arch.

[#69 Olepoint]

#57 Las rolling release, como Manjaro (Arch) ya lo han parcheado, ayer mismo:

Me extrañó una actualización de solo dos componentes, suele pasar con los navegadores, pero no con utilidades.  

[#81 tommyx]

#49 kamikazes

[#84 frg]

#81 Pedante

[#86 tommyx]

#84 que problema tienes tú ? Se corrige un error e insultas?

[#48 Lito]

Novelón, lleva planeándose 2 años.

Aquí un resumen de lo que se va encontrando boehs.org/node/everything-i-know-about-the-xz-backdoor

Me parece una historia super interesante.

[#60 Lito]

#48 2 no, 3 años.

[#45 Nouser]

#31 En la NSA están seguros de que conocen ahora todos los backdoors de Windows, no dentro de unos años.

[#50 solojavi]

#45 Conocen los backdoors que han ordenado poner. Del resto no sabemos si tienen información o no

[#73 ostiayajoder]

#45 Al menos todos los q han puesto ellos.

[#42 BuckMulligan]

Gracias a Microsoft Linux es seguro

[#47 marcumen]

#42 de hecho el que encontró el código trabaja en Microsoft.

[#70 BuckMulligan]

#47 A eso me refería. Un desarrollador de Microsoft detectó una mayor latencia en los login SSH y decidió investigar. Gracias a Microsoft se ha descubierto el percal.
Probablemente un proyecto de espionaje a largo plazo de algún gobierno.
lcamtuf.substack.com/p/technologist-vs-spy-the-xz-backdoor

[#75 soberao]

#47 #70 No habría podido publicar nada de no ser código libre. Si fuera del código de Windows serían solo mensajes internos entre los que tienen acceso a esas partes del código cerrado.

[#54 psxe]

#42 Yo uso una Debian compilada por mí y no necesito usar antivirus.

Uso esta distro en vez de Windouze de Micro$oft, porque nunca está expuesta a vulnerabilidades y tiene todos todos los programas que necesito.

[#63 anthk]

Para evitar estas cosas está Guix que reproducible en extremo y en caso de problemas puedes hacer un rollback desde Grub. No es para novatos en absoluto pero para entornos científicos es imbatible.

[#67 frg]

#63 Entiendo que para usar Guix hay que utilizar el SO del mismo nombre. Le voy a dar un ojo. Gracias.

[#77 ofuquillo]

#76 Ups... Acabo de encontrar tu sentido del humor, ese que habías perdido... Te lo devuelvo.

[#66 ofuquillo]

A ver si al final este no va a ser el año de Linux...

[#76 anthk]

#66 Teniendo en cuenta que OpenSSH nace de OpenBSD y que éste no lo enlaza hacia xz, no puede haber comentario más metepata...

[#78 ecam]

#0 A ver si algún @admin te puede arreglar las etiquetas (quitar los #).

[#80 azenbugranto]

#78 Oopss... tenía oxidado el crear historias.

[#4 MPR]

#3 Precisamente un desarrollador cualquiera se dio cuenta del error y localizó el código erróneo porque es software libre, con Windows no habría podido hacerlo porque no tendría acceso al código.

[#85 provotector]

#4 Un desarrollador cualquiera no. Uno de Microsoft.

[#87 Nok1a]

#85 Pero eso no se dice que queda mal, igual que a #3 lo han cosido a negativos los fanatismos por los OS y softwares no los entiendo sinceramente, usa lo que te sirva y te vaya bien

[#6 blak]

#3 En Windows no es un bug, es un feature

[#7 mr._cortimer]

#3 El código malicioso lo puso uno de los desarrolladores, y además el código estaba ofuscado. Está claro esa persona tenía muy claro lo que quería hacer desde hace tiempo, no tiene nada que ver con software libre o software privativo, se trata básicamente de un hijoputa

[#17 mcfgdbbn3]

#7: Yo estoy convencido de que no existen "hackers que encuentran vulnerabilidades", sino organizaciones que cuelan este tipo de "bugs" (puertas traseras, #backdoors) en el código a propósito para explotarlas después.

¿Soluciones? Congelar el desarrollo de algunos productos cuando llegan a cierta versión, auditar bien el código por parte de diversas organizaciones y luego no empeñarse en usar la ultimísima versión, sino una versión congelada. Si una versión cumple con una determinada funcionalidad se puede usar sin problema. ¿Que intentan colar un fallo en el código? Cuando se haga la próxima congelación se podría ver al auditar el código.

[#29 UnoYDos]

#17 Si hay hackers que encuentran vulnerabilidades. Porque hay programadores que las generan. Muchas veces los programadores no están al tanto de las CVE publicadas recientemente. En mi trabajo nos pasamos un scanner que la gente de ciberseguridad mantiene al dia para ver si hemos liado alguna y corregirlo.

[#30 MoneyTalks]

#7 Los tentaculos de la CIA ..

[#71 ostiayajoder]

#7 LOL

Muy naif eso q dices....

Tu como crees q funcionan Pegasus y compañia?

A ese le han PAGADO durante 2 años para meter eso ahi.

Alguna empresa de defensa o algun pais. Y por el nombre de usuario apostaria a que NO era chino.

Apuesto por Israel o USA. O Rusia tal vez...

[#8 eldarel]

#3 Llega a pasar en Windows y lo detectan dentro de varios años.

[#31 tednsi]

#8 ¿Quién dice que no ha pasado en Windows? ¿La NSA?

[#72 ostiayajoder]

#8 En windows y en Mac los hay igual y nunca te vas a enterar.

[#79 tommyx]

#8 igual ya está pasando

[#16 perrico]

#3 Llega a ocurrir en Windows y se tira 2 años sin que nadie se entere.

[#43 Pablosky]

#16 Por no decir 20.

[#68 perrico]

#43 He puesto un tiempo al azar. Pero si. Pueden ser 20 o que no se detecte nunca.

[#24 anthk]

#3 Eso no ha pasado en distros LTS. Y OpenBSD no usa OpenSSH compilado contra xz.

[#33 prejudice]

#3 En Windows es posible que un backdoor no fuse algo a corregir si no parte del sprint
No en serio. Para mi es igual de grave que si lo mete en Windows o en Macos.
Si lo lleva a ofuscar mejor, nos lo comemos con patatas