Attenzione: NO PANIC, è molto probabile che i vostri sistemi "GNU/Linux" non siano affetti da questa backdoor in XZ (ora risolta): per saperlo, iscrivetevi, se non lo siete già, alla newsletter di sicurezza della distribuzione che state utilizzando (o rivolgetevi a un professionista).
Buongiorno, per diversi giorni il mio alter ego si è occupato con una certa _apprensione_ di questa vicenda, ora per fortuna l'apprensione sta scemando e può lavorare con più calma alle misure per mitigare questi rischi... e lasciarmi scrivere qui in merito. Qualcuno in lista almeno ne avrà sentito palare ma forse la maggior parte ancora non sa che il 29 Marzo 2024 è stato scoperto il peggior supply chain attack ad oggi conosciuto. La vulnerabilità è tecnicamente conosciuta come CVE-2024-3094 e il NIST gli assegna un punteggio di 10 (su 10), ma potrebbe benissimo essere 10 cum laude: https://nvd.nist.gov/vuln/detail/CVE-2024-3094 I dettagli tecnici e _sistemistici_ sono relativamente (poco) complessi e NON trascurabili per poter avere una chiara e precisa comprensione del /modus vivendi/ ma soprattutto del /modus operandi/ che ha reso possibile questo attacco... "nucleare". In merito si stanno scrivendo fiumi di parole, molte delle quali a sproposito, anche da parte di "esperti del settore", come purtroppo accade quando si tratta di "cose complesse" (non complicate!) di informatica ;-(. In questa prima parte, come /introduzione/ alla questione vi consiglio un articolo che ritengo meritevole. Prima però voglio sottolineare una opportuna quanto agghiacciante considerazione di Bruce Schneier: https://www.schneier.com/blog/archives/2024/04/xz-utils-backdoor.html --8<---------------cut here---------------start------------->8--- Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. --8<---------------cut here---------------end--------------->8--- e una totalmente inopportuna e altrettanto superficiale: --8<---------------cut here---------------start------------->8--- We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone unpaid distracted—or worse—individuals. --8<---------------cut here---------------end--------------->8--- Ecco finalmente l'articolo introduttivo: https://www.insicurezzadigitale.com/backdoor-su-xz-il-problema-e-molto-piu-grande-non-e-lopen-source-e-non-si-risolve-con-un-aggiornamento-una-storia-incredibile/ «Backdoor su Xz: il problema è molto più grande, non è l'open source e non si risolve con un aggiornamento. Una storia incredibile» Dario Fadda, 2024-04-11 --8<---------------cut here---------------start------------->8--- Mondo Linux in allarme da alcuni giorni, grande eco per la vulnerabilità rilevata su Xz il 29 marzo appena passato. Una backdoor installata sul codice open source della libreria largamente utilizzata per la compressione di dati che utilizza l'algoritmo [lzma], che *permette di eseguire codice da remoto su un server SSH* senza averne l'autenticazione. Questi sono i fatti, ma il contenuto di questo articolo vuole rispondere ad altre domande che sorgono naturalmente: come fa una utility di compressione ad agire su SSH? Chi ha installato questa backdoor e come ci è riuscito? Proviamo a vederci chiaro, ma di sicuro premetto che le favolette dell'instabilità di un progetto open source e dell'hacker annoiato nella propria stanza, non reggono. [lzma] <https://it.wikipedia.org/wiki/Algoritmo_Lempel-Ziv-Markov> Come funziona la backdoor su Xz? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Non mi dilungherò in analisi dettagliate e tecniche sul funzionamento di questa backdoor, già ampiamente dibattute ([qui] e [qui]), ma giusto due righe per chiarirne il concetto base. Vista l'efficienza della libreria Xz, è da sempre utilizzata da molti altri software che necessitano di effettuare compressione dati (soprattutto nella gestione dei loro pacchetti). Tra gli utilizzatori c'è pure OpenSSH, il software più utilizzato per effettuare connessioni sicure tra client e server (gestire da remoto la shell, quindi la completa amministrazione, di un computer disposto altrove) via SSH. Il pacchetto OpenSSH non ha però la diretta dipendenza della libreria Xz. Qui dobbiamo prestare attenzione a questo passaggio, perché è il primo punto di complicazione di *come è stato congegnato l'atterraggio verso SSH* /senza farsi beccare/: OpenSSH ha una funzionalità di notifica sui sistemi operativi che utilizzano *SystemD* che è governata da una libreria “libsystemd” che a sua volta utilizza una seconda libreria che si chiama “liblzma” che è parte del progetto Xz! Un bel giro, per iniettare del codice malevolo ed arrivare a destinazione, sicuramente niente di /fatto in casa/. [qui] <https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27> [qui] <https://gynvael.coldwind.pl/?lang=en&id=782> Come è stato possibile? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ La backdoor Xz è stata la parte finale di una campagna durata due anni di attività, *si tratta di operazioni di human intelligence* molto elaborate e che richiedono tempo e persone. Due anni di /lavoro/ per avere una backdoor aperta circa tre settimane prima che venga rilevata. C'è stato un approccio che è durato mesi prima che il *personaggio di Jia Tan* (JiaT75 questo lo pseudonimo di chi ha diffuso il codice malevolo all'interno del progetto Xz originale) fosse ben posizionato per ricevere un ruolo di fiducia nel progetto, da parte di chi segue la manutenzione diretta ( /Lasse Collin/ è invece il suo nome). L'account su GitHub di *Jia Tan viene registrato nel 2021*. Non opererà però subito su Xz, ma inizia scrivendo un commit per un altro pacchetto open source “libarchive”. Con questo commit aggiunge una vulnerabilità pure li che nessuno discute mai e che quindi, ad oggi potrebbe far considerare *non sicuro pure libarchive*. In sintesi, Jia Tan e altri attori hanno lavorato per introdurre una backdoor nel progetto XZ, utilizzando varie tattiche per aumentare il controllo sul progetto e cercando di far includere la versione compromessa in diverse distribuzioni di Linux. La storia ╌╌╌╌╌╌╌╌╌ Subito dopo i fatti del 2021 appena descritti è un susseguirsi di attività che portano fino ai giorni attuali. [...] La gravità ╌╌╌╌╌╌╌╌╌╌╌ Da come si sono articolati gli eventi, possiamo comprendere bene la gravità della situazione e di come l'organizzazione dietro questo attacco, sia enormemente organizzata. Va ricordato che la versione vulnerabile di Xz è rimasta operativa per [tre settimane] circa (dal 9 marzo 2024), in ogni caso è plausibile che gli sforzi di questi due anni per condurre l'operazione, mirino ai ritardi negli aggiornamenti, prima che tutti i sistemi coinvolti (vista la diffusione dello strumento Xz), vengano raggiunti dagli aggiornamenti necessari per sanare il problema. Il modus operandi di questa cronologia di eventi, è il tipico stile di operazione di human intelligence che punta a *sconvolgere il bersaglio* (Lasse Collin, mantenitore del progetto), dal punto di vista psicologico (capendo su che leve operare): ecco cosa scrive Lasse in una mailing-list nel 2022 quando aumentavano le pressioni per far aggiungere un altro contributore al progetto Xz. [immagine del messaggio: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html] Sottolinei un problema che qualcuno non è in grado di risolvere, ti fai spalleggiare da altri utenti (finti, della tua organizzazione malevola), e ti rendi disponibile a risolverlo. È il modo migliore per entrare nella cerchia della fiducia, di un debole preso dallo sconforto per mille altre ragioni. Ci sono voluti 12 mesi di lavoro per passare da essere nessuno, a essere un contributore del progetto Xz. Per un progetto così ampio è poco, non è tanto tempo. Il lavoro psicologico di questa organizzazione in questo caso è stato preponderante nella testa di Lasse Collin. [tre settimane] <https://git.tukaani.org/?p=xz.git;a=summary> Chi sono i responsabili? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Difficile dirlo. GitHub ha sospeso il progetto Xz bloccandone la pagina di riferimento, ha anche bannato Lasse Collin come responsabile del disastro, e questo è ancora più inaccettabile anche visto gli sforzi (stipendiati zero Euro) da quando esiste Xz ad oggi, e dal 29 marzo ad ora per offrire supporto nel mitigare i danni [documentando tutto]. GitHub ha anche ovviamente bannato l'account di JiaT75 che ha fisicamente firmato gli aggiornamenti malevoli del programma, certo. Ma questo account non esiste, è stato creato ad hoc solo per questa lunghissima operazione, come lui ne possono esistere mille in giro. Sottolineo l'aggressività della campagna: Jia Tan ha cercato di far integrare la sua modifica vulnerabile anche su progetti terzi come 1Password (gestore di password largamente utilizzato), su Ubuntu e su Fedora. Progetti enormi che coinvolgerebbero una marea di utenti in tutto il mondo. Fortunatamente l'operazione è stata interrotta, ma la responsabilità in cose così grandi e impattanti (per me) è una sola: un gruppo sponsorizzato (anche finanziariamente) da uno Stato. Alcuni indizi portano alla Cina (o comunque all'oriente) per eventuali dettagli di orari di operatività e lingua parlata dagli utenti coinvolti, ma è difficile dirlo con certezza. Sicuramente si può dire che dietro ci sia una *organizzazione criminale dalle grosse capacità economiche*: ne sono state spese più dal 2021 ad oggi nella conduzione di questa campagna mirata all'installazione della backdoor, che in tutta la vita del progetto Xz per la sua realizzazione. *Il software open source è sicuro?* Sì, lo è eccome. La comunità è il cuore pulsante di ogni progetto e nel mondo è pieno di persone che vogliono offrire supporto reale per migliorare un progetto, a volte nato per hobby. È quando il progetto matura e diventa di proporzioni ciclopiche che deve arrivare il vero supporto da parte della comunità. Non si lascia uno sviluppatore da solo in balia del mondo, mentre tutti /fanno i soldi/ con la sua libreria. Non si lascia mai che un progetto abbia una persona da sola che pubblichi delle modifiche al codice, senza che altri occhi le abbiano viste e riviste. [documentando tutto] <https://tukaani.org/xz-backdoor/> --8<---------------cut here---------------end--------------->8--- Se avete compreso la pericolosità di questa _classe_ di backdoors (spiegherò nella prossima parte /quale/ classe), vi lascio immaginare cosa potrebbe succedere se con un sistema _analogo_ qualcuno riuscisse a impiantare una backdoor del genere in una libreria usata dal sistema operativo _proprietario_ della Intel Management Engine... o /qualsiasi/ sistema di out-of-band management (che è sostanzialmente un sistema operativo "embedded") con accesso via LAN: https://en.wikipedia.org/wiki/Out-of-band_management Intuite la portata della falla /sistemistica/ di sicurezza? :-O Fine della prima parte. Saluti, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
signature.asc
Description: PGP signature
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
