Backdooring SSH
Un întreținător nefast sau compromis a introdus un comportament rău intenționat într-o bibliotecă numită liblzma, parte a instrumentelor și bibliotecilor de compresie xz, rezultând un backdoor în SSH. Acesta este un atac avansat asupra lanțului de aprovizionare software, deoarece biblioteca a fost modificată intenționat pentru backdoor, cu tehnici de ofuscare și stealth pentru a ascunde sarcina utilă a atacului de recenzori.
A fost descoperit și dezvăluit recent (pe 29 martie), iar gestionarea atacului este în curs de desfășurare. Cu toate acestea, a fost rapid controlat, deoarece pare să afecteze doar versiunile pre-lansare ale unui set limitat de medii (pachete DEB și RPM, pentru arhitectura x86_64 și construite cu GCC). În orice caz, CVE i s-a dat un Scorul de bază CVSS de 10, care este rezervat pentru cele mai critice vulnerabilități de securitate cibernetică. Dacă ar intra în distribuții stabile, impactul ar fi copleșitor.
Analiza tehnică a atacului, inclusiv Backdoor-ul xz explicat în detaliu, a fost analizat în altă parte. Această postare se va concentra pe cronologia atacului, cum a putut fi detectat, cum a fost gestionat incidentul până în prezent și ce lecții pot fi extrase din atac.
Coada lungă a backdoor-ului a continuat mult după patch-ul inițial. În august 2025, la peste un an după dezvăluirea CVE-2024-3094, cercetătorii în domeniul securității de la Binarly au descoperit că backdoor-ul era încă prezent într-o duzină de imagini Debian Docker publicate pe Docker Hub, echipa Debian refuzând să le elimine, tratându-le ca artefacte istorice de dezvoltare, mai degrabă decât ca risc activ. Separat, OpenSSF și OpenJS au emis un avertisment comun la scurt timp după incidentul XZ, conform căruia încercări similare de preluare prin inginerie socială au vizat deja proiecte JavaScript, sugerând că modelul de atac de tip „maintainer-trust” folosit aici este reutilizat în alte părți.
Cum a fost injectată ușa din spate XZ
Notă: Depozitul git se află în git.tukaani.org. Cu toate acestea, a existat și o Repozitoriu găzduit pe GitHub (blocat în prezent) unde contul GitHub posta modificările care au fost integrate ulterior în depozitul Git.
O porțiune a backdoor-ului pare să se afle doar în fișierele tar distribuite pentru versiunile 5.6.0 și 5.6.1, nu în repozitoriile git și se bazează pe un o singură linie în fișierul build-to-host.m4 fișier macro folosit de autoconf. Cealaltă porțiune se afla în două presupuse fișiere de test bad-3-corrupt_lzma2.xz și bun-large_compressed.lzma
care au fost commitTed de contul GitHub „Jia Tan” (JiaT75), În depozit xz pe 23 februarie. A fost o modificare inofensivă adăugarea de fișiere de test (se presupune că blocuri comprimate .lzma și .xz). Interesant este că fișierele de test nu au fost folosite de teste! Linia din fișierul .m4 injectează un script ofuscat (inclus în arhiva tar) care va fi executat la sfârșitul configurării dacă anumite condiții sunt îndeplinite. Modifică Makefile-ul pentru liblzma bibliotecă care conține cod ce extrage date din fișierul .xz, după ce deobfuscarea se termină în acest scenariu, este invocat la sfârșitul configurării. Decide dacă să modifice procesul de compilare pentru a injecta cod: numai sub GCC și linker-ul GCC, sub Debian sau rpm și numai pentru Linux x86_64. Când se potrivește, codul injectat interceptează execuția prin înlocuirea a două ifunc rezolveri, astfel încât anumite apeluri să fie înlocuite. Acest lucru determină analizarea tabelelor de simboluri în memorie (acest lucru necesită timp, ceea ce a dus la detectare, așa cum se explică mai târziu).
Apoi lucrurile devin interesante: backdoor-ul instalează un hook de audit în linker-ul dinamic, așteptând sosirea simbolului funcției RSA_public_decrypt, care este redirecționat către un punct din codul backdoor-ului, care la rândul său apelează înapoi. libcrypto, probabil pentru a efectua autentificarea normală. Și sarcina utilă se activează dacă programul care rulează are numele procesului /usr/sbin/sshdEra clar că serverele SSH erau ținta. În mod tradițional, ssh serverele precum OpenSSH nu erau conectate cu liblzma, dar sshd este adesea cârpit pentru a suporta systemd-notify, astfel încât alte servicii să poată porni atunci când sshd rulează. Apoi, liblzma este încărcat indirect de systemd, închizând cercul.
Ușa din spate nu este încă analizată complet, dar se pare că este... permite executarea comenzilor la distanță (RCE) cu privilegiile daemonului sshd, rulând într-un context de pre-autentificare. Informațiile de la certificatul la distanță, atunci când sunt găsite de backdoor, sunt decriptate cu ChaCha20, iar când decriptarea este reușită, sunt transmise către sistem()Deci, în esență, acesta este un RCE cu porți, mult mai rău decât o simplă ocolire a cheii publice.
O versiune tar ulterioară, versiunea 5.6.1, a arătat eforturi suplimentare pentru ascunderea urmelor, adăugând o ofuscare suplimentară pentru numele simbolurilor și încercând să corecteze erorile observate. mecanism de extensie unde s-au căutat fișiere de testare suplimentare pentru anumite semnături care să fie adăugate la backdoor, au fost implementate și ele.
Acest atac destul de sofisticat ar putea trece neobservat până când se vor obține distribuții Linux stabile. Din fericire, unora le place să verifice de ce se întâmplă lucruri anormale.
Descoperirea atacului de tip backdoor XZ
De multe ori, comportamentul rău intenționat injectat este descoperit din întâmplare sau accidental. Un bun exemplu a fost un avertisment de perimare („Cui îi pasă de avertismente?”) care a dus la descoperirea atac de flux de evenimente în octombrie 2018. Un altul este utilizatorul care a avertizat Codecov în aprilie 2021 că scriptul lor de încărcare bash nu a trecut suma de control („Cine verifică integritatea artefactelor cu sume de control”?) Anomalii și simptome ciudate cu ssh logins (loginconsumă mult CPU și crește timpul scurs, erorile Valgrind) au stârnit curiozitatea Andres Freund, un dezvoltator PostgreSQL vigilent, dar nu un analist de securitate (așa cum a declarat el)). După niște investigații cu OpenSSH pe Debian Sid, a ajuns la concluzia că o problemă a timpului de răspuns se baza pe o bibliotecă, liblzma, O parte din xz-utils bibliotecă de compresie. Motivul: „depozitul xz upstream și fișierele tarball xz au fost accesate prin backdoor„Acest diagnostic a fost atât de precis!” Pe 29 martie 2024, Andres a postat pe Openwall prima analiză: „backdoor în upstream xz/liblzma care duce la compromiterea serverului ssh„Cert: Fișierele tar ale versiunilor 5.6.0 și 5.6.1 ale XZ Utils conțin un backdoor. Aceste fișiere tar au fost create și semnate de contul Jia Tan menționat anterior. He postat în Mastodon mai târziu în acea zi, recunoscând că descoperirea a fost accidentală și a necesitat multe coincidențe. Comentariile altor utilizatori merită citite. utilizator GitHub același (alias Sam James) a publicat un Gist frumos Întrebări frecvente despre backdoor-ul xz-utils unde a fost rezumat atacul, făcând legătura cu mai multe analize aprofundate a sarcinii utile a atacului. Aceste analize au fost interesante din punct de vedere tehnic și ne-au ajutat să înțelegem mai bine injecția, care a fost foarte elaborată:- xz/liblzma: Explicația ofuscării în etapa BashO analiză frumoasă a deofuscării prin scriptul de injectare, în patru „etape”.
- Firul de discuție despre cerul albastru al lui Filippo Valsorda Analiza backdoor-ului în sine în RSA_public_decrypt, care arată natura sa: un RCE, nu ocolirea autentificării, și blocat (acceptă cheia privată a autorului și dacă nu, revine la comportamentul normal) / nerambursabil. Autorul a intenționat să fie discret pentru a evita detectarea!
- Analiza backdoor-ului XZ de către @smx-smx (în curs de desfășurare) – Analiză suplimentară a backdoor-ului (m-am rătăcit aproape la început 😀)
- Documentație wiki pentru backdoor-ul xz, o altă analiză a scriptului de injectare 5.6.1.
Cum a fost gestionat incidentul
Dezvăluirea făcută de Andreas Freund a fost prudentă deoarece, în propriile sale cuvinte:„Având în vedere implicarea aparentă a sistemului upstream, nu am raportat o eroare în sistemul upstream. Deoarece inițial am crezut că este o problemă specifică Debian, am trimis un raport mai preliminar la security@...ian.org. Ulterior, am raportat problema la distros@.” CISA a fost notificat de o distribuție.”
Cine este atacat?
Fie contul GitHub JiaT75 a fost compromis (amintiți-vă că GitHub a impus recent 2FA), fie utilizatorul fizic care deținea contul a trecut de partea întunecată. Există însă motive convingătoare să ne gândim la o amenințare persistentă avansată (APT), probabil susținută de stat, datorită sofisticării tehnice a atacului. Investigațiile suplimentare efectuate de agențiile de securitate cibernetică și de forțele de ordine vor spune... Această intrare Știri despre Jia Tan în YCombinator Hacker Aruncă puțină lumină asupra „cine” și a activității sale. Recomandat! Oferă multe informații despre cum răufăcătorii încearcă să înșele alți utilizatori, folosind ingineria socială.„Foarte enervant - autorul aparent al backdoor-ului a comunicat cu mine (rwmj) timp de câteva săptămâni, încercând să adauge xz 5.6.x la Fedora 40 și 41 datorită «noilor sale caracteristici grozave». Am lucrat chiar și cu el pentru a remedia problema valgrind (care se pare că acum a fost cauzată de backdoor-ul pe care îl adăugase). A trebuit să ne grăbim aseară să remediem problema după o încălcare accidentală a embargoului. El face parte din proiectul xz de 2 ani, adăugând tot felul de fișiere binare de testare și, ca să fiu sincer, cu acest nivel de sofisticare, aș fi suspicios față de versiunile chiar mai vechi de xz până la proba contrarie.”
Jia Tan a luat măsuri pentru a preveni urmărirea: Se pare că a folosit VPN (vpn.singapore.witopia.net) pentru conectare – ceea ce este în regulă în sine. Și multe modificări par a fi susținute de e-mailuri temporale, de unică folosință (de la ProtonMail în acest caz) care îndeamnă la îmbinarea modificărilor.
Actorul ar putea intenționa să meargă și mai adânc, până la kernelul Linux, în calitate de contribuitor la xy-încorporat proiect. O analiză inițială nu a găsit nicio dovadă de avort spontan, până în prezent.
Notă: o altă colaborator discret la XZ, „Hans Jansen“ (Utilizatorul GitHub „hansjans162”) este sub controlContul său la Debian este acum blocatA făcut multe actualizări la Debian Games pentru a-l ascunde pe cel pe care îl dorea pe debian/xz-utils, o actualizare la upstream 5.6.1 pentru a grăbi distribuirea backdoor-ului către debian/unstable.
Tot ce putem spune, deocamdată, este că acesta este un APT (încă neidentificat) care folosește conturi diferite, care lucrează de cel puțin doi ani la această campanie și lucrează cu răbdare la implantarea unui RCE în SSH.
În momentul scrierii acestui articol, identitatea din spatele personajului „Jia Tan” rămâne neconfirmată. Nicio atribuire credibilă către o anumită persoană, organizație sau actor statal nu a fost verificată public, ceea ce întărește cât de eficientă a fost disciplina operațională a personajului.
Atacul backdoor XZ putea fi prevenit?
Destul de dificil.
În primul rând, o parte din backdoor-ul injectat a ajuns în fișiere de testare comprimate care nu au fost folosite de teste. Retrospectiv, acest lucru ar putea declanșa unele alarme (zgomotoase), dar cui îi pasă să verifice dacă toate fișierele de testare sunt utilizate de testele reale în lumea reală? În al doilea rând, o parte din backdoor-ul injectat a ajuns în fișiere macro în fișierele tarball ale versiunii și este dificil să verifici manual diferențele față de fișierele tarball așteptate. Automatizarea este, de asemenea, complexă, deoarece rezultatul așteptat din compilarea în sine (pentru oricine știe cum funcționează automake/autoconf) este dificil de modelat pentru a analiza dacă tarball-ul real corespunde așteptărilor. Unii au pus-o pe gânduri as „Nepotrivirea fișierelor tar din arborele git este o funcționalitate, nu o eroare”Proveniența fișierelor tar binare din codul sursă este o problemă nerezolvată.
Reputația utilizatorului? Ei bine, contul GitHub JiaTan75 nu făcea lucruri necinstite, conform trecutului. commitA fost suspendată doar după acumularea dovezilor, dar până pe 29 martie era vorba de un utilizator obișnuit care își desfășura activitatea normală. Ei bine, nu chiar atât de normal. Mai târziu commits (acest, acest, acest și acest care a ajustat codul exploit-ului) a încercat să remedieze erorile și blocările valgrind în anumite configurații, din cauza diferențelor față de aspectul stivei așteptat de backdoor. Commit Recenziile ar putea detecta acest lucru, dar cine are răbdarea să analizeze modificările dintr-un fișier binar de test sau motivația reală pentru o modificare a atributelor GCC în codul sursă C?
Ar trebui să se declanșeze alarma atunci când se utilizează un SSH? login durează 800 ms în loc de 300 ms? Probabil că doar oamenii hiperprudenți ar lua în considerare. Cicero a spus, „Nebunia aparține tinereții; prudența bătrâneții.”
Infrastructura ifunc a fost adăugată în iunie 2023 de „Hans Jansen” și „Jia Tan”. Aceasta este prima commit adăugarea suportului ifunc la crc64_fast.c (folosit ulterior pentru injectarea backdoor-ului). Cu luni înainte de injectarea binarelor backdoor în fișierele de test!
Notă: Autorul și commitExistă divergențe aici, dar acest lucru este normal: Lasse Collin este responsabilul cu întreținerea proiectului și el a integrat modificările. El chiar îi mulțumește lui „Hans Jansen”...
Nimeni nu și-a exprimat îngrijorarea înainte de postarea lui Andres Freund și de CVE-ul creat de RedHat. Dacă vedeți o cascadă de instrumente care ar detecta acest lucru, acestea detectează acum componenta afectată. ex post facto.
Probabil cea mai bună prevenție a provenit din natura distribuțiilor Linux și din modul în care versiunile instabile, de ultimă generație, trec la distribuțiile stabile în aval doar în urma unui proces ritmat.
Lecții învățate din atacul XZ bBackdoor
Am observat cât de dificil este de detectat intenționat backdoor-uri. Backdoor-urile ar trebui considerate o amenințare internă, deoarece sunt implantate de personal intern sau prin intermediul conturilor interne compromise. Iar acești tipi sunt în mare parte de încredere. Iar atunci când backdoor-ul este implantat în artefactul distribuit, este mai greu de detectat.
Unii autori precum Kevin Beaumont arătat spre sistem, ceea ce deschide o suprafață extinsă de atac a serviciilor terțe către backdoor-uri. Acesta este motivul pentru care actorul rău intenționat a abuzat aici. Systemd are multe priviri, dar XZ este o bibliotecă obscură în amonte. „Când partea din amonte este contaminată, toată lumea bea apă otrăvită din aval”.
O cerere de modificare fără legătură în sistem pentru încărcarea dinamică a bibliotecilor de compresie, care ar elimina backdoor-ul, a fost deja integrat în sistem, dar nu a fost încă livrat. Dependențele suplimentare introduse de libsystemd ar putea fi sursa vulnerabilităților., și ieri această cerere a fost deschisă.
A comentariu în „xz: Dezactivați ifunc pentru a remedia problema” commit a oferit o perspectivă clară asupra locului unde să ne concentrăm atenția dacă vrem să prevenim o astfel de activitate (sublinierea îmi aparține):
„Lecția pe care ar trebui să o învățăm ca și comunitate este mai degrabă să asigurăm software supply chain security „în mod holistic, auditarea sistemelor de construire dincolo de codul sursă. Cum ar fi breșa de securitate SolarWinds, unde atacatorii au modificat actualizările de software pentru oferta de software de monitorizare cu sursă închisă SolarWinds.”
FAQ
Este backdoor-ul XZ încă un risc astăzi?
În mare parte controlat, dar nu dispărut complet. În august 2025, cercetătorii au descoperit că backdoor-ul era încă prezent în mai multe imagini Debian Docker Hub, tratate de Debian ca artefacte istorice inactive. Echipele ar trebui să verifice dacă nu construiesc pe imagini de bază învechite, nepachetate, în loc să presupună că patch-ul din 2024 a închis complet ușa.
