[CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)
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-g... «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>.
Marco Calamari in Cassandra ne ha parlato qualche giorno fa. "dignitosa coscienza e netta", lui non lo ha detto qui. Maurizio Il 11/04/24 18:25, 380° ha scritto:
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-g...
«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°
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
------------------------------------------------------------------------ lo straniero non parla e non capisce la nostra lingua, che non è più nostra, perché la nostra vera lingua diventa la traduzione, lo scambio luca ferrieri, dalla public library all’open library ------------------------------------------------------------------------ Maurizio Lana Università del Piemonte Orientale Dipartimento di Studi Umanistici Piazza Roma 36 - 13100 Vercelli
Unfortunately, in today's work environment - where many people are at home and rely on network-based services not only for work but also for entertainment (Netflix and the like) - the infrastructure is under stress and the download may fail several times. When you click the yellow DOWNLOAD button, the download starts in the background without any visible activity on your screen. We suggest you open the DOWNLOAD page in your browser to check the status. Please do not close the browser until you are sure the download is complete. If the download does not start, please try a different server. To change servers, click on the INFO link just below the yellow DOWNLOAD button and select a server from the list that appears on the page that opens when you click on the INFO link. Please note that you can retry the download as many times as you like, as long as you do not close the browser window before the download is complete. You can ignore the donation request, as donations are optional and help us keep the project alive. If all goes well, when the download is complete, a window will open asking you to choose whether to run the installer or save the file to your hard drive. Please choose the second option and save the file to your DOWNLOADS folder. Then open the DOWNLOADS folder and double-click on the file (the name starts with LibreOffice and ends with .MSI on Windows and .DMG on MacOS). Follow the on-screen instructions carefully until the end of the installation process. If everything goes well, LibreOffice will be installed correctly and will appear in your menu (for Windows) or in your Applications folder (for MacOS). Please do not use torrents as they are not reliable (as of today). Sorry for the long message. I hope this helps. Best regards. On 11/04/24 19:13, maurizio lana wrote:
Marco Calamari in Cassandra ne ha parlato qualche giorno fa. "dignitosa coscienza e netta", lui non lo ha detto qui. Maurizio
Il 11/04/24 18:25, 380° ha scritto:
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-g...
«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°
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
------------------------------------------------------------------------
lo straniero non parla e non capisce la nostra lingua, che non è più nostra, perché la nostra vera lingua diventa la traduzione, lo scambio luca ferrieri, dalla public library all’open library
------------------------------------------------------------------------ Maurizio Lana Università del Piemonte Orientale Dipartimento di Studi Umanistici Piazza Roma 36 - 13100 Vercelli
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa -- Italo Vignoli - italo@vignoli.org mobile/signal +39.348.5653829 GPG Key ID - 0xAAB8D5C0 DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0
On gio, 2024-04-11 at 18:25 +0200, 380° wrote:
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.
Buonasera, malgrado la preoccupazione che chi ha letto il tuo contributo avrà sperabilmente provato, devo sottolineare che la situazione è molto peggiore di così. Infatti sembra che la comunità della security sia incapace di fare l'ultimo passo di questo ragionamento, e cioè che backdoor come quella di Xz, che non si è diffusa perché intercettata in tempo, **sono certamente già installate in altri software**. Ne scrivevo proprio qualche giorno fa qui. https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddon... provo ad incollare il testo nel seguito. HTH. Marco, Cassandra Crossing/ Xz, Solarwinds e l’Armageddon prossimo venturo Marco A. L. Calamari (582) — Il sabotaggio della libreria Xz è stato sventato, ed ancora una volta i buoni hanno vinto. Ma siamo sicuri che altrove gli attacchi alla supply chain del software non siano riusciti senza che nessuno se ne sia accorto? 5 aprile 2024 — La realtà costringe Cassandra a prolungare ulteriormente la serie “Fine del Mondo” perché nuovi, gravissimi indizi emergono riguardo al fatto che le armi per l’Armageddon informatico prossimo venturo continuano ad accumularsi. E di nuovo, ventate di ottimismo, espresse anche da addetti ai lavori, si propagano in maniera tanto inesplicabile quanto pericolosa. Non certo per stupidità o per incompetenza; forse per desiderio di quieto vivere, forse per ingiustificato ottimismo. Ma per poter esprimere compiutamente ed in maniera comprensibile la sua tesi, Cassandra è come al solito costretta a riavvolgere il nastro e narrare un po’ di antefatti. Per fortuna ci basta riavvolgere solo al 2003, anno in cui viene portato alla luce il tentativo di introdurre una backdoor addirittura nel kernel di Linux. Un amministratore del repository dei sorgenti ufficiali si accorse che una modifica minima apportata ad una banale routine del kernel non appariva richiesta da nessuno. Cassandra non pretende che il C sia patrimonio dei suoi lettori, ma giusto al fine di illustrare la diabolicità della modifica, si tratta della variazione di un singolo carattere in una singola riga, cioè da if ((options == (__WCLONE|__WALL)) && (current->uid == 0)) a if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) la mancanza dell’ultimo “=” faceva si che, ad esempio, qualunque utente avesse usato il comando “kill” con un parametro opportuno (un valore a 16 bit) si sarebbe trovato “promosso” a root, e quindi avrebbe potuto prendere il completo controllo del server. La modifica fu annullata, l’infrastruttura dei server di compilazione fu piallata e ricostruita da zero, ed i sorgenti furono ricaricati da un backup. Buoni 1, Cattivi 0. Ma basta fare un avanti veloce al 2006 per trovare una ulteriore modifica diabolica nella libreria OpenSSL. Due semplici linee commentate diminuivano drasticamente l’entropia dell’RNG della libreria. Per farla anche qui semplice, facevano si che, ad esempio, il numero di differenti chiavi crittografiche generabili dalla libreria passasse da un valore praticamente infinito a 32767. Chi avesse conosciuto questo fatto e precalcolato le opportune chiavi avrebbe potuto forzare qualunque algoritmo crittografico che usasse OpenSSL (cioè praticamente tutti) con estrema facilità. Quando il problema fu scoperto e prontamente risolto, i suoi effetti non cessarono subito. Infatti ci vollero oltre due anni perché la maggioranza delle chiavi “deboli”, generate e diffuse per tutta internet venisse rimpiazzata, cosa che ha lasciato ulteriori due anni di tempo agli autori della malefatta per approfittare dei suoi effetti. Questo evento fu così sentito dai cronisti dell’epoca che addirittura il fumetto XKCD gli dedicò un’arguta vignetta. Ma andiamo avanti, perché purtroppo non c’è niente da ridere. Ci fu chi disse Buoni 2 — Cattivi 0 e palla al centro. Del calcolo di questo punteggio, che è un po’ il nocciolo del ragionamento di Cassandra, riparleremo alla fine di questa esternazione. Arriviamo rapidamente al 2020; un gruppo di criminali informatici al soldo di uno stato nazione attacca la rete di un produttore di software per la sicurezza informatica, probabilmente già nel 2018. Dopo aver violato la rete altera i server che compilavano il software destinato ad essere spedito ai clienti, in modo che includesse una backdoor. Non stiamo parlando di un software qualsiasi, Solarwinds è un sofisticato software per la sicurezza informatica, installato dalle più grandi organizzazioni con stringenti necessità di sicurezza, tra cui, ad esempio, una ventina di agenzie governative americane, fornitori di armamenti, grandi aziende informatiche e compagnia cantando. Si, anche in Italia. L’aggiornamento automatico di Solarwinds aveva quindi installato automaticamente una backdoor che rendeva semplicissimo violare le reti che lo utilizzavano; in questo modo migliaia di reti iperprotette si sono improvvisamente aperte ai criminali informatici che ne hanno potuto abusare a piacimento per anni. Quando l’attacco fu scoperto (perché di attacco si tratta), il principale problema per le organizzazioni colpite fu di capire se erano o no state violate, perché gli attaccanti erano del tipo più pericoloso, quelli bravi, che non si fanno scoprire e che è difficilissimo trovare e scacciare. E finalmente arriviamo al 2024, ad oggi, anzi a due settimane fa, ed all’attacco alla libreria Xz. Un dipendente Microsoft che utilizzava OpenSSL (si, di nuovo lei) si accorge che la nuova versione ci mette 500 millisecondi in più a compere certe operazioni rispetto alla versione precedente. Siccome evidentemente nella sua vita non aveva di meglio da fare e giudicava importante questo problema, si mette a controllare i codici sorgenti per cercarne il motivo. Con suo stupore si accorge che la nuova versione della libreria OpenSSL contiene un file binario proveniente da un’altra libreria, per l’esattezza Xz che è la libreria che si occupa di comprimere e decomprimere i file; si, proprio quella con cui zippate i vostri PDF, che lo sappiate o meno. Si accorge con orrore che questa modifica permette, a chi possiede certe chiavi crittografiche, di iniettare ed eseguire qualunque programma direttamente nel kernel del sistema operativo, e di far succedere qualsiasi cosa; dal prendere il controllo completo del sistema a distruggere rapidamente e completamente tutti i server compromessi. L’analisi retrospettiva degli avvenimenti ha rivelato che due anni prima uno sviluppatore anonimo aveva iniziato a proporre modifiche alla libreria Xz, che erano ragionevoli e quindi erano state accettate del suo amministratore, e poi a farsi accettare come co-amministratore della libreria stessa. Aveva poi lentamente sovvertito il sistema di compilazione della libreria stessa, inserendovi il codice malevolo destinato a finire nella libreria OpenSSL, e contemporaneamente svolgendo una sofisticata azione di ingegneria sociale nei confronti di chi avrebbe potuto controllare le sue modifiche in modo tale che queste verifiche non fossero fatte. Poi, quando la libreria infettata ha cominciato a propagarsi sui primi server, uno di essi è stato quello del benedetto dipendente Microsoft con tanto tempo libero, che non ringrazieremo mai abbastanza e che meriterebbe un monumento. Se questo scarno riassunto non vi paresse abbastanza, potete divertirvi ascoltando questo podcast in cui due titani della scena hacker italiana degli anni ’90 discutono, approfonditamente e scherzosamente, della faccenda, condividendo anche un giudizio ottimistico per il futuro. Quindi Buoni 3 — Cattivi 0 e palla al centro? Bene, questa valutazione è quella che ha accompagnato questi terrificanti eventi, venuti alla luce sempre per fortuna, e prima che potessero causare danni catastrofici. In effetti Solarwind ha davvero causato danni economici rilevantissimi e danni derivanti da furti di dati e da attività spionistiche non precisabili, ma dovrebbe aver spinto la comunità informatica mondiale ad attivarsi contro questo nuovo tipo di attacchi informatici. Quindi Buoni 4 — Cattivi 0?? Ed arriviamo alle conclusioni, probabilmente ormai chiarissime ai 24 informatissimi lettori di Cassandra. Per tutte le divinità mai adorate dagli umani, da Astarte a Zaratustra, inclusi Manitù, Cthulhu e Yog-Setoth, è possibile che nessuno pensi a tutti gli attacchi di questa portata che non sono mai stati rilevati? Quelli in cui nessun dipendente insonne è inciampato, che nessun amministratore di sistema curioso ha mai rilevato? Ma davvero ci sono addetti ai lavori che credono che i buoni continuino a segnare e che i cattivi siano costretti nella loro metà campo? Davvero qualcuno può pensare che gli stati-nazione, i produttori di armi, i grandi e piccoli gruppi criminali e le mafie non stiano accumulando, in grandi e piccoli arsenali, queste “modifiche” al software che fa funzionare il mondo, queste armi informatiche che talvolta sono state anche testate od utilizzate su scala ridotta o con conseguenze circoscritte (i nomi SQL Slammer e Stuxnet non vi dicono niente?). Cassandra è sempre stata andreottiana nell’animo, e mai come in questo caso sente il dovere di invitare gli ottimisti a riconsiderare le proprie posizioni, non per un principio di precauzione, ma per puro e semplice realismo. L’Armageddon della prima guerra informatica mondiale è certamente, e ripeto certamente in fase di avanzata realizzazione. Poi non dite che non vi avevo avvertito. -- Marco A. Calamari <marcoc_maillist@marcoc.it>
una conclusione ptrebbe essere che forse siamo 4 a 1 a nostra insaputa perche' all'attaccante basta avere ragione una volta sola mentre chi difende deve avere ragione sempre e se un cattivo ha avuto ragione, adesso potremmo averlo ospite in casa a nostra insaputa e lui potrebbe farci vedere sul tabellone 4 a 0 On 11/04/24 19:20, Marco A. Calamari wrote:
On gio, 2024-04-11 at 18:25 +0200, 380° wrote:
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.
Buonasera,
malgrado la preoccupazione che chi ha letto il tuo contributo avrà sperabilmente provato, devo sottolineare che la situazione è molto peggiore di così.
Infatti sembra che la comunità della security sia incapace di fare l'ultimo passo di questo ragionamento, e cioè che backdoor come quella di Xz, che non si è diffusa perché intercettata in tempo, **sono certamente già installate in altri software**.
Ne scrivevo proprio qualche giorno fa qui.
https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddon... <https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddon...>
provo ad incollare il testo nel seguito.
HTH. Marco,
Cassandra Crossing/ Xz, Solarwinds e l’Armageddon prossimo venturo Marco A. L. Calamari
(582) — Il sabotaggio della libreria Xz è stato sventato, ed ancora una volta i buoni hanno vinto. Ma siamo sicuri che altrove gli attacchi alla supply chain del software non siano riusciti senza che nessuno se ne sia accorto?
5 aprile 2024 — La realtà costringe Cassandra a prolungare ulteriormente la serie “Fine del Mondo” perché nuovi, gravissimi indizi emergono riguardo al fatto che le armi per l’Armageddon informatico prossimo venturo continuano ad accumularsi.
E di nuovo, ventate di ottimismo, espresse anche da addetti ai lavori, si propagano in maniera tanto inesplicabile quanto pericolosa. Non certo per stupidità o per incompetenza; forse per desiderio di quieto vivere, forse per ingiustificato ottimismo.
Ma per poter esprimere compiutamente ed in maniera comprensibile la sua tesi, Cassandra è come al solito costretta a riavvolgere il nastro e narrare un po’ di antefatti.
Per fortuna ci basta riavvolgere solo al 2003, anno in cui viene portato alla luce il tentativo di introdurre una backdoor addirittura nel kernel di Linux.
Un amministratore del repository dei sorgenti ufficiali si accorse che una modifica minima apportata ad una banale routine del kernel non appariva richiesta da nessuno. Cassandra non pretende che il C sia patrimonio dei suoi lettori, ma giusto al fine di illustrare la diabolicità della modifica, si tratta della variazione di un singolo carattere in una singola riga, cioè da
if ((options == (__WCLONE|__WALL)) && (current->uid == 0))
a
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
la mancanza dell’ultimo “=” faceva si che, ad esempio, qualunque utente avesse usato il comando “kill” con un parametro opportuno (un valore a 16 bit) si sarebbe trovato “promosso” a root, e quindi avrebbe potuto prendere il completo controllo del server.
La modifica fu annullata, l’infrastruttura dei server di compilazione fu piallata e ricostruita da zero, ed i sorgenti furono ricaricati da un backup.
Buoni 1, Cattivi 0.
Ma basta fare un avanti veloce al 2006 per trovare una ulteriore modifica diabolica nella libreria OpenSSL. Due semplici linee commentate diminuivano drasticamente l’entropia dell’RNG della libreria. Per farla anche qui semplice, facevano si che, ad esempio, il numero di differenti chiavi crittografiche generabili dalla libreria passasse da un valore praticamente infinito a 32767. Chi avesse conosciuto questo fatto e precalcolato le opportune chiavi avrebbe potuto forzare qualunque algoritmo crittografico che usasse OpenSSL (cioè praticamente tutti) con estrema facilità.
Quando il problema fu scoperto e prontamente risolto, i suoi effetti non cessarono subito. Infatti ci vollero oltre due anni perché la maggioranza delle chiavi “deboli”, generate e diffuse per tutta internet venisse rimpiazzata, cosa che ha lasciato ulteriori due anni di tempo agli autori della malefatta per approfittare dei suoi effetti.
Questo evento fu così sentito dai cronisti dell’epoca che addirittura il fumetto XKCD gli dedicò un’arguta vignetta.
Ma andiamo avanti, perché purtroppo non c’è niente da ridere.
Ci fu chi disse Buoni 2 — Cattivi 0 e palla al centro.
Del calcolo di questo punteggio, che è un po’ il nocciolo del ragionamento di Cassandra, riparleremo alla fine di questa esternazione.
Arriviamo rapidamente al 2020; un gruppo di criminali informatici al soldo di uno stato nazione attacca la rete di un produttore di software per la sicurezza informatica, probabilmente già nel 2018. Dopo aver violato la rete altera i server che compilavano il software destinato ad essere spedito ai clienti, in modo che includesse una backdoor.
Non stiamo parlando di un software qualsiasi, Solarwinds è un sofisticato software per la sicurezza informatica, installato dalle più grandi organizzazioni con stringenti necessità di sicurezza, tra cui, ad esempio, una ventina di agenzie governative americane, fornitori di armamenti, grandi aziende informatiche e compagnia cantando. Si, anche in Italia.
L’aggiornamento automatico di Solarwinds aveva quindi installato automaticamente una backdoor che rendeva semplicissimo violare le reti che lo utilizzavano; in questo modo migliaia di reti iperprotette si sono improvvisamente aperte ai criminali informatici che ne hanno potuto abusare a piacimento per anni. Quando l’attacco fu scoperto (perché di attacco si tratta), il principale problema per le organizzazioni colpite fu di capire se erano o no state violate, perché gli attaccanti erano del tipo più pericoloso, quelli bravi, che non si fanno scoprire e che è difficilissimo trovare e scacciare.
E finalmente arriviamo al 2024, ad oggi, anzi a due settimane fa, ed all’attacco alla libreria Xz.
Un dipendente Microsoft che utilizzava OpenSSL (si, di nuovo lei) si accorge che la nuova versione ci mette 500 millisecondi in più a compere certe operazioni rispetto alla versione precedente. Siccome evidentemente nella sua vita non aveva di meglio da fare e giudicava importante questo problema, si mette a controllare i codici sorgenti per cercarne il motivo. Con suo stupore si accorge che la nuova versione della libreria OpenSSL contiene un file binario proveniente da un’altra libreria, per l’esattezza Xz che è la libreria che si occupa di comprimere e decomprimere i file; si, proprio quella con cui zippate i vostri PDF, che lo sappiate o meno.
Si accorge con orrore che questa modifica permette, a chi possiede certe chiavi crittografiche, di iniettare ed eseguire qualunque programma direttamente nel kernel del sistema operativo, e di far succedere qualsiasi cosa; dal prendere il controllo completo del sistema a distruggere rapidamente e completamente tutti i server compromessi.
L’analisi retrospettiva degli avvenimenti ha rivelato che due anni prima uno sviluppatore anonimo aveva iniziato a proporre modifiche alla libreria Xz, che erano ragionevoli e quindi erano state accettate del suo amministratore, e poi a farsi accettare come co-amministratore della libreria stessa. Aveva poi lentamente sovvertito il sistema di compilazione della libreria stessa, inserendovi il codice malevolo destinato a finire nella libreria OpenSSL, e contemporaneamente svolgendo una sofisticata azione di ingegneria sociale nei confronti di chi avrebbe potuto controllare le sue modifiche in modo tale che queste verifiche non fossero fatte.
Poi, quando la libreria infettata ha cominciato a propagarsi sui primi server, uno di essi è stato quello del benedetto dipendente Microsoft con tanto tempo libero, che non ringrazieremo mai abbastanza e che meriterebbe un monumento.
Se questo scarno riassunto non vi paresse abbastanza, potete divertirvi ascoltando questo podcast in cui due titani della scena hacker italiana degli anni ’90 discutono, approfonditamente e scherzosamente, della faccenda, condividendo anche un giudizio ottimistico per il futuro.
Quindi Buoni 3 — Cattivi 0 e palla al centro?
Bene, questa valutazione è quella che ha accompagnato questi terrificanti eventi, venuti alla luce sempre per fortuna, e prima che potessero causare danni catastrofici. In effetti Solarwind ha davvero causato danni economici rilevantissimi e danni derivanti da furti di dati e da attività spionistiche non precisabili, ma dovrebbe aver spinto la comunità informatica mondiale ad attivarsi contro questo nuovo tipo di attacchi informatici.
Quindi Buoni 4 — Cattivi 0??
Ed arriviamo alle conclusioni, probabilmente ormai chiarissime ai 24 informatissimi lettori di Cassandra.
Per tutte le divinità mai adorate dagli umani, da Astarte a Zaratustra, inclusi Manitù, Cthulhu e Yog-Setoth, è possibile che nessuno pensi a tutti gli attacchi di questa portata che non sono mai stati rilevati? Quelli in cui nessun dipendente insonne è inciampato, che nessun amministratore di sistema curioso ha mai rilevato?
Ma davvero ci sono addetti ai lavori che credono che i buoni continuino a segnare e che i cattivi siano costretti nella loro metà campo?
Davvero qualcuno può pensare che gli stati-nazione, i produttori di armi, i grandi e piccoli gruppi criminali e le mafie non stiano accumulando, in grandi e piccoli arsenali, queste “modifiche” al software che fa funzionare il mondo, queste armi informatiche che talvolta sono state anche testate od utilizzate su scala ridotta o con conseguenze circoscritte (i nomi SQL Slammer e Stuxnet non vi dicono niente?).
Cassandra è sempre stata andreottiana nell’animo, e mai come in questo caso sente il dovere di invitare gli ottimisti a riconsiderare le proprie posizioni, non per un principio di precauzione, ma per puro e semplice realismo.
L’Armageddon della prima guerra informatica mondiale è certamente, e ripeto certamente in fase di avanzata realizzazione. Poi non dite che non vi avevo avvertito.
--
Marco A. Calamari <marcoc_maillist@marcoc.it <mailto:marcoc_maillist@marcoc.it>>
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
On gio, 2024-04-11 at 19:28 +0200, Stefano Quintarelli wrote:
una conclusione ptrebbe essere che forse siamo 4 a 1 a nostra insaputa perche' all'attaccante basta avere ragione una volta sola mentre chi difende deve avere ragione sempre e se un cattivo ha avuto ragione, adesso potremmo averlo ospite in casa a nostra insaputa e lui potrebbe farci vedere sul tabellone 4 a 0
Tutto vero, certo, ma il problema è proprio questo. Nessuno userà le backdoor già impiantate per far soldi. Non le hanno impiantate normali criminali. Sono armi ben oliate ed immagazzinate ... pronte per essere usate per uno scopo pianificato con cura. La paranoia è una virtù.
On 11/04/24 19:20, Marco A. Calamari wrote:
On gio, 2024-04-11 at 18:25 +0200, 380° wrote:
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.
Buonasera,
malgrado la preoccupazione che chi ha letto il tuo contributo avrà sperabilmente provato, devo sottolineare che la situazione è molto peggiore di così.
Infatti sembra che la comunità della security sia incapace di fare l'ultimo passo di questo ragionamento, e cioè che backdoor come quella di Xz, che non si è diffusa perché intercettata in tempo, **sono certamente già installate in altri software**.
Ne scrivevo proprio qualche giorno fa qui.
https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddon... < https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddon...
provo ad incollare il testo nel seguito.
HTH. Marco,
Cassandra Crossing/ Xz, Solarwinds e l’Armageddon prossimo venturo Marco A. L. Calamari
(582) — Il sabotaggio della libreria Xz è stato sventato, ed ancora una volta i buoni hanno vinto. Ma siamo sicuri che altrove gli attacchi alla supply chain del software non siano riusciti senza che nessuno se ne sia accorto?
5 aprile 2024 — La realtà costringe Cassandra a prolungare ulteriormente la serie “Fine del Mondo” perché nuovi, gravissimi indizi emergono riguardo al fatto che le armi per l’Armageddon informatico prossimo venturo continuano ad accumularsi.
E di nuovo, ventate di ottimismo, espresse anche da addetti ai lavori, si propagano in maniera tanto inesplicabile quanto pericolosa. Non certo per stupidità o per incompetenza; forse per desiderio di quieto vivere, forse per ingiustificato ottimismo.
Ma per poter esprimere compiutamente ed in maniera comprensibile la sua tesi, Cassandra è come al solito costretta a riavvolgere il nastro e narrare un po’ di antefatti.
Per fortuna ci basta riavvolgere solo al 2003, anno in cui viene portato alla luce il tentativo di introdurre una backdoor addirittura nel kernel di Linux.
Un amministratore del repository dei sorgenti ufficiali si accorse che una modifica minima apportata ad una banale routine del kernel non appariva richiesta da nessuno. Cassandra non pretende che il C sia patrimonio dei suoi lettori, ma giusto al fine di illustrare la diabolicità della modifica, si tratta della variazione di un singolo carattere in una singola riga, cioè da
if ((options == (__WCLONE|__WALL)) && (current->uid == 0))
a
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
la mancanza dell’ultimo “=” faceva si che, ad esempio, qualunque utente avesse usato il comando “kill” con un parametro opportuno (un valore a 16 bit) si sarebbe trovato “promosso” a root, e quindi avrebbe potuto prendere il completo controllo del server.
La modifica fu annullata, l’infrastruttura dei server di compilazione fu piallata e ricostruita da zero, ed i sorgenti furono ricaricati da un backup.
Buoni 1, Cattivi 0.
Ma basta fare un avanti veloce al 2006 per trovare una ulteriore modifica diabolica nella libreria OpenSSL. Due semplici linee commentate diminuivano drasticamente l’entropia dell’RNG della libreria. Per farla anche qui semplice, facevano si che, ad esempio, il numero di differenti chiavi crittografiche generabili dalla libreria passasse da un valore praticamente infinito a 32767. Chi avesse conosciuto questo fatto e precalcolato le opportune chiavi avrebbe potuto forzare qualunque algoritmo crittografico che usasse OpenSSL (cioè praticamente tutti) con estrema facilità.
Quando il problema fu scoperto e prontamente risolto, i suoi effetti non cessarono subito. Infatti ci vollero oltre due anni perché la maggioranza delle chiavi “deboli”, generate e diffuse per tutta internet venisse rimpiazzata, cosa che ha lasciato ulteriori due anni di tempo agli autori della malefatta per approfittare dei suoi effetti.
Questo evento fu così sentito dai cronisti dell’epoca che addirittura il fumetto XKCD gli dedicò un’arguta vignetta.
Ma andiamo avanti, perché purtroppo non c’è niente da ridere.
Ci fu chi disse Buoni 2 — Cattivi 0 e palla al centro.
Del calcolo di questo punteggio, che è un po’ il nocciolo del ragionamento di Cassandra, riparleremo alla fine di questa esternazione.
Arriviamo rapidamente al 2020; un gruppo di criminali informatici al soldo di uno stato nazione attacca la rete di un produttore di software per la sicurezza informatica, probabilmente già nel 2018. Dopo aver violato la rete altera i server che compilavano il software destinato ad essere spedito ai clienti, in modo che includesse una backdoor.
Non stiamo parlando di un software qualsiasi, Solarwinds è un sofisticato software per la sicurezza informatica, installato dalle più grandi organizzazioni con stringenti necessità di sicurezza, tra cui, ad esempio, una ventina di agenzie governative americane, fornitori di armamenti, grandi aziende informatiche e compagnia cantando. Si, anche in Italia.
L’aggiornamento automatico di Solarwinds aveva quindi installato automaticamente una backdoor che rendeva semplicissimo violare le reti che lo utilizzavano; in questo modo migliaia di reti iperprotette si sono improvvisamente aperte ai criminali informatici che ne hanno potuto abusare a piacimento per anni. Quando l’attacco fu scoperto (perché di attacco si tratta), il principale problema per le organizzazioni colpite fu di capire se erano o no state violate, perché gli attaccanti erano del tipo più pericoloso, quelli bravi, che non si fanno scoprire e che è difficilissimo trovare e scacciare.
E finalmente arriviamo al 2024, ad oggi, anzi a due settimane fa, ed all’attacco alla libreria Xz.
Un dipendente Microsoft che utilizzava OpenSSL (si, di nuovo lei) si accorge che la nuova versione ci mette 500 millisecondi in più a compere certe operazioni rispetto alla versione precedente. Siccome evidentemente nella sua vita non aveva di meglio da fare e giudicava importante questo problema, si mette a controllare i codici sorgenti per cercarne il motivo. Con suo stupore si accorge che la nuova versione della libreria OpenSSL contiene un file binario proveniente da un’altra libreria, per l’esattezza Xz che è la libreria che si occupa di comprimere e decomprimere i file; si, proprio quella con cui zippate i vostri PDF, che lo sappiate o meno.
Si accorge con orrore che questa modifica permette, a chi possiede certe chiavi crittografiche, di iniettare ed eseguire qualunque programma direttamente nel kernel del sistema operativo, e di far succedere qualsiasi cosa; dal prendere il controllo completo del sistema a distruggere rapidamente e completamente tutti i server compromessi.
L’analisi retrospettiva degli avvenimenti ha rivelato che due anni prima uno sviluppatore anonimo aveva iniziato a proporre modifiche alla libreria Xz, che erano ragionevoli e quindi erano state accettate del suo amministratore, e poi a farsi accettare come co-amministratore della libreria stessa. Aveva poi lentamente sovvertito il sistema di compilazione della libreria stessa, inserendovi il codice malevolo destinato a finire nella libreria OpenSSL, e contemporaneamente svolgendo una sofisticata azione di ingegneria sociale nei confronti di chi avrebbe potuto controllare le sue modifiche in modo tale che queste verifiche non fossero fatte.
Poi, quando la libreria infettata ha cominciato a propagarsi sui primi server, uno di essi è stato quello del benedetto dipendente Microsoft con tanto tempo libero, che non ringrazieremo mai abbastanza e che meriterebbe un monumento.
Se questo scarno riassunto non vi paresse abbastanza, potete divertirvi ascoltando questo podcast in cui due titani della scena hacker italiana degli anni ’90 discutono, approfonditamente e scherzosamente, della faccenda, condividendo anche un giudizio ottimistico per il futuro.
Quindi Buoni 3 — Cattivi 0 e palla al centro?
Bene, questa valutazione è quella che ha accompagnato questi terrificanti eventi, venuti alla luce sempre per fortuna, e prima che potessero causare danni catastrofici. In effetti Solarwind ha davvero causato danni economici rilevantissimi e danni derivanti da furti di dati e da attività spionistiche non precisabili, ma dovrebbe aver spinto la comunità informatica mondiale ad attivarsi contro questo nuovo tipo di attacchi informatici.
Quindi Buoni 4 — Cattivi 0??
Ed arriviamo alle conclusioni, probabilmente ormai chiarissime ai 24 informatissimi lettori di Cassandra.
Per tutte le divinità mai adorate dagli umani, da Astarte a Zaratustra, inclusi Manitù, Cthulhu e Yog-Setoth, è possibile che nessuno pensi a tutti gli attacchi di questa portata che non sono mai stati rilevati? Quelli in cui nessun dipendente insonne è inciampato, che nessun amministratore di sistema curioso ha mai rilevato?
Ma davvero ci sono addetti ai lavori che credono che i buoni continuino a segnare e che i cattivi siano costretti nella loro metà campo?
Davvero qualcuno può pensare che gli stati-nazione, i produttori di armi, i grandi e piccoli gruppi criminali e le mafie non stiano accumulando, in grandi e piccoli arsenali, queste “modifiche” al software che fa funzionare il mondo, queste armi informatiche che talvolta sono state anche testate od utilizzate su scala ridotta o con conseguenze circoscritte (i nomi SQL Slammer e Stuxnet non vi dicono niente?).
Cassandra è sempre stata andreottiana nell’animo, e mai come in questo caso sente il dovere di invitare gli ottimisti a riconsiderare le proprie posizioni, non per un principio di precauzione, ma per puro e semplice realismo.
L’Armageddon della prima guerra informatica mondiale è certamente, e ripeto certamente in fase di avanzata realizzazione. Poi non dite che non vi avevo avvertito.
--
Marco A. Calamari <marcoc_maillist@marcoc.it <mailto:marcoc_maillist@marcoc.it>>
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Buongiorno, a chi è intervenuto (e interverrà) nel thread: grazie davvero per i commenti che avete inviato, vi prometto che con calma vi risponderò ove necessario, ma prima vorrei finire almeno la parte 2 della mia analisi e ci vorrà ancora un po' di tempo (indefinito). Lungi da me voler dissuadere chiunque dall'aggiungere i propri commenti a questo thread, faccio però a tutti una preghiera: siccome si tratta di una questione relativamente complessa, sarebbe il caso che chi non avesse avuto modo di studiare la questione "backdoor in XZ", anche leggendo analisi altrui, si astenesse _momentaneamente_ dai commenti, perché mancherebbero elementi importanti per formarsi un giudizio completo in merito alla situazuione, alle sue cause e alle possibili soluzioni a medio/lungo termine; sta succedendo anche a _superstar_ del settore di sbagliare clamorosamente, credetemi. Infine, sapete che io sono il re degli OT ma in questo thread mi piacerebbe ci concentrassimo sugli aspetti tecnici *e* ambientali (sociali, economici, ecc.) che hanno reso possiblile questo _specifico_ attacco che definirei: "targeted backdoor injection through build process subversion of a library via supply chain attack by unfaithful authority" ...se non lo capite adesso, spero che dopo la parte 2 sarà più chiaro. Per ora aggiungo solo che non si tratta di una "banale" backdoor [1] e nemmeno di un "banale" supply chain attack [2], perché per quel tipo di attacchi l'ecosistema FLOSS ha già trovato _da_diverso_tempo_ una *soluzione* tecnica, che alcune distribuzioni GNU/Linux et al stanno cercando di attuare, risolvendo pazientemente le "asperità tecniche e sociali" che stanno emergendo nelle fasi di _implementazione_ delle soluzioni trovare. Alla prossima puntata :-) Loving, 380° [1] per esempio inserita direttamente nel codice della libreria [2] per esempio attuato infiltrandosi senza autorizzazione nel sistema di distribuzione del *binario* -- 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>.
On 4/12/24 09:49, 380° wrote:
Buongiorno,
a chi è intervenuto (e interverrà) nel thread: grazie davvero per i commenti che avete inviato, vi prometto che con calma vi risponderò ove necessario, ma prima vorrei finire almeno la parte 2 della mia analisi e ci vorrà ancora un po' di tempo (indefinito).
Lungi da me voler dissuadere chiunque dall'aggiungere i propri commenti a questo thread, faccio però a tutti una preghiera: siccome si tratta di una questione relativamente complessa, sarebbe il caso che chi non avesse avuto modo di studiare la questione "backdoor in XZ", anche leggendo analisi altrui, si astenesse _momentaneamente_ dai commenti, perché mancherebbero elementi importanti per formarsi un giudizio completo in merito alla situazuione, alle sue cause e alle possibili soluzioni a medio/lungo termine; sta succedendo anche a _superstar_ del settore di sbagliare clamorosamente, credetemi.
Infine, sapete che io sono il re degli OT ma in questo thread mi piacerebbe ci concentrassimo sugli aspetti tecnici *e* ambientali (sociali, economici, ecc.) che hanno reso possiblile questo _specifico_ attacco che definirei:
"targeted backdoor injection through build process subversion of a library via supply chain attack by unfaithful authority"
...se non lo capite adesso, spero che dopo la parte 2 sarà più chiaro.
Per ora aggiungo solo che non si tratta di una "banale" backdoor [1] e nemmeno di un "banale" supply chain attack [2], perché per quel tipo di attacchi l'ecosistema FLOSS ha già trovato _da_diverso_tempo_ una *soluzione* tecnica, che alcune distribuzioni GNU/Linux et al stanno cercando di attuare, risolvendo pazientemente le "asperità tecniche e sociali" che stanno emergendo nelle fasi di _implementazione_ delle soluzioni trovare.
Alla prossima puntata :-)
Loving, 380°
[1] per esempio inserita direttamente nel codice della libreria
[2] per esempio attuato infiltrandosi senza autorizzazione nel sistema di distribuzione del *binario*
Grazie mille, 380°, veramente ben fatta. Attendo la seconda parte, allora. D. (null)
Lungi da me voler dissuadere chiunque dall'aggiungere i propri commenti a questo thread, faccio però a tutti una preghiera: siccome si tratta di una questione relativamente complessa, sarebbe il caso che chi non avesse avuto modo di studiare la questione "backdoor in XZ",
Ti assicuro che l'ho studiata, fidati sulla parola ;) Qualche informazione in più, non prettamente tecnica ma necessaria, dato che in giro ci questi titoli ad effetto: "Come un volontario ha impedito a una backdoor di esporre i sistemi ..." o "Sviluppatore Microsoft salva Linux da una backdoor in xz". Bene, lo "sviluppatore volontario Microsoft" è tale Andres Freund che ha passato parte della sua giovane vita (38 anni) sul kernel Linux (discutendone in lista con Linus Torvalds e gli altri) e su PostgreSQL. Qui un suo post del 2007 [1]. Sulla faccenda c'è, quindi, anche da considerare la "lettura" di RMS e gli altri [2][3] A. [1] https://lore.kernel.org/lkml/200712020210.59041.andres@anarazel.de/ [2] https://techrights.org/n/2024/03/31/Microsoft-Exchange-chaos-the-real-news.s... [3] https://techrights.org/n/2024/04/02/Richard_Stallman_Was_Right_and_What_Happ...
Ciao Antonio, grazie per i link che non conoscevo! (ce ne saranno a decine di utili che ancora ignoro) Ai tuoi commenti rispondo rapidissimamente perché è facile ;-) Antonio <antonio@piumarossa.it> writes:
Ti assicuro che l'ho studiata, fidati sulla parola ;)
ROTFL :-D [...]
Bene, lo "sviluppatore volontario Microsoft" è tale Andres Freund
Sì e ovviamente ci sono ancora molte questioni aperte in merito ai tempi e modi nei quali ha rilevato e rivelato la backdoor... forse ci arriverò nella parte terza. Comunque ai fini della _sostanza_ della falla di sicurezza evidenziata da questo attacco la ritengo una questione /secondaria/, non perché ignoro che dietro la rivelazione potrebbe esserci una qualche macchinazione (anche secondaria), ma perché... chissenefrega? [...]
Qui un suo post del 2007 [1].
Per curiosità, per cosa ritieni che quel post sia interessante nel contesto di questa discussione?
Sulla faccenda c'è, quindi, anche da considerare la "lettura" di RMS e gli altri [2][3]
Ho dato una rapidissima occhiata ai due articoli (li leggerò con calma quando riuscirò) ma ho capito il senso... ...e sì, è ovvio che questa vicenda è usata, ancora una volta, per gettare fango ad-minchiam; per distratte? Non lo so, vedremo. Noi nel frattempo prendiamo nota ;-) Al volo ti dico che _non_ è un caso se ho scelto un articolo equilibrato intitolato «Backdoor su Xz: il problema è molto più grande, non è l'open source e non si risolve con un aggiornamento. Una storia incredibile». Chiunque abbia la incommensurabile faccia tosta di attribuire il fatto che la backdoor sia stata iniettata in OpenSSH perché "l'ecosistema" FLOSS non è sicuro mentre quello proprietario sì, ha solo voglia di rendersi ridicolo agli occhi della storia, anche se qualche beota probabilmente gli darà ascolto perché "autorevole". Ribadisco che "l'ecosistema" FLOSS consente di implementare tutti gli strumenti tecnici (in via di rapido sviluppo) e /sociali/ per evitare /anche/ simili attacchi, cosa che i /cultori/ del software proprietario possono solo sognarsi nei loro sogni erotici più spinti. Loving, 380°
[1] https://lore.kernel.org/lkml/200712020210.59041.andres@anarazel.de/ [2] https://techrights.org/n/2024/03/31/Microsoft-Exchange-chaos-the-real-news.s... [3] https://techrights.org/n/2024/04/02/Richard_Stallman_Was_Right_and_What_Happ...
-- 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>.
Salve 380, come Antonio, ho seguito la questione nel suo svilupparsi, con un misto di tristezza e divertimento, tanto da aver preceduto Schneier [1]. Si tratta però di ovvietà: centinaia di simili backdoor sono correntemente in produzione. Forse migliaia. Solo i professionisti del InfoSec possono fingere di credere il contrario (da cui il dramma inscenato online). Tuttavia, tutte le analisi che ho letto sull'attacco subito da OpenSSH tramite SystemD tramite XZ sono basate sulle stesse assunzioni che hanno reso possibile l'attacco. Alla base di questo castello di assunzioni c'è l'accettazione della enorme complessità degli stack applicativi mainstream, in cui nascondere una backdoor è facilissimo anche se (de)i sorgenti sono disponibili. Le libertà promesse dal software libero (e ancor più da quello opensource) sono sistematicamente vanificate dalla complessità che lo caratterizzano. Se una persona adulta non può leggere e comprendere interamente un software in (al massimo) un mese, quel software è irrimediabilmente vulnerabile e probabilmente compromesso. Il resto sono favolette consolatorie. Non è un problema dell'FLOSS. Non è un problema di autoconf. Non è nemmeno un problema di riproducibilità delle build. C'è un problema di sfruttamento degli sviluppatori volontari, ma risolverlo non risolverà il problema. Il problema è cibernetico e culturale, non tecnico o economico. Dovremmo ristudiare Wirth: https://www.projectoberon.net/ Giacomo [1] https://qoto.org/@Shamar/112195245691551523
Buongiorno, Executive summary: l'intera questione si può riassumere in una mancanza di verificabilità _pragmatica_ di /alcuni/ file necessari durante le /varie/ fasi di compilazione (build phase), solitamente distribuiti dagli autori del software (upstream) attraverso le cosidette "release tarball" e solitamente usati dagli utilizzatori (downstream) per compilare il binario ed eventualmente distribuirlo. Dopo l'introduzione, è il momento di addentrarci un pochino nelle questioni tecniche (_sistemistiche_) necessarie per una analisi efficace della situazione e di conseguenza ipotizzare una soluzione per _azzerare_ questa classe di attacchi: non sto esagerando, azzerare. Cercherò di essere sintetico al massimo ma certe cose non si possono semplificare senza complicarne irrimediabilmente la comprensione. Innanzi tutto, la pagina ufficiale di Lasse Collin in merito alla backdoor è questa: https://tukaani.org/xz-backdoor/ (1) ...ma non è necessario attendere che lui abbia tempo di scrivere l'articolo che ha in programma, sappiamo già abbastanza. Affinché quell'attacco funzionasse, sono state _indispensabili_ due condizioni: 1. sia il codice di injection (il trojan) che il codice della backdoor stessa (il cosiddetto payload) erano _molto_ nascosti: il trojan in tre (quattro?) script concatenati e offuscati (Stage 0..3), il payload in due files inseriti dagli attaccanti con lo scopo dichiarato di servire per i test del software, che normalmente fanno parte delle fasi di build. Questo è ben spiegato in «xz/liblzma: Bash-stage Obfuscation Explained» [2] --8<---------------cut here---------------start------------->8--- the bash part is split into three (four?) stages of interest, which I have named Stage 0 (that's the start code added in m4/build-to-host.m4) to Stage 2. I'll touch on the potential "Stage 3" as well, though I don't think it has fully materialized yet. Please also note that the obfuscated/encrypted stages and later binary backdoor are hidden in two test files: tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma. --8<---------------cut here---------------end--------------->8--- 2. il primo stadio (Stage 0) trojan era presente _solo_ dentro la release tarball rilasciata upstream, quello pubblicato nel repository git ufficiale (sempre upstream) era diverso. Questo è ben spiegato nelle "FAQ by Sam James" [3] citato in (1): --8<---------------cut here---------------start------------->8--- * The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf. The version of build-to-host.m4 in the release tarballs differs wildly from the upstream on GitHub. [...] TODO for this doc [...] * Explain dist tarballs, why we use them, what they do, link to autotools docs, etc * "Explaining the history of it would be very helpful I think. It also explains how a single person was able to insert code in an open source project that no one was able to peer review. It is pragmatically impossible, even if technically possible once you know the problem is there, to peer review a tarball prepared in this manner." --8<---------------cut here---------------end--------------->8--- Perché nessuno si è accorto che build-to-host.m4 presente nella "release tarball" differiva da quello in git? Perché build-to-host.m4 è uno dei diversi file autogenerati da autotools e autoconf e quei file non sono umanamente leggibili, sono sostanzialmente analoghi a quello che in gergo tecnico si chiamano /binary seeds/ [4], anche se scritti in linguaggio shell (credo bash). Al contrario, I file (sorgenti) usati da autotools e autoconf per autogenerare build-to-host.m4 e compagni sono decisamente più umani, si prestano quindi a poter essere verificati e sono ovviamente presenti sia nel VCS ufficiale che nelle "release tarball" ufficiali. La soluzione a questo /primo/ problema è facilissima, quindi: i "downstream consumer" devono semplicemente smetterla di essere _pigri_, perché «this is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf». Quindi i "downstream consumers" semplicemente devono ricordarsi come si usano autotools e autoconf e _usarli_ nelle loro fasi di build, senza scorciatoie. Rimane però il _vero_ problema: controllare che davvero la release tarball contenga esattamente lo stesso codice distribuito nel VCS e NON quello con _aggiunta_ una backdoor (che sia ben nascosta o no non fa differenza) è un lavoraccio e _pragmaticamente_ non lo possono fare le persone; andrebbe automatizzato ma non è possibile, perché le release tarball non sono riproducibili. [5] L'idea che sta raccogliendo più consensi nel progetto Guix - la distribuzione, quindi downstream - et al è quella che le release tarball siano /inemendabili/ dal punto di vista della riproducibilità [6], quindi stanno valutando come effettuare la transizione dai sorgenti presi dalle release tarball a quelli presi direttamente dal VCS, come già avviene per molti pacchetti i cui sorgenti sono disponibili via git. Usando direttamente il codice preso dal VCS upstream si azzererebbero le possibilità di riuscire a nascondere un trojan (tipo build-to-host.m4) in grado di sovvertire il processo di build e fargli installare la backdoor a sua volta nascosta in file binari camuffati da file necessari per i test. Fine della seconda parte. Sto valutando una terza parte per illustrare cosa _non_ risolve questi problemi, ma non vorrei annoiare perché non sono sicurissimo sia on topic in questa lista e... ho la sindrome dell'impostore. Loving, 380° [1] credo che più del 90% di "upstream" usi qualche VCS (es. git, SVN, ecc.) per gestire il proprio codice. [2] https://gynvael.coldwind.pl/?lang=en&id=782 [3] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 [4] http://joyofsource.com/reduced-binary-seed-bootstrap.html [5] la riproducibilità del software è una caratteristica tecnica molto importante sulla quale qui mi tocca soprassedere per non ammazzare di noia chi legge, che se interessato saprà dove cercare [6] per approfondimenti sul perché e il percome si veda ad esempio questo thread nella mailing list guix-devel: https://yhetil.org/guix/8734s1mn5p.fsf@xelera.eu/ -- 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>.
Ciao 380, grazie per aver speso il tempo di scrivere questa ottima disanima: sei un ottimo divulgatore! Aggiungo solo qualche considerazione: Il 13 Aprile 2024 17:45:54 CEST, "380°" ha scritto:
Perché build-to-host.m4 è uno dei diversi file autogenerati da autotools e autoconf e quei file non sono umanamente leggibili, [...]
La soluzione a questo /primo/ problema è facilissima, quindi: i "downstream consumer" devono semplicemente smetterla di essere _pigri_
Ovvero smettere di usare la procedura ``` ./configure ... make make install ``` Giusto per chiarire la complessità della "soluzione facilissima" a chiunque abbia mai scaricato e compilato un tar.gz Direi che questo è un caso da manuale di soluzione semplice tutt'altro che facile. :-)
Usando direttamente il codice preso dal VCS upstream si azzererebbero le possibilità di riuscire a nascondere un trojan (tipo build-to-host.m4) in grado di sovvertire il processo di build e fargli installare la backdoor a sua volta nascosta in file binari camuffati da file necessari per i test.
Purtroppo non basta lontanamente. Leggi questo bell'esperimento mentale di Vegard Nossum <https://www.openwall.com/lists/oss-security/2024/04/17/3> Cito solo la conclusione a seguito di 6 possibili mitigazioni (tutt'altro che facili) dell'attacco che Nossum ha ideato: ``` Even if we did all of this, it would of course still not be enough. The underlying problem is having things that are unreadable or unreviewable -- binary files, inscrutable code (whether shell scripts, makefiles, m4 code, or, in some cases, Perl code). ``` Conclusione comunque parziale: più in generale se un qualunque software (kernel, libreria, script di build...) non può essere compreso interamente (in un tempo ragionevole) qualunque sistema cibernetico che ne dipenda è vulnerabile e probabilmente già compromesso. Il problema è la complessità. Aggiungere complessità non lo risolverà, potrà solo nasconderlo. Giacomo
On mer, 2024-04-17 at 23:58 +0200, Giacomo Tesio wrote:
Ciao 380,
grazie per aver speso il tempo di scrivere questa ottima disanima: sei un ottimo divulgatore!
Aggiungo solo qualche considerazione:
Il 13 Aprile 2024 17:45:54 CEST, "380°" ha scritto:
Perché build-to-host.m4 è uno dei diversi file autogenerati da autotools
...
Conclusione comunque parziale: più in generale se un qualunque software (kernel, libreria, script di build...) non può essere compreso interamente (in un tempo ragionevole) qualunque sistema cibernetico che ne dipenda è vulnerabile e probabilmente già compromesso. Il problema è la complessità. Aggiungere complessità non lo risolverà, potrà solo nasconderlo.
Ecco, questo è il punto. Ottima sintesi finale. Discutiamo di attacchi, mentre il problema vero è la complessità del software che regge il mondo, e la contingenza attuale è che tutto questo software è certamente già compromesso, come le mura già minate ma apparentemente intatte di una città sotto assedio. Sembrano solide, ma il nemico le ha già distrutte, ed aspetta solo il momento giusto. JM2C. Marco
...
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).
Fermo restando che Lasse Collin non è il vero nome dello sviluppatore, ma va beh, ognuno si presenta su Internet come vuole, a che punto siamo dopo due mesi? Pochi giorni fa [1] è uscita la versione 5.6.2 di xz-utils che mette una "pezza" su tutto ciò che di "malevolo" è stato fatto da JiaT75. C'è una cosa, però, di strano ... "Sam James is now a supporting maintainer. The x...@tukaani.org email address forwards to me and him." Ovvero quello che mesi prima era stato fatto con Jia Tan (la condivisione della mail). Ma chi è questo Sam James, qualcuno l'ha mai visto di persona? Di lui si sa soltanto quello che afferma, ovvero che: "I'm a maths student from the UK. I enjoy learning, no matter what the topic is, and generally try to make things better, whatever they are. I've loved playing with Linux since I was 11, and haven't stopped since then. Pleased to be finally giving back to my favourite distro and the wider community. I'm passionate about security and that's why my main focus of contributions is in that area: helping the security project, some tangential topics like security-critical packages in tree, and Gentoo Hardened! And I like getting stuck in." [2] Ok, immagino ciò che alcuni di voi stiano pensando. Alcuni sviluppatori open source sono molto attenti alla privacy e preferiscono l'anonimato, ma dopo un caso del genere non sarebbe stato più opportuno agire alla luce del sole? A. [1] https://www.mail-archive.com/xz-devel@tukaani.org/msg00681.html [2] https://archives.gentoo.org/gentoo-project/message/0c047ccf685c8879c0044e9c2...
On ven, 2024-05-31 at 08:54 +0200, Antonio wrote:
... ...
Ok, immagino ciò che alcuni di voi stiano pensando. Alcuni sviluppatori open source sono molto attenti alla privacy e preferiscono l'anonimato, ma dopo un caso del genere non sarebbe stato più opportuno agire alla luce del sole?
Da membro poco attivo della comunità, a titolo personale, ti rispondo tranquillamente di no. Te lo motivo: 1) in realtà serve una cambiamento nella valutazione delle collaborazioni proprie ed altrui 2) l'approccio alla privacy e ad altre questioni di una comunità globale poco accoppiata (loosely coupled) ha un'inerzia fortissima, e comunque non è la causa del problema, che è esterna alla comunità, essendo un problema di guerra asimmetrica. 3) il problema vero credo sia l'inclusione selvaggia di qualsiasi cosa che funzioni in prodotti comnerciali chiusi e poco verificati, per massimizzare i profitti. Su questo, credo, si dovrebbe agire, se si vuole essere efficaci. In ogni caso, una valutazione negativa di un diritto alla privacy ed al parziale/totale anonimato di tutti, sviluppatori non commerciali inclusi, mi pare traspaia anche dalle tue parole. Sbaglio ad interpretarle così? JM2C. Grazie a tutti. Marco
In ogni caso, una valutazione negativa di un diritto alla privacy ed al parziale/totale anonimato di tutti, sviluppatori non commerciali inclusi, mi pare traspaia anche dalle tue parole. Sbaglio ad interpretarle così?
Io tengo all'anonimato quanto te. Mi riferivo solo a questo caso. Perché non si è fatta avanti la Linux Foundation per "aiutare", dato che xz è, tra l'altro, anche parte del kernel linux? Nel dubbio, io non installerò questa versione e, anzi, provvederò ad eliminare completamente xz (nei limiti del possibile). L'open source è "fiducia", io mi fido degli altri sviluppatori perché do per scontato che agiscano come me, ovvero, da volontario, per il bene degli altri (del nostro caso, della comunità open source). Quando si rompe la fiducia, e in questo caso si è rotta, per ripristanarla occorre qualche passetto in più. A.
Ciao Antonio, Il giorno Fri, 31 May 2024 09:44:16 +0200 Antonio ha scritto:
L'open source è "fiducia"
Ma non era un modello di sviluppo che prescinde dalla fiducia? :-D ``` Why do people prefer using open source software? [...] Control. Many people prefer open source software because they have more control over that kind of software. They can examine the code to make sure it's not doing anything they don't want it to do, and they can change parts of it they don't like. [...] Security. Some people prefer open source software because they consider it more secure and stable than proprietary software. Because anyone can view and modify open source software, someone might spot and correct errors or omissions that a program's original authors might have missed. And because so many programmers can work on a piece of open source software without asking for permission from original authors, they can fix, update, and upgrade open source software more quickly than they can proprietary software. ``` https://opensource.com/resources/what-open-source
io mi fido degli altri sviluppatori perché do per scontato che agiscano come me, ovvero, da volontario, per il bene degli altri
In realtà, nessuna comunità funziona così. Le comunità si caratterizzano per le regole che proteggono un bene in comune (che può essere materiale o immateriale): ovvero l'esatto contrario di assumere che tutti i membri si comportino come si comporterebbe il più idealista e corretto dei membri. Se ti potessi fidare che nessuno ridurrà l'utilità del bene comune per gli altri, non avresti proprio bisogno di una comunità. Al contrario, proprio perché non puoi fidarti, hai bisogno di regole che limitino e vincolino l'accesso al bene in comune, in modo che nessuno ne possa ridurre l'utilità che questo ha per gli altri a proprio vantaggio.
Quando si rompe la fiducia, e in questo caso si è rotta, per ripristanarla occorre qualche passetto in più.
Direi questo caso evidenzia come si possa solo ripartire dal via. XZ è solo uno delle migliaia di software opensource compromessi, di cui ci siamo accorti solo per una serie incredibile di coincidenze. Che poi i software proprietari siano ancor più vulnerabili, è un'altra questione (piuttosto ovvia). Giacomo
Le comunità si caratterizzano per le regole che proteggono un bene in comune (che può essere materiale o immateriale): ovvero l'esatto contrario di assumere che tutti i membri si comportino come si comporterebbe il più idealista e corretto dei membri.
Regole? Non ti seguo. Cattedrale e non bazaar? Github, da quest'anno, ha introdotto l'autenticazione a due fattori per una maggiore protezione contro la compromissione degli account sfruttata per distribuire codice dannoso. E' servita? No. Se non ad abbandonare definitivamente Github (nel mio caso). Passare da Github a Gitlab può servire? Ci spostiamo su Radicle [1]? O ancora, ognuno con il suo portable GitHub, magari basato su gitprep [2]?. Tu cosa proponi? A. [1] https://radicle.xyz/ [2] https://github.com/yuki-kimoto/gitprep
Il giorno Fri, 31 May 2024 12:00:50 +0200 Antonio <antonio@piumarossa.it> ha scritto:
Le comunità si caratterizzano per le regole che proteggono un bene in comune (che può essere materiale o immateriale): ovvero l'esatto contrario di assumere che tutti i membri si comportino come si comporterebbe il più idealista e corretto dei membri.
Regole?
Già. Che si tratti di licenze, di statuti associativi o di consuetudini trasmesse oralmente (ma non meno inviolabili e vincolanti) le comunità non si caratterizzano tanto (o non solo) per il bene che mettono in comune (talvolta persino astratto e intangibile, come può essere la fede in una religione) ma dalle regole che si danno per custodirlo, per regolare l'accesso ad esso sia all'interno che dall'esterno della comunità stessa. Ti consiglio al riguardo il lavoro di Elinor Ostrom.
Cattedrale e non bazaar?
Anche il bazaar ha le sue regole. E scommetterei che le punizioni per i ladri sono... definitive. ;-)
Github, [...] Gitlab [...] Radicle [1]? [...] gitprep [2]?
Già che viriamo sul tecnico, io sto lavorando molto bene con Fossil https://fossil-scm.org Si tratta di un progetto veramente interessante, che NON si basa su git ed in effetti ha molti vantaggi sia tecnici che sociologici. Tuttavia Fossil non risponde alla tua domanda:
Tu cosa proponi?
Ho sono pieno di idee e proposte, sistemi operativi, linguaggi di programmazione, licenze... c'è tanto lavoro da fare. La meno eretica la conosci già: http://www.tesio.it/documents/HACK.txt Giacomo
participants (8)
-
380° -
Antonio -
D. Davide Lamanna -
Giacomo Tesio -
Italo Vignoli -
Marco A. Calamari -
maurizio lana -
Stefano Quintarelli