nexa

By thread

nexa@server-nexa.polito.it

40 participants
30621 messages

22 aprile 2024 alle ore 16 Tavola rotonda"La protezione dei dati personali e la transizione digitale: le sfide attuali e future

by Mauro Alovisio

Gent.mi segnalo la tavola rotonda: "*La protezione dei dati personali e la transizione digitale: le sfide attuali e future" *che si terrà lunedì 22 aprile alle ore 16 a Torino presso aula magna del Campus Luigi Einaudi, Lungo Dora Siena 100 Saluti istituzionali : *Prof. Raffaele Caterina* , Direttore del Dipartimento di Giurisprudenza *Avv. Simona Grabbi,* Presidente dell’Ordine degli Avvocati di Torino *Dott.ssa Paola Zambon,* Referente GDPR - Ordine Dottori commercialisti ed esperti Contabili di Torino Dott. Fabrizio Bontempo, Presidente Ordine Consulenti del lavoro * Intervengono Prof. Francesco Pizzetti, Università degli Studi di Torino * *Prof. Sergio Foà*, Università degli Studi di Torino *Dott. Agostino Giglia*, componente dell'Autorità Garante per la protezione dei dati personali Avv.* Laura Marengo, *Unione industriali di Torino; *Avv. Mauro Alovisio*- Università degli Studi di Torino *Ing. Angelo Sacc*à direttore sistemi informativi Università di Torino E' gradita l'iscrizione tramite form onlineopen_in_new <https://forms.gle/HFet7kXSZ5jwLfLKA>. L'evento è accreditato per la formazione obbligatoria per gli avvocati *Durante la tavola rotonda sarà presentata la sesta edizione del corso:"Compliance dei dati e della protezione dei dati personali nella transizione digitale.* *Il corso sarà erogato sia in presenza che on line ed è accreditato per la formazione obbligatoria per avvocati* Qualora impossibilitati potete seguire on line Qui il sito dove saranno pubblicate nei prossimi giorni le informazioni su scadenze, costi iscrizioni https://www.giurisprudenza.unito.it/do/home.pl/View?doc=data_protection_off… Grazie per l'attenzione Un caro saluto Mauro Alovisio

April 12, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) rapido commento e preghiera.

by Antonio

> 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.… [3] https://techrights.org/n/2024/04/02/Richard_Stallman_Was_Right_and_What_Hap…

April 12, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) rapido commento e preghiera.

by D. Davide Lamanna

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)

April 12, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) rapido commento e preghiera.

by 380°

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>.

April 12, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)

by Marco A. Calamari

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-larmageddo… > > < > > https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddo… > > > > > > > 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(a)marcoc.it <mailto:marcoc_maillist@marcoc.it>> > > > > _______________________________________________ > > nexa mailing list > > nexa(a)server-nexa.polito.it > > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 11, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)

by Stefano Quintarelli

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-larmageddo… <https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddo…> > > 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(a)marcoc.it <mailto:marcoc_maillist@marcoc.it>> > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 11, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)

by Marco A. Calamari

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-larmageddo… 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(a)marcoc.it>

April 11, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)

by Italo Vignoli

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-… >> >> «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(a)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(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa -- Italo Vignoli - italo(a)vignoli.org mobile/signal +39.348.5653829 GPG Key ID - 0xAAB8D5C0 DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0

April 11, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)

by maurizio lana

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-… > > «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(a)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

April 11, 2024

[CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)

by 380°

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-… «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>.

April 11, 2024

Jump to page: