SSH de porta enrere
Un mantenidor nefast o compromès va inserir un comportament maliciós en una biblioteca anomenada lliblzma, part de les eines i biblioteques de compressió xz, cosa que ha provocat una porta del darrere a SSH. Es tracta d'un atac avançat a la cadena de subministrament de programari, ja que la biblioteca es va modificar intencionadament per a la porta del darrere, amb tècniques d'ofuscació i ocultació per ocultar la càrrega útil de l'atac als revisors.
Va ser descobert i divulgat recentment (el passat 29 de març) i la gestió de l'atac està en curs. Tanmateix, va ser contingut ràpidament, ja que sembla que només afecta les versions preliminars d'un conjunt limitat d'entorns (paquets DEB i RPM, per a l'arquitectura x86_64 i construïts amb GCC). De totes maneres, el CVE se li va donar un Puntuació base del CVSS de 10, que està reservat per a les vulnerabilitats de ciberseguretat més crítiques. Si entrés a distribucions estables, l'impacte seria aclaparador.
L'anàlisi tècnica de l'atac, incloent-hi la Explicació detallada de la porta del darrere xz, es va analitzar en un altre lloc. Aquesta publicació se centrarà en la cronologia de l'atac, com es va poder detectar, com es va gestionar l'incident fins ara i quines lliçons es poden extreure de l'atac.
La llarga cua de la porta del darrere ha continuat molt més enllà del pegat inicial. L'agost de 2025, més d'un any després que es divulgués la CVE-2024-3094, investigadors de seguretat de Binarly van trobar que la porta del darrere encara era present en una dotzena d'imatges de Debian Docker publicades a Docker Hub, i l'equip de Debian es va negar a eliminar-les, tractant-les com a artefactes de desenvolupament històric en lloc de risc actiu. Per separat, OpenSSF i OpenJS van emetre un avís conjunt poc després de l'incident de XZ que intents similars de presa de control d'enginyeria social ja havien atacat projectes de JavaScript, cosa que suggereix que el patró d'atac de confiança del mantenidor utilitzat aquí s'està reutilitzant en altres llocs.
Com es va injectar la porta del darrere XZ
Nota: El repositori git es troba a git.tukaani.org. No obstant això, també hi havia un Repositori allotjat a GitHub (actualment bloquejat) on el compte de GitHub publicava els canvis que posteriorment es van integrar al repositori de Git.
Una part de la porta del darrere sembla que només es troba als fitxers tar distribuïts de les versions 5.6.0 i 5.6.1, no als repositoris git, i depèn d'un una sola línia al fitxer build-to-host.m4 fitxer de macro utilitzat per l'autoconf. L'altra part estava en dos suposats fitxers de prova bad-3-corrupt_lzma2.xz i bon-gran_comprimit.lzma
això era committed pel compte de GitHub «Jia Tan» (JiaT75) Al repositori xz el 23 de febrer. Va ser un canvi inocu afegir fitxers de prova (suposadament blocs comprimits .lzma i .xz). Curiosament, els fitxers de prova no van ser utilitzats per les proves! La línia del fitxer .m4 injecta un script ofuscat (inclòs al tarball) que s'executarà al final de la configuració si coincideixen algunes condicions. Modifica el Makefile per a la lliblzma biblioteca per contenir codi que extreu dades del fitxer .xz, que després de la desofuscació finalitza en aquest guió, s'invoca al final de la configuració. Decideix si cal modificar el procés de compilació per injectar codi: només sota GCC i l'enllaçador GCC, sota Debian o rpm, i només per a Linux x86_64. Quan coincideix, el codi injectat intercepta l'execució substituint dos ifunc resolutors de manera que certes crides siguin substituïdes. Això fa que les taules de símbols s'analitzin a la memòria (això requereix temps, cosa que va conduir a la detecció, com s'explica més endavant).
Aleshores les coses es tornen interessants: la porta del darrere instal·la un ganxo d'auditoria a l'enllaçador dinàmic, esperant que arribi el símbol de la funció RSA_public_decrypt, que es redirigeix a un punt del codi de la porta del darrere, que al seu torn fa una crida. libcrypto, presumiblement per realitzar l'autenticació normal. I la càrrega útil s'activa si el programa en execució té el nom del procés /usr/sbin/sshdEra clar que l'objectiu eren els servidors SSH. Tradicionalment, sshd servidors com OpenSSH no estaven enllaçats amb lliblzma, però sshd és sovint pegat per donar suport a systemd-notify perquè altres serveis puguin iniciar-se quan sshd s'està executant. I després liblzma es carrega indirectament per systemd, tancant el cercle.
La porta del darrere encara no s'ha analitzat completament, però sembla que sí. permetent l'execució remota d'ordres (RCE) amb els privilegis del dimoni sshd, executant-se en un context de preautenticació. La informació del certificat remot, quan coincideix amb la porta del darrere, es desxifra amb ChaCha20, i quan es desxifra correctament es passa a sistema()Així doncs, això és essencialment un RCE amb portes, molt pitjor que una simple derivació de clau pública.
Un tarball 5.6.1 posterior va mostrar esforços addicionals per ocultar els rastres, afegint més ofuscació als noms de símbols i intentant corregir els errors observats. Un mecanisme d'extensió on també es van buscar fitxers de prova addicionals per a certes signatures per afegir a la porta del darrere.
Aquest atac força sofisticat podria passar desapercebut fins que s'aconsegueixin distribucions de Linux estables. Afortunadament, a algunes persones els agrada comprovar per què passen coses anormals.
El descobriment de l'atac de la porta del darrere de XZ
Moltes vegades, el comportament maliciós injectat es descobreix per casualitat o accident. Un bon exemple va ser un avís de desaprovació (“A qui li importen els avisos?”) que va conduir al descobriment de la atac de flux d'esdeveniments a l'octubre de 2018. Un altre és l'usuari que va advertir Codecov l'abril de 2021 que el seu script de pujada de bash no passava la suma de verificació ("Qui verifica la integritat dels artefactes amb sumes de verificació"?) Anomalies i símptomes estranys amb ssh login(loginconsumint molta CPU i augmentant el temps transcorregut, errors de Valgrind) van despertar la curiositat de Andrés Freund, un desenvolupador de PostgreSQL vigilant però no un analista de seguretat (com va afirmar). Després d'una investigació amb OpenSSH a Debian Sid, va concloure que un problema de temps de resposta depenia d'una biblioteca, lliblzma, Part de la xz-utils biblioteca de compressió. El motiu: “El repositori xz aigües amunt i els fitxers tar de xz han estat objecte d'una porta posterior.". Aquest diagnòstic va ser tan precís! El 29 de març de 2024, l'Andrés va publicar a Openwall la primera anàlisi: «porta del darrere a xz/liblzma aigües amunt que ha compromès el servidor ssh". El fet: els fitxers tar de XZ Utils 5.6.0 i 5.6.1 contenen una porta del darrere. Aquests fitxers tar van ser creats i signats pel compte Jia Tan esmentat anteriorment. He publicat a Mastodon més tard aquell mateix dia, reconeixent que el descobriment va ser accidental i va requerir moltes coincidències. Val la pena llegir els comentaris d'altres usuaris. Usuari de GitHub thèmesam (també conegut com Sam James) va publicar un bon Gist Preguntes freqüents sobre la porta del darrere xz-utils on es va resumir l'atac, enllaçant amb més anàlisis en profunditat de la càrrega útil de l'atac. Aquestes anàlisis van ser tècnicament sucoses i ens van ajudar a entendre millor la injecció, que era molt elaborada:- xz/liblzma: Explicació de l'ofuscació a la fase BashBona anàlisi sobre la desofuscació mitjançant l'script d'injecció, en quatre "etapes".
- Fil de cel blau de Filippo Valsorda Anàlisi de la porta del darrere a RSA_public_decrypt, que mostra la seva naturalesa: un RCE, no una omissió d'autenticació, i bloquejada (accepta la clau privada de l'autor i si no, torna al comportament normal) / no reemborsable. L'autor tenia la intenció de passar desapercebut per evitar ser detectat!
- Anàlisi de la porta posterior de XZ per @smx-smx (en curs) – Anàlisi addicional de la porta del darrere (gairebé m'he perdut al principi 😀)
- wiki de documentació de la porta del darrere xz, una altra anàlisi de l'script d'injecció 5.6.1.
Com es va gestionar l'incident
La revelació d'Andreas Freund va ser cautelosa perquè, en les seves pròpies paraules:"Donada la suposada implicació del programa original, no he informat d'un error del programa original. Com que inicialment vaig pensar que era un problema específic de Debian, vaig enviar un informe més preliminar a security@...ian.org. Posteriorment, vaig informar del problema a distros@." CISA va ser notificat per una distribució.
Qui està sota l'atac?
O bé el compte JiaT75 de GitHub va ser compromès (recordeu que GitHub va ordenar l'autenticació a dues façes recentment) o bé l'usuari físic propietari del compte va passar al costat fosc. Però hi ha raons de pes per pensar en una amenaça persistent avançada (APT), potser recolzada per l'estat, a causa de la sofisticació tècnica de l'atac. Una investigació més detallada per part de les agències de ciberseguretat i les forces de l'ordre ho dirà... Aquesta entrada a Notícies de pirates informàtics d'YCombinator sobre Jia Tan Aclareix el "qui" i la seva activitat. Recomanat! Dóna molta informació sobre com els delinqüents intenten enganyar altres usuaris mitjançant l'enginyeria social.«Molt molest: l'autor aparent de la porta del darrere va estar en comunicació amb mi (rwmj) durant diverses setmanes intentant afegir xz 5.6.x a Fedora 40 i 41 per les seves "noves funcions fantàstiques". Fins i tot vam treballar amb ell per solucionar el problema de valgrind (que ara resulta que era causat per la porta del darrere que havia afegit). Vam haver de córrer ahir a la nit per solucionar el problema després d'una ruptura accidental de l'embargament. Ha format part del projecte xz durant 2 anys, afegint tot tipus de fitxers binaris de prova i, per ser sincer amb aquest nivell de sofisticació, sospitaria de versions encara més antigues de xz fins que es demostri el contrari.»
Jia Tan va prendre mesures per evitar que el rastregessin: sembla que va utilitzar una VPN (vpn.singapore.witopia.net) per connectar-se, cosa que per se està bé. I molts canvis semblen estar recolzats per correus electrònics temporals d'un sol ús (de ProtonMail en aquest cas) que insten a fusionar els canvis.
L'actor podria tenir la intenció d'anar encara més enllà, fins al nucli de Linux, com a contribuïdor a la xy-incrustat projecte. Una anàlisi inicial no va trobar cap evidència d'avortament espontani, fins avui.
Nota: una altra col·laborador de baix perfil de XZ, "Hans Jansen", (L'usuari de GitHub "hansjans162") és sota escrutiniEl seu compte a Debian ara és obstruïtVa fer moltes actualitzacions a Debian Games per ocultar el que volia a debian/xz-utils, una actualització a la versió 5.6.1 d'UPWINE per accelerar la distribució de la porta del darrere a debian/inestable.
Tot el que podem dir, de moment, és que es tracta d'un APT (encara no identificat) que utilitza comptes diferents, que treballa durant almenys dos anys en aquesta campanya i que treballa pacientment per implantar un RCE a SSH.
En el moment d'escriure aquest article, la identitat darrere de "Jia Tan" continua sense confirmar-se. No s'ha verificat públicament cap atribució creïble a un individu, organització o actor estatal específic, cosa que reforça l'efectivitat de la disciplina operativa de la persona.
Es podia prevenir l'atac de la porta del darrere de XZ?
Bastant difícil.
Primer, part de la porta del darrere injectada va arribar a fitxers de prova comprimits que no van ser utilitzats per les proves. Retrospectivament, això podria generar algunes alarmes (sorolloses), però a qui li importa comprovar que tots els fitxers de prova siguin utilitzats per proves reals al món real? En segon lloc, part de la porta del darrere injectada va arribar a fitxers macro als fitxers tar de llançament, i és difícil comprovar manualment si hi ha diferències amb els fitxers tar esperats. L'automatització també és complexa, ja que el resultat esperat de la pròpia compilació (per a qualsevol que sàpiga com funciona automake/autoconf) és difícil de modelar per analitzar si el fitxer tar real coincideix amb les expectatives. Alguns ho van plantejar as «El fet que els fitxers tar no coincideixin amb l'arbre de git és una característica, no un error»La procedència dels fitxers tar binaris a partir del seu codi font és un problema sense resoldre.
Reputació de l'usuari? Doncs bé, el compte de GitHub de JiaTan75 no feia coses fraudulentes segons el passat. commits. Només es va suspendre després que s'acumulessin proves, però fins al 29 de març era un usuari habitual que feia la seva feina amb normalitat. Bé, no tan normal. Més tard commit(aquest, aquest, aquesti aquest que ajustava el codi de l'exploit) va intentar corregir els errors i els bloquejos de valgrind en algunes configuracions, a causa de diferències amb la disposició de la pila esperada per la porta del darrere. Commit Les revisions podrien detectar-ho, però qui té la paciència d'analitzar els canvis en un fitxer de prova binari o la motivació real d'un canvi en els atributs de GCC en el codi font C?
S'hauria de fer sonar l'alarma quan s'utilitza un SSH? login triga 800 ms en comptes de 300 ms? Probablement només la gent hiperprudent ho tindria en compte. Ciceró va dir, "La temeritat pertany a la joventut; la prudència a la vellesa."
La infraestructura ifunc va ser afegida el juny de 2023 per "Hans Jansen" i "Jia Tan". Aquesta és la primera commit afegint la compatibilitat amb ifunc a crc64_fast.c (que més tard s'utilitzarà per injectar la porta del darrere). Mesos abans d'injectar els binaris de la porta del darrere als fitxers de prova!
Nota: Autor i commitaquí hi ha diferències, però això és normal: Lasse Collin és el mantenidor del projecte i ell va fusionar els canvis. Fins i tot agraeix a "Hans Jansen"...
Ningú va plantejar preocupacions abans de la publicació d'Andres Freund i el CVE creat per RedHat. Si veieu una cascada d'eines que ho detecten, ara detecten el component afectat. ex post facto.
Probablement la millor prevenció va provenir de la naturalesa de les distribucions de Linux i de com les versions inestables i innovadores només passen a les distribucions estables posteriors seguint un procés accelerat.
Lliçons apreses de l'atac de porta posterior de XZ
Hem observat la dificultat de detectar intencional portes del darrere. Les portes del darrere s'han de considerar una amenaça interna, ja que les instal·la personal intern o a través de comptes interns compromesos. I en la seva majoria es confia en aquests individus. I quan la porta del darrere s'implanta a l'artefacte distribuït, fa que sigui més difícil de detectar.
Alguns autors com Kevin Beaumont apuntat eOS®, que obre una gran superfície d'atac de serveis de tercers a portes enrere. Això és del que ha abusat el mal actor aquí. Systemd té molts ulls, però XZ és una biblioteca obscura a la cadena. "Quan el riu amunt està contaminat, tothom beu aigua enverinada aigües avall".
Una sol·licitud de canvi no relacionada al sistema per a càrrega dinàmica de biblioteques de compressió, que eliminaria la porta del darrere, ja s'havia incorporat al sistema però encara no s'havia lliurat. Les dependències addicionals introduïdes per libsystemd poden ser la font de vulnerabilitats., i ahir aquesta sol·licitud es va obrir.
A comment a "xz: Desactiva ifunc per solucionar el problema" commit va donar una idea clara sobre on cal centrar-se si volem evitar aquesta activitat (l'èmfasi és meu):
"La lliçó que hauríem d'aprendre com a comunitat és més aviat assegurar software supply chain security de manera holística, auditant els sistemes de compilació més enllà del codi font. Com la bretxa de SolarWinds on els atacants van modificar les actualitzacions de programari per a l'oferta de programari de monitorització de codi tancat de SolarWinds.
FAQ
La porta del darrere XZ encara és un risc avui dia?
Principalment contingut, però no completament desaparegut. A l'agost de 2025, els investigadors van trobar que la porta del darrere encara era present en diverses imatges de Debian Docker Hub, tractades per Debian com a artefactes històrics inactius. Els equips haurien de verificar que no estan construint sobre imatges base obsoletes i sense pegats en lloc de suposar que el pegat del 2024 va tancar completament la porta.
