S3 Ep95: Slack leak, attacco di Github e crittografia post-quantistica [Audio + Text]

Fare clic e trascinare sulle onde sonore sottostanti per passare a qualsiasi punto. Puoi anche ascolta direttamente su Soundcloud.

DOUG.  Perdite lente, codice GitHub dispettoso e crittografia post-quantistica.

Tutto questo, e molto altro, nel podcast Naked Security.

[MODE MUSICALE]

Benvenuti nel podcast, a tutti.

Sono Doug Aamoth.

Con me, come sempre, c'è Paul Ducklin.

Paolo, come stai oggi?

---

ANATRA.  Super-duper, come al solito, Doug!

---

DOUG.  Sono super entusiasta di arrivare a quello di questa settimana Storia della tecnologia segmento, perché...

…tu eri lì, amico!

Questa settimana, l'11 agosto...

---

ANATRA.  Oh, no!

Penso che il centesimo sia appena caduto...

---

DOUG.  Non devo nemmeno dire l’anno!

11 agosto 2003: il mondo si accorge del worm Blaster, che colpisce i sistemi Windows 2000 e Windows XP.

Blaster, noto anche come Lovesan e MsBlast, sfruttava un buffer overflow ed è forse meglio conosciuto per il messaggio, “Billy Gates, perché lo rendi possibile? Smetti di fare soldi e aggiusta il tuo software.

Cos'è successo, Paolo?

---

ANATRA.  Beh, era l'era prima, forse, che prendessimo la sicurezza così seriamente.

E, fortunatamente, quel tipo di bug sarebbe molto, molto più difficile da sfruttare al giorno d'oggi: si trattava di un buffer overflow basato sullo stack.

E se ricordo bene, le versioni server di Windows erano già in fase di realizzazione con quello che viene chiamato protezione dello stack.

In altre parole, se si supera lo stack all'interno di una funzione, prima che la funzione ritorni e faccia il danno con lo stack danneggiato, rileverà che è successo qualcosa di brutto.

Quindi deve chiudere il programma incriminato, ma il malware non riesce a funzionare.

Ma a quel tempo quella protezione non era presente nelle versioni client di Windows.

E, se ricordo bene, era uno di quei primi malware che doveva indovinare quale versione del sistema operativo possedevi.

Sei sul 2000? Sei su NT? Hai XP?

E se sbagliasse, una parte importante del sistema si bloccherebbe e riceverai l'avviso "Il tuo sistema sta per spegnersi".

---

DOUG.  Ah, quelli li ricordo!

---

ANATRA.  Quindi, c'era quel danno collaterale che era, per molte persone, il segno che eri martellato dalle infezioni...

…che potrebbe provenire dall’esterno, ad esempio se fossi solo un utente domestico e non avessi un router o un firewall a casa.

Ma se fossi all'interno di un'azienda, l'attacco più probabile sarebbe arrivato da qualcun altro all'interno dell'azienda, che avrebbe sparso pacchetti sulla tua rete.

Quindi, proprio come l'attacco CodeRed di cui abbiamo parlato, avvenuto un paio di anni prima, in un recente podcast, il problema era proprio la portata, il volume e la velocità di questa cosa.

---

DOUG.  Va bene, è successo circa 20 anni fa.

E se torniamo indietro nel tempo a cinque anni fa, ecco quando Slack ha iniziato a perdere password con hash. [RISATA]

---

ANATRA.  Sì, Slack, il popolare strumento di collaborazione…

…ha una funzione in cui puoi inviare un collegamento di invito ad altre persone per unirsi al tuo spazio di lavoro.

E immagini: fai clic su un pulsante che dice "Genera un collegamento" e creerà una sorta di pacchetto di rete che probabilmente contiene del JSON al suo interno.

Se hai mai ricevuto un invito a una riunione Zoom, saprai che ha una data, un'ora, la persona che ti sta invitando, un URL che puoi utilizzare per la riunione, un passcode e tutto il resto roba – ci sono un sacco di dati lì dentro.

Normalmente, non si analizzano i dati grezzi per vedere cosa c'è dentro: il cliente dice semplicemente: "Ehi, ecco una riunione, ecco i dettagli. Vuoi accettare /Forse /Rifiutare?"

Si è scoperto che quando hai fatto questo con Slack, come dici tu, per più di cinque anni, in quell'invito c'erano dati estranei non strettamente rilevanti per l'invito stesso.

Quindi, non un URL, non un nome, non una data, non un'ora...

…ma *l’hash della password dell’utente invitante* [RISATA]

---

DOUG.  Hmmmmm.

---

ANATRA.  Non sto scherzando!

---

DOUG.  Suona male...

---

ANATRA.  Sì, lo fa davvero, non è vero?

La brutta notizia è: come diavolo è finito lì?

E, una volta lì dentro, come ha fatto a non farsi notare per cinque anni e tre mesi?

Infatti, se visiti l'articolo sulla Naked Security e guardi il file URL completo dell'articolo, noterai che alla fine dice: blahblahblah-for-three-months.

Perché, quando ho letto il rapporto per la prima volta, la mia mente non voleva vederlo come il 2017! [RISATA]

Era dal 17 aprile al 17 luglio, quindi c'erano molti "17" lì dentro.

E la mia mente ha cancellato il 2017 come anno di inizio: l'ho letto erroneamente come "da aprile a luglio *di quest'anno*" [2022].

Ho pensato: "Wow, *tre mesi* e non se ne sono accorti".

E poi il primo commento all'articolo è stato: “Ehm [TOSSE]. In realtà era il 17 aprile *2017*.”

Wow!

Ma qualcuno l'ha capito il 17 luglio [2022] e Slack, a suo merito, ha risolto il problema lo stesso giorno.

Tipo: "Oh, cavolo, a cosa stavamo pensando?!"

Quindi questa è la brutta notizia.

La buona notizia è che almeno si trattava di password con *hashing*.

E non sono stati semplicemente sottoposti ad hashing, sono stati *salati*, ovvero dove si mescolano dati casuali scelti in modo univoco per utente con la password.

L’idea è duplice.

Innanzitutto, se due persone scelgono la stessa password, non ottengono lo stesso hash, quindi non è possibile fare alcuna deduzione esaminando il database degli hash.

E due, non puoi precalcolare un dizionario di hash conosciuti per input noti, perché devi creare un dizionario separato per ogni password *per ogni salt*.

Quindi non è un esercizio banale decifrare le password con hash.

Detto questo, l’idea generale è che non dovrebbero essere una questione di dominio pubblico.

Vengono triturati e salati *nel caso* che perdessero, non *in modo che possano* perdere.

Quindi, uovo in faccia a Slack!

Slack afferma che circa un utente su 200, ovvero lo 0.5%, è stato colpito.

Ma se sei un utente Slack, suppongo che se non si fossero resi conto che stavano perdendo password con hash per cinque anni, forse non avrebbero nemmeno enumerato completamente l’elenco delle persone colpite.

Quindi, vai e cambia comunque la tua password... potresti anche farlo.

---

DOUG.  OK, diciamo anche: se non stai utilizzando un gestore di password, considera di procurartene uno; e attiva 2FA se puoi.

---

ANATRA.  Pensavo che ti sarebbe piaciuto, Doug.

---

DOUG.  Sì, certamente!

E poi, se sei Slack o un'azienda simile, scegli a algoritmo salt-hash-and-stretch affidabile quando gestisci le password da solo.

---

ANATRA.  Sì.

Il grosso problema nella risposta di Slack, e quello che pensavo mancasse, è che hanno semplicemente detto: "Non preoccuparti, non solo abbiamo crittografato le password, ma le abbiamo anche salate".

Il mio consiglio è che se ti trovi coinvolto in una violazione come questa, dovresti essere disposto a dichiarare l’algoritmo o il processo che hai utilizzato per il salting e l’hashing, e idealmente anche quello che viene chiamato stiramento, che è dove non si esegue l'hashing della password salata solo una volta, ma forse la si esegue 100,000 volte per rallentare qualsiasi tipo di dizionario o attacco di forza bruta.

E se indichi quale algoritmo stai utilizzando e con quali parametri... ad esempio, PBKDF2, bcrypt, scrypt, Argon2 – questi sono gli algoritmi “salt-hash-stretch” delle password più conosciuti in circolazione.

Se indichi effettivamente quale algoritmo stai utilizzando, allora: [A] sarai più aperto e [B] stai dando alle potenziali vittime del problema la possibilità di valutare da sole quanto pericoloso pensano che potrebbe essere stato .

E questo tipo di apertura può effettivamente aiutare molto.

Slack non l'ha fatto.

Hanno semplicemente detto: "Oh, erano salati e tritati".

Ma quello che non sappiamo è se hanno inserito due byte di sale e poi li hanno sottoposti ad hashing una volta con SHA-1...

…o avevano qualcosa di un po’ più resistente alla rottura?

---

DOUG.  Restando in tema di cose brutte, stiamo notando una tendenza in via di sviluppo in cui le persone lo sono iniettando cose cattive in GitHub, solo per vedere cosa succede, esponendosi al rischio...

… abbiamo un’altra di quelle storie.

---

ANATRA.  Sì, qualcuno che ora presumibilmente è uscito su Twitter e ha detto: “Non preoccupatevi ragazzi, non è stato fatto alcun male. Era solo per la ricerca. Scriverò un rapporto per distinguermi da Blue Alert.

Hanno creato letteralmente migliaia di progetti GitHub fasulli, basati sulla copia del codice legittimo esistente, inserendovi deliberatamente alcuni comandi malware, come "chiama a casa per ulteriori istruzioni" e "interpreta il corpo della risposta come codice backdoor da eseguire" e Presto.

Quindi, cose che potrebbero davvero causare danni se installassi uno di questi pacchetti.

Dare loro nomi dall'aspetto legittimo...

…prendendo in prestito, a quanto pare, la cronologia dei commit di un vero progetto in modo che la cosa sembrasse molto più legittima di quanto ci si potrebbe altrimenti aspettare se si presentasse semplicemente con “Ehi, scarica questo file. Lo sai che lo vuoi!"

Veramente?! Ricerca?? Non lo sapevamo già?!!?

Ora potresti obiettare: "Bene, Microsoft, proprietaria di GitHub, cosa sta facendo per rendere così facile per le persone caricare questo tipo di cose?"

E c’è del vero in questo.

Forse potrebbero fare un lavoro migliore nel tenere lontani i malware.

Ma è un po’ esagerato dire: “Oh, è tutta colpa di Microsoft”.

È ancora peggio, secondo me, dire: “Sì, questa è una ricerca genuina; questo è davvero importante; dobbiamo ricordare alla gente che questo potrebbe accadere.

Bene, [A] lo sappiamo già, grazie mille, perché un sacco di persone lo hanno già fatto; abbiamo ricevuto il messaggio forte e chiaro.

E [B] questa *non* è ricerca.

Si tratta di un tentativo deliberato di indurre le persone a scaricare codice che fornisce il controllo remoto a un potenziale aggressore, in cambio della possibilità di scrivere un rapporto.

A me sembra più una “grossa scusa” che una legittima motivazione per la ricerca.

E quindi la mia raccomandazione è, se pensi che questa *sia* ricerca, e se sei determinato a fare di nuovo qualcosa del genere, *non aspettarti molta simpatia* se vieni scoperto.

---

DOUG.  Va bene, torneremo su questo e i commenti dei lettori alla fine dello spettacolo, quindi restate qui.

Ma prima parliamo di semaforie cosa hanno a che fare con la sicurezza informatica.

---

ANATRA.  Ahhh, sì! [RIDERE]

Bene, c'è una cosa chiamata TLP, il Protocollo semaforico.

E il TLP è quello che potresti chiamare un "protocollo di ricerca sulla sicurezza informatica umana" che ti aiuta a etichettare i documenti che invii ad altre persone, per dare loro un suggerimento su ciò che speri che facciano (e, cosa più importante, cosa speri che facciano * not*) a che fare con i dati.

In particolare, quanto ampiamente dovrebbero ridistribuirlo?

È qualcosa di così importante da poterlo dichiarare al mondo?

Oppure è potenzialmente pericoloso o include potenzialmente alcune cose che non vogliamo che siano ancora pubbliche... quindi tienilo per te?

Ed è iniziato con: TLP:RED, che significava "Tienilo per te"; TLP:AMBER, che significava “Potete diffonderlo all'interno della vostra azienda o presso i vostri clienti che ritenete possano avere urgente bisogno di saperlo”; TLP:GREEN, che significava: "OK, puoi lasciare che questo circoli ampiamente all'interno della comunità della sicurezza informatica".

E altre ancora… TLP:WHITE, che significava: "Puoi dirlo a chiunque".

Molto utile, molto semplice: ROSSO, AMBRA, VERDE… una metafora che funziona globalmente, senza preoccuparsi di quale sia la differenza tra “segreto” e “confidenziale” e quale sia la differenza tra “confidenziale” e “classificato”, tutta quella roba complicata che ha bisogno di un sacco di leggi al riguardo.

Bene, il TLP ha appena ricevuto alcune modifiche.

Quindi, se ti interessa la ricerca sulla sicurezza informatica, assicurati di esserne a conoscenza.

TLP:WHITE è stato cambiato in quello che considero un termine molto migliore in realtà, perché bianca ha tutte queste sfumature culturali inutili di cui possiamo fare a meno nell’era moderna.

Così, TLP:WHITE è appena diventato TLP:CLEAR, che a mio avviso è una parola molto migliore perché dice: "Sei libero di utilizzare questi dati" e tale intenzione è dichiarata, ehm, molto chiaramente. (Scusate, non ho potuto resistere al gioco di parole.)

E c’è un livello aggiuntivo (quindi ha rovinato un po’ la metafora – ora è un semaforo colorato a *cinque* colori!).

C'è un livello speciale chiamato TLP:AMBER+STRICT, e ciò significa: "Puoi condividerlo all'interno della tua azienda".

Quindi potresti essere invitato a una riunione, forse lavori per un'azienda di sicurezza informatica, ed è abbastanza chiaro che dovrai mostrarlo ai programmatori, forse al tuo team IT, forse agli addetti al controllo qualità, in modo da poter fare ricerche su il problema o affrontarne la risoluzione.

Ma TLP:AMBER+STRICT significa che, sebbene tu possa diffonderlo all'interno della tua organizzazione, *per favore non dirlo ai tuoi clienti o ai tuoi clienti*, o anche a persone esterne all'azienda che ritieni possano aver bisogno di sapere.

Mantienilo all'interno della comunità più ristretta per cominciare.

TLP:AMBER, come prima, significa: "OK, se ritieni di dover dirlo ai tuoi clienti, puoi farlo".

E questo può essere importante, perché a volte potresti voler informare i tuoi clienti: “Ehi, stiamo arrivando la soluzione. Dovrai adottare alcune misure precauzionali prima che arrivi la soluzione. Ma poiché è una questione piuttosto delicata, possiamo chiederti di non dirlo ancora al mondo?"

A volte, raccontare il mondo troppo presto in realtà gioca più a favore dei truffatori che dei difensori.

Quindi, se sei un operatore della sicurezza informatica, ti suggerisco di andare: https://www.first.org/tlp

---

DOUG.  E tu puoi leggi di più su questo sul nostro sito, baresecurity.sophos.com.

E se stai cercando qualche altra lettura leggera, dimentica la crittografia quantistica... stiamo passando a crittografia post-quantistica, Paolo!

---

ANATRA.  Sì, ne abbiamo già parlato alcune volte nel podcast, vero?

L’idea di un computer quantistico, presupponendo che se ne possa costruire uno sufficientemente potente e affidabile, è che alcuni tipi di algoritmi potrebbero essere accelerati rispetto allo stato dell’arte odierno, sia in termini di radice quadrata… o, peggio ancora, di *logaritmo* della portata del problema oggi.

In altre parole, invece di prenderne 2²⁵⁶ tenta di trovare un file con un particolare hash, potresti riuscire a farlo semplicemente ("solo"!) 2¹²⁸ prova, che è la radice quadrata.

Chiaramente molto più veloce.

Ma c’è tutta una serie di problemi che coinvolgono la fattorizzazione di prodotti di numeri primi che secondo la teoria potrebbero essere risolti nel *logaritmo* del tempo che impiegano oggi, in parole povere.

Quindi, invece di prendere, diciamo, 2¹²⁸ giorni per crollare [MOLTO PIÙ LUNGO DELL’ETÀ ATTUALE DELL’UNIVERSO], potrebbero volerci solo 128 giorni per crollare.

Oppure puoi sostituire “giorni” con “minuti” o altro.

E sfortunatamente, quell'algoritmo temporale logaritmico (chiamato Algoritmo di fattorizzazione quantistica di Shor)… questo potrebbe essere, in teoria, applicato ad alcune delle tecniche crittografiche odierne, in particolare quelle utilizzate per la crittografia a chiave pubblica.

E, nel caso in cui questi dispositivi di calcolo quantistico diventino fattibili nei prossimi anni, forse dovremmo iniziare a prepararci ora per algoritmi di crittografia che non siano vulnerabili a queste due particolari classi di attacco?

In particolare quello logaritmico, perché accelera così tanto i potenziali attacchi che le chiavi crittografiche che attualmente pensiamo: "Beh, nessuno lo capirà mai", potrebbero diventare rivelabili in una fase successiva.

Comunque, NIST, il Istituto Nazionale di Standard e Tecnologie negli Stati Uniti, da diversi anni conduce un concorso per cercare di standardizzare alcuni algoritmi pubblici, non brevettati e ben controllati che saranno resistenti a questi magici computer quantistici, se mai si presentassero.

E recentemente hanno scelto quattro algoritmi su cui sono pronti a standardizzarsi ora.

Hanno nomi interessanti, Doug, quindi devo leggerli ad alta voce: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONe SPHINCS+. [RISATA]

Quindi hanno nomi interessanti, se non altro.

Ma, allo stesso tempo, il NIST ha pensato: “Beh, sono solo quattro algoritmi. Quello che faremo è sceglierne altri quattro come potenziali candidati secondari, e vedremo se anche qualcuno di questi dovrebbe passare”.

Quindi ci sono quattro algoritmi standardizzati ora e quattro algoritmi che potrebbero essere standardizzati in futuro.

Oppure *erano* quattro il 5 luglio 2022, e uno di loro lo era SIKE, abbreviazione di incapsulamento di chiavi isogeniche supersingolari.

(Avremo bisogno di diversi podcast per spiegare le isogenie supersingolari, quindi non ci preoccuperemo. [RISATA])

Ma, sfortunatamente, questo, che resisteva con la possibilità di essere standardizzato, sembra che sia stato irrimediabilmente rotto, nonostante sia già stato aperto al controllo pubblico per almeno cinque anni.

Quindi, fortunatamente, poco prima che venisse o potesse essere standardizzato, due crittografi belgi hanno capito: “Sai una cosa? Pensiamo di avere un modo per aggirare questo problema utilizzando calcoli che richiedono circa un’ora, su una CPU abbastanza media, utilizzando un solo core”.

---

DOUG.  Immagino sia meglio scoprirlo ora piuttosto che dopo averlo standardizzato e rilasciato in libertà?

---

ANATRA.  Infatti!

Immagino che se fosse stato uno degli algoritmi già standardizzati, avrebbero dovuto abrogare lo standard e inventarne uno nuovo?

Sembra strano che questo non sia stato notato per cinque anni.

Ma immagino che questa sia l’idea stessa del controllo pubblico: non si sa mai quando qualcuno potrebbe trovare la crepa che serve, o il piccolo cuneo che può usare per irrompere e dimostrare che l’algoritmo non è così forte come si pensava originariamente.

Un buon promemoria che se *mai* hai pensato di creare la tua crittografia...

---

DOUG.  [RISA] Non l’ho fatto!

---

ANATRA.  ..nonostante vi abbiamo detto N volte nel podcast Naked Security: "Non farlo!"

Questo dovrebbe essere l’ultimo promemoria del fatto che, anche quando veri esperti mettono a punto un algoritmo soggetto al controllo pubblico in una competizione globale per cinque anni, ciò non fornisce necessariamente abbastanza tempo per esporre difetti che si rivelano piuttosto gravi.

Quindi, certamente non sta andando bene per questo SIKE algoritmo.

E chissà, forse verrà ritirato?

---

DOUG.  Lo terremo d'occhio.

E mentre il sole tramonta lentamente sul nostro programma di questa settimana, è tempo di ascoltare uno dei nostri lettori sulla storia di GitHub di cui abbiamo discusso in precedenza.

rapinare scrive:

“C’è un po’ di gesso e formaggio nei commenti, e odio dirlo, ma riesco davvero a vedere entrambi i lati della questione. È pericoloso, fastidioso, fa perdere tempo e consuma risorse? Sì, certo che lo è. È quello che farebbero i tipi dalla mentalità criminale? Si si lo è. È un promemoria per chiunque utilizzi GitHub, o qualsiasi altro sistema di repository di codice, che viaggiare in sicurezza su Internet richiede un sano grado di cinismo e paranoia? SÌ. Come amministratore di sistema, una parte di me vuole applaudire l'esposizione del rischio a portata di mano. In qualità di amministratore di sistema di un gruppo di sviluppatori, ora devo assicurarmi che tutti abbiano recentemente esaminato eventuali voci discutibili."

---

ANATRA.  Sì, grazie, RobB, per questo commento, perché immagino sia importante vedere entrambi i lati della questione.

C’erano commentatori che dicevano semplicemente: “Che diavolo è il problema con questo? Questo è fantastico!”

Una persona ha detto, “No, in realtà questo test con penna è buono e utile. Sii felice che questi vengano smascherati ora invece di alzare la testa da un vero aggressore.

E la mia risposta è: “Beh, questo *è* un attacco, in realtà”.

È solo che qualcuno è uscito allo scoperto dopo, dicendo: “Oh, no, no. Nessun danno fatto! Onestamente, non ero cattivo.

Non penso che tu sia obbligato a comprare quella scusa!

Ma comunque non si tratta di test di penetrazione.

La mia risposta è stata quella di dire, molto semplicemente: "I penetration tester responsabili agiscono sempre e solo [A] dopo aver ricevuto il permesso esplicito, e [B] entro limiti comportamentali concordati esplicitamente in anticipo."

Non ti limiti a stabilire le tue regole e ne abbiamo già discusso in precedenza.

Quindi, come ha detto un altro commentatore, che è, credo, il mio commento preferito... Ecurb ha detto, “Penso che qualcuno dovrebbe andare di casa in casa e rompere le finestre per dimostrare quanto siano inefficaci le serrature delle porte. Questo è scaduto. Qualcuno ci salti sopra, per favore."

E poi, nel caso non vi foste accorti che quella era satira, gente, dice, "Non!"

---

ANATRA.  Ho l'idea che sia un buon promemoria e ho l'idea che se sei un utente GitHub, sia come produttore che come consumatore, ci sono cose che puoi fare.

Li elenchiamo nei commenti e nell'articolo.

Ad esempio, inserisci una firma digitale su tutti i tuoi commit in modo che sia ovvio che le modifiche provengono da te e che ci sia una sorta di tracciabilità.

E non consumare ciecamente cose solo perché hai fatto una ricerca e "sembrava" che potesse essere il progetto giusto.

Sì, tutti possiamo imparare da questo, ma questo conta davvero come un insegnamento o è solo qualcosa che dovremmo imparare comunque?

Penso che questo *non* sia insegnamento.

Semplicemente *non è di uno standard sufficientemente elevato* da poter essere considerato ricerca.

---

DOUG.  Ottima discussione su questo articolo e grazie per averlo inviato, Rob.

Se hai una storia, un commento o una domanda interessante che vorresti inviare, ci piacerebbe leggerla sul podcast.

Puoi inviare un'e-mail tips@sophos.com; puoi commentare uno qualsiasi dei nostri articoli; oppure puoi contattarci sui social: @NakedSecurity.

Questo è il nostro spettacolo per oggi – grazie mille per l'ascolto.

Per Paul Ducklin, sono Doug Aamoth e ti ricordo, alla prossima volta, di...

---

TUTTI E DUE.  Stai al sicuro!

[MODE MUSICALE]