S3 Ep112: Le violazioni dei dati possono perseguitarti più di una volta! [Audio + testo]

Timestamp: 9 dicembre 2022 11:46
Nodo di origine: 1769637
by

VIOLAZIONI DEI DATI – LA PASTIGLIA NELLA CODA

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

Con Doug Aamoth e Paul Ducklin. Musica introduttiva e finale di Edith Mudge.

Puoi ascoltarci su Soundcloud, Podcast Apple, Google Podcast, Spotify, Stitcher e ovunque si trovino buoni podcast. O semplicemente rilascia il URL del nostro feed RSS nel tuo podcatcher preferito.

LEGGI LA TRASCRIZIONE

DOUG.  Scambio di SIM, zero-days, la [voce drammatica] Ping of DEATH e LastPass... di nuovo.

Tutto questo e molto altro sul podcast Naked Security.

[MODE MUSICALE]

Benvenuti al podcast a tutti.

Sono Doug Aamoth.

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

Paolo, come stai?

ANATRA.  Molto bene, Doug.

Hai messo un po' di suono drammatico in quell'introduzione, mi fa piacere vedere!

DOUG.  Bene, come si dice "Ping of Death" senza dire [ringhio doom metal] "Ping of DEATH"?

Non puoi semplicemente dire [voce gentile] "Ping of Death".

Devi picchiarlo un po'...

ANATRA.  Suppongo di sì.

È diverso nella scrittura: cosa hai?

Grassetto e corsivo.

Sono andato solo con il testo normale, ma ho usato lettere maiuscole, il che aiuta.

DOUG.  Sì, penso che metterei in grassetto e in corsivo la parola "death", quindi [di nuovo doom metal] "The Ping of DEATH".

ANATRA.  E usa più colori!

Lo farò la prossima volta, Doug.

DOUG.  Rompi il vecchio tag in HTML, farlo lampeggiare un po'? [RIDE]

ANATRA.  Doug, per un momento, ero preoccupato che avresti usato la parola [RISATA] .

DOUG.  [RISATA] Adoriamo le cose vecchie qui!

E questo combacia perfettamente con il nostro Questa settimana nella storia della tecnologia segmento - Sono entusiasta di questo perché non ne avevo sentito parlare, ma mi sono imbattuto in esso.

Questa settimana, il 04 dicembre 2001, il worm Goner ha saccheggiato Internet a un ritmo secondo solo a quello del virus Love Bug.

Goner si è diffuso tramite Microsoft Outlook e ha promesso alle vittime ignare un divertente salvaschermo quando eseguito.

ANATRA.  Andato…

Penso che abbia preso quel nome perché c'era un popup alla fine, non c'era, che menzionava il Pentagono?

Ma doveva essere un gioco di parole: era "Penta/Gone".

Questo è stato certamente il worm che ha ricordato alla gente che, in realtà, gli screensaver di Windows sono solo programmi eseguibili.

Quindi, se stavi cercando appositamente per .EXE file, beh, potrebbero essere racchiusi in .SCR (salvaschermo) anche i file.

Se facessi affidamento solo sui nomi dei file, potresti facilmente essere ingannato.

E molte persone lo erano, purtroppo.

DOUG.  Va bene, passeremo dalla vecchia scuola alla nuova scuola.

Stiamo parlando di LastPass: c'è stata una breccia; la breccia in sé non era terribile; ma quella violazione ora ha portato a un'altra violazione.

O forse questa è solo una continuazione della violazione originale?

LastPass ammette la violazione dei dati dei clienti causata da precedenti violazioni

ANATRA.  Sì, LastPass ne ha scritto essenzialmente come seguito alla violazione precedente, che penso fosse agosto 2022, non è vero?

E come abbiamo detto all'epoca, è stato un aspetto molto imbarazzante per LastPass.

Ma con l'avanzare delle violazioni, probabilmente è stato peggio per le loro pubbliche relazioni, il marketing e (immagino) per i loro dipartimenti di proprietà intellettuale, perché sembra che la cosa principale che i truffatori hanno eliminato sia il codice sorgente del loro sistema di sviluppo.

E LastPass si è affrettato a rassicurare le persone...

In primo luogo, le loro indagini hanno suggerito che, mentre erano lì, i truffatori non erano in grado di apportare modifiche non autorizzate che avrebbero potuto in seguito penetrare nel codice reale.

In secondo luogo, l'accesso al sistema di sviluppo non ti dà accesso al sistema di produzione, dove viene creato il codice vero e proprio.

E in terzo luogo, sono stati in grado di affermare che sembrava che non fosse stato rubato alcun deposito di password crittografato, quindi non è stato possibile accedere all'archivio cloud delle password crittografate.

E anche se fosse stato effettuato l'accesso, solo tu sapresti la password, perché la decrittazione (quello che hai definito il "lavoro pesante" quando ne abbiamo parlato nel podcast) viene effettivamente eseguita in memoria sui tuoi dispositivi: LastPass non vede mai il tuo parola d'ordine.

E poi, in quarto luogo, hanno detto, per quanto ne sappiamo, come risultato di quella violazione, alcune delle cose che erano nell'ambiente di sviluppo ora hanno dato lo stesso... o forse un carico completamente diverso di truffatori che hanno comprato il dati rubati dal lotto precedente, chi lo sa?

Ciò ha permesso loro di entrare in un servizio cloud in cui è stato rubato un set di dati dei clienti apparentemente sconosciuto.

Non credo che lo sappiano ancora del tutto, perché può volerci un po' di tempo per capire a cosa è stato effettivamente effettuato l'accesso dopo che si è verificata una violazione.

Quindi penso che sia giusto dire che questo è una specie di lato B della violazione originale.

DOUG.  Va bene, suggeriamo che se sei un cliente LastPass, di tenere d'occhio il rapporto sugli incidenti di sicurezza dell'azienda.

Terremo d'occhio questa storia mentre è ancora in via di sviluppo.

E se tu, come me e Paul, combatti il ​​crimine informatico per vivere, ci sono alcune lezioni eccellenti da imparare dalla violazione di Uber.

Quindi questo è un episodio del podcast - un "minisodio" - con Chester Wisniewski che Paul ha inserito in fondo all'articolo di LastPass:

S3 Ep100.5: Violazione Uber – parla un esperto [Audio + Testo]

C'è molto da imparare su questo fronte!

ANATRA.  Come dici tu, è un ottimo ascolto, perché è, credo, ciò che in America è noto come "consiglio attuabile" o "notizie che puoi usare".

DOUG.  [RISATA] Meraviglioso.

A proposito di notizie che non puoi davvero usare, Apple è generalmente a bocca aperta sui suoi aggiornamenti di sicurezza ... e c'è stato un aggiornamento di sicurezza:

Apple lancia l'aggiornamento di sicurezza iOS che è più riservato che mai

ANATRA.  Oh, Doug, è uno dei tuoi migliori... mi piace quel seguito.

DOUG.  [RISATA] Grazie; Grazie mille.

ANATRA.  Sì, questo mi ha sorpreso.

Ho pensato: "Bene, prenderò l'aggiornamento perché sembra serio".

E mi sono dato il motivo: "Lasciamelo fare per i lettori di Naked Security".

Perché se lo faccio e non ci sono effetti collaterali, allora posso almeno dire ad altre persone: “Guarda, l'ho fatto alla cieca e non mi è venuto alcun danno. Quindi forse puoi farlo anche tu.

All'improvviso ho notato che era disponibile un aggiornamento iOS 16.1.2, anche se non avevo ricevuto e-mail di avviso di sicurezza da Apple.

Nessuna e-mail?!

È strano... così sono andato al HT201222 pagina del portale che Apple ha per i suoi bollettini sulla sicurezza, ed eccolo lì: iOS 16.1.2.

E cosa dice, Doug, "I dettagli seguiranno presto"?

DOUG.  E hanno seguito presto?

ANATRA.  Bene, è successo più di una settimana fa e non sono ancora arrivati.

Quindi stiamo parlando di "presto" che significa ore, giorni, settimane o mesi?

Al momento, sembrano settimane.

E, come sempre con Apple, non c'è alcuna indicazione di nulla a che fare con altri sistemi operativi.

Sono stati dimenticati?

Non hanno bisogno dell'aggiornamento?

Avevano anche bisogno dell'aggiornamento, ma non è ancora pronto?

Sono stati abbandonati dal supporto?

Ma sembrava, come ho detto nel titolo, ancora più riservato del solito per Apple, e non necessariamente la cosa più utile al mondo.

DOUG.  OK, molto bene... ancora alcune domande, che ci portano alla nostra prossima storia.

Una domanda molto interessante!

A volte, quando ti iscrivi a un servizio e applica l'autenticazione a due fattori, dice: "Vuoi ricevere una notifica tramite messaggio di testo o vuoi utilizzare un'app di autenticazione?"

E questa storia è un ammonimento a non usare il telefono: usa un'app di autenticazione, anche se è un po' più macchinosa.

Questa è una storia molto interessante:

Scambiatore di SIM mandato in prigione per un furto di criptovaluta 2FA di oltre $ 20 milioni

ANATRA.  Lo è, Douglas!

Se ti è mai capitato di perdere un telefono cellulare o di rimanere bloccato fuori dalla tua carta SIM inserendo il PIN in modo errato troppe volte, saprai che puoi andare nel negozio di telefonia mobile...

... e di solito chiedono un documento d'identità o qualcosa del genere, e tu dici: "Ehi, ho bisogno di una nuova scheda SIM".

E ne genereranno uno per te.

Quando lo metti nel tuo telefono, bingo!... c'è il tuo vecchio numero sopra.

Quindi ciò significa che se un truffatore può eseguire lo stesso esercizio che faresti tu per convincere la compagnia di telefonia mobile che ha "perso" o "rotto" la sua carta SIM (cioè *la tua carta SIM*), e possono ottenere quella carta consegnata, o inviata, o data loro in qualche modo...

… poi, quando lo collegano al loro telefono, iniziano a ricevere i tuoi codici di autenticazione a due fattori via SMS, *e* il tuo telefono smette di funzionare.

Questa è la cattiva notizia.

La buona notizia in questo articolo è che si trattava di un tizio che è stato beccato per questo.

È stato mandato in prigione negli Stati Uniti per 18 mesi.

Lui, con un mucchio di complici – o, nelle parole del Dipartimento di Giustizia, il Partecipanti al programma… [RIDE]

… se ne sono andati con la criptovaluta di una particolare vittima, apparentemente per un importo di $ 20 milioni, se non ti dispiace.

DOUG.  uff!

ANATRA.  Quindi ha accettato di dichiararsi colpevole, prendere una pena detentiva e rinunciare immediatamente ... l'importo era [leggendo attentamente] $ 983,010.72 ... solo per rinunciare immediatamente.

Quindi, presumibilmente, ce l'aveva in giro.

E a quanto pare ha anche una sorta di obbligo legale di rimborsare oltre $ 20 milioni.

DOUG.  Buona fortuna a tutti! Buona fortuna.

I suoi altri [corsivo vocale] Partecipanti al programma potrebbe causare alcuni problemi lì! [RIDE]

ANATRA.  Sì, non so cosa succede se anche loro si rifiutano di collaborare.

Ad esempio, se lo appendono ad asciugare, cosa succede?

Ma abbiamo alcuni suggerimenti e alcuni consigli su come rafforzare la sicurezza (in più modi rispetto al semplice 2FA che usi) nell'articolo.

Quindi vai a leggere che... ogni piccola cosa aiuta.

DOUG.  OK, parlando di "piccoli pezzi"...

…questa era un'altra storia affascinante, come gli umili ping può essere utilizzato per attivare l'esecuzione di codice remoto:

Ping di morte! FreeBSD corregge bug crashtastic nello strumento di rete

ANATRA.  [Mi piace di nuovo il seguito] Penso che tu sia migliorato, Doug!

DOUG.  [RISATA] Oggi sono su un tiro...

ANATRA.  Da Apple al [debole tentativo di voce doom] Ping of DEATH!

Sì, questo era un bug intrigante.

Non penso che causerà davvero molto danno a molte persone, ed è *è* patchato, quindi risolverlo è facile.

Ma c'è un'ottima recensione su FreeBSD consulenza sulla sicurezza...

... e crea un racconto divertente e, se lo dico io stesso, molto istruttivo per l'attuale generazione di programmatori che potrebbero aver fatto affidamento su "Le librerie di terze parti lo faranno solo per me. Hai a che fare con pacchetti di rete di basso livello? Non devo mai pensarci…”

Ci sono alcune grandi lezioni da imparare qui.

I ping utility, che è l'unico strumento di rete che praticamente tutti conoscono, prende il nome da SONAR.

Vai [fa il rumore del sottomarino del film] ping, quindi l'eco ritorna dal server all'altra estremità.

E questa è una funzionalità integrata nel protocollo Internet, IP, utilizzando una cosa chiamata ICMP, che è Internet Control Message Protocol.

È uno speciale protocollo di basso livello, molto più basso di UDP o TCP a cui le persone sono probabilmente abituate, che è praticamente progettato esattamente per questo genere di cose: "Sei davvero vivo dall'altra parte, prima che mi preoccupi del perché il tuo server web non funziona?"

C'è un tipo speciale di pacchetto che puoi inviare chiamato "ICMP Echo".

Quindi, invii questo minuscolo pacchetto con un breve messaggio (il messaggio può essere qualsiasi cosa ti piaccia) e ti invia semplicemente lo stesso messaggio.

È solo un modo semplice per dire: "Se quel messaggio non ritorna, o la rete o l'intero server è inattivo", piuttosto che c'è qualche problema software sul computer.

Per analogia con SONAR, il programma che invia queste richieste di eco si chiama... [pausa] Farò l'effetto sonoro, Doug... [di nuovo il finto rumore del sottomarino] ping. [RISATA]

E l'idea è, tu vai, diciamo, ping -c3 (ciò significa controllare tre volte) nakedsecurity.sophos.com.

Puoi farlo adesso e dovresti ricevere tre risposte, ciascuna a distanza di un secondo, dai server WordPress che ospitano il nostro sito.

E sta dicendo che il sito è vivo.

Non ti sta dicendo che il server web è attivo; non ti sta dicendo che WordPress è attivo; non sta dicendo che Naked Security sia effettivamente disponibile per la lettura.

Ma almeno conferma che puoi vedere il server e che il server può raggiungerti.

E chi avrebbe mai pensato che quell'umile piccola risposta al ping potesse far inciampare FreeBSD ping programmare in modo tale che un server non autorizzato possa restituire un messaggio "Sì, sono vivo" con trappola esplosiva che potrebbe, in teoria (solo in teoria; non credo che qualcuno l'abbia fatto in pratica) innescare l'esecuzione di codice remoto su il tuo computer.

DOUG.  Sì, è fantastico; questa è la parte sorprendente.

Anche se è una prova di concetto, è una cosa così piccola!

ANATRA.  I ping il programma stesso recupera l'intero pacchetto IP e dovrebbe dividerlo in due parti.

Normalmente, il kernel lo gestirebbe per te, quindi vedresti solo la parte dei dati.

Ma quando hai a che fare con quelli che vengono chiamati prese grezze, ciò che ottieni è l'intestazione del protocollo Internet, che dice semplicemente: "Ehi, questi byte provengono da questo o quel server".

E poi ottieni una cosa chiamata "ICMP Echo Reply", che è la seconda metà del pacchetto che ricevi.

Ora, questi pacchetti, in genere sono solo 100 byte o giù di lì, e se è IPv4, i primi 20 byte sono l'intestazione IP e il resto, qualunque cosa sia, è la risposta Echo.

Ha pochi byte per dire "Questa è una risposta Echo", e poi il messaggio originale che è uscito tornando indietro.

E quindi la cosa ovvia da fare, Doug, quando lo ottieni, è dividerlo in...

…l'intestazione IP, lunga 20 byte, e il resto.

Indovina dove sta il problema?

DOUG.  Dillo!

ANATRA.  Il problema è che le intestazioni IP sono *quasi sempre* lunghe 20 byte – infatti, non credo di averne mai visto uno che non lo fosse.

E puoi dire che sono lunghi 20 byte perché il primo byte sarà esadecimale 0x45.

Il "4"" significa IPv4, e il "5"... "Oh, lo useremo per dire quanto è lunga l'intestazione."

Prendi quel numero 5 e lo moltiplichi per 4 (per valori a 32 bit) e ottieni 20 byte..

... e questa è la dimensione di probabilmente sei sigma di intestazioni IP che vedrai mai in tutto il mondo, Doug. [RISATA]

Ma *possono* arrivare fino a 60 byte.

Se metti 0x4F invece di 0x45, che dice che ci sono 0xF (o 15 in decimale) × 4 = 60 byte nell'intestazione.

E il codice di FreeBSD ha semplicemente preso quell'intestazione e l'ha copiata in un buffer sullo stack che aveva una dimensione di 20 byte.

Un semplice overflow del buffer dello stack della vecchia scuola.

Si tratta di un venerabile strumento per la risoluzione dei problemi di rete con un venerabile tipo di bug al suo interno. (Beh, non più.)

Quindi, quando stai programmando e hai a che fare con cose di basso livello a cui nessuno ha davvero pensato per anni, non limitarti ad andare con la saggezza ricevuta che dice: “Oh, saranno sempre 20 byte; non vedrai mai niente di più grande.

Perché un giorno potresti.

E quando quel giorno verrà, potrebbe essere lì deliberatamente perché un truffatore l'ha fatto apposta.

Quindi il diavolo, come sempre, è nei dettagli della programmazione, Doug.

DOUG.  OK, molto interessante; grande storia.

E resteremo sull'argomento del codice con questa storia finale su Chrome.

Un altro zero-day, che porta a nove volte il totale del 2022:

Numero nove! Chrome corregge un altro zero-day del 2022, anche Edge patchato

ANATRA.  [Voce formale, che suona come una registrazione] "Numero 9. Numero 9. Numero 9, numero 9", Douglas.

DOUG.  [RISATA] Questa è Yoko Ono?

ANATRA.  Questo è Rivoluzione 9 dal “White Album” dei Beatles.

Yoko può essere ascoltata riffing in quella canzone - quella soundscape, Credo che lo chiamino – ma a quanto pare il pezzo all'inizio in cui c'è qualcuno che dice "Numero 9, numero 9" più e più volte, era, in effetti, un nastro di prova che hanno trovato in giro.

DOUG.  Ah, molto bello.

ANATRA.  Un ingegnere della EMI che dice qualcosa del tipo: "Questo è il nastro di prova della EMI numero 9" [RISATA], ea quanto pare non credo nemmeno che nessuno sappia di chi fosse la voce.

Questo *niente* ha a che fare con Chrome, Doug.

Ma dato che qualcuno ha commentato su Facebook l'altro giorno, "Quel ragazzo di Paul sta iniziando a sembrare un Beatle"... [interrogativo] che ho trovato un po' strano.

DOUG.  [RISATA] Sì, come dovresti prenderla?

ANATRA.  …Ho pensato che avrei potuto cenare fuori al “Numero 9”.

Finora è il nono giorno zero dell'anno, a quanto pare, Doug.

Ed è una correzione di un bug, con il bug identificato come CVE 2022-4282.

Poiché Microsoft Edge utilizza il core open source Chromium, anch'esso era vulnerabile e, un paio di giorni dopo, Microsoft ha seguito un aggiornamento per Edge.

Quindi questo è sia un problema di Chrome che di Edge.

Anche se quei browser dovrebbero aggiornarsi da soli, ti consiglio di controllare comunque - ti mostriamo come farlo nell'articolo - per ogni evenienza.

Non leggerò i numeri di versione qui perché sono diversi per Mac, Linux e Windows su Chrome, e sono ancora diversi per Edge.

Come Apple, Google è un po' riservato su questo.

È stato trovato da una delle loro squadre di cacciatori di minacce, credo.

Quindi immagino che l'abbiano trovato mentre indagavano su un incidente accaduto in natura, e quindi probabilmente vogliono tenerlo sotto il cappello, anche se Google di solito ha molto da dire sull'"apertura" quando si tratta di correggere i bug.

Puoi capire perché, in un caso come questo, potresti aver bisogno di un po' di tempo per scavare un po' più a fondo prima di dire a tutti esattamente come funziona.

DOUG.  Eccellente... e abbiamo una domanda del lettore che probabilmente è una domanda a cui molte persone stanno pensando.

Cassandra chiede: "I cercatori di bug sono solo fortunati a trovare bug? O hanno colpito una "cucitura" piena di bug? O Chromium sta emettendo un nuovo codice che presenta più bug del normale? O sta succedendo qualcos'altro?"

ANATRA.  Sì, questa è un'ottima domanda, in realtà, e temo di poter rispondere solo in modo un po' scherzoso, Doug.

Poiché Cassandra aveva dato le scelte A), B) e C), ho detto: “Beh, forse lo è D) Tutto quanto sopra."

Sappiamo che quando un bug di un particolare tipo compare nel codice, allora è ragionevole presumere che lo stesso programmatore possa aver creato bug simili altrove nel software.

Oppure altri programmatori della stessa azienda potrebbero aver utilizzato quella che all'epoca era considerata saggezza consolidata o pratica standard e potrebbero aver seguito l'esempio.

E un ottimo esempio è che, se guardi indietro a Log4J ... c'era una soluzione per correggere il problema.

E poi, quando sono andati a cercare, "Oh, in realtà, ci sono altri posti in cui sono stati commessi errori simili".

Quindi c'era una correzione per la correzione, e poi c'era una correzione per la correzione per la correzione, se ricordo bene.

C'è, ovviamente, anche il problema che quando aggiungi nuovo codice, potresti ottenere bug che sono unici per quel nuovo codice e che si verificano a causa dell'aggiunta di funzionalità.

Ed è per questo che molti browser, incluso Chrome, hanno una versione "leggermente più vecchia" se ti piace con cui puoi restare.

E l'idea è che quelle "vecchie" versioni... non abbiano nessuna delle nuove funzionalità, ma tutte le relative correzioni di sicurezza.

Quindi, se vuoi essere prudente riguardo alle nuove funzionalità, puoi esserlo.

Ma certamente sappiamo che, a volte, quando inserisci nuove funzionalità in un prodotto, nuovi bug arrivano con le nuove funzionalità.

E puoi dirlo, ad esempio, quando c'è un aggiornamento, diciamo, per il tuo iPhone, e ricevi aggiornamenti, diciamo, per iOS 15 e iOS 16.

Quindi, quando guardi gli elenchi di bug, ci sono alcuni bug che si applicano solo a iOS 16.

E pensi: "Ciao, quelli devono essere bug nel codice che prima non c'erano".

Quindi, sì, questa è una possibilità.

E penso che le altre cose che stanno succedendo possano essere considerate buone.

Il primo è che penso che, in particolare per cose come i browser, i produttori di browser stiano migliorando molto nel distribuire ricostruzioni complete molto, molto rapidamente.

DOUG.  Interessante.

ANATRA.  E penso che l'altra cosa che è cambiata sia che, in passato, si potrebbe obiettare che per molti venditori... era abbastanza difficile convincere le persone ad applicare le patch, anche quando uscivano solo su base mensile, e anche se contenevano più correzioni zero-day.

Penso che forse sia anche una risposta al fatto che sempre più persone sono sempre più propense non solo ad accettare, ma addirittura ad *aspettarsi* un aggiornamento automatico che sia davvero tempestivo.

Quindi, penso che tu possa leggere alcune cose buone in questo.

Il fatto non solo che Google può distribuire quasi istantaneamente una singola correzione zero-day, ma anche che le persone sono disposte ad accettarlo e persino a richiederlo.

Quindi mi piace vedere quel numero di "Wow, nove giorni zero nell'anno fissati individualmente!"...

…Mi piace pensarlo più come “bicchiere mezzo pieno e pieno” che “bicchiere mezzo vuoto e scolare attraverso un piccolo foro sul fondo”. [RISATA]

Questa è la mia opinione.

DOUG.  Va bene, molto bene.

Grazie per la domanda, Cassandra.

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

Puoi inviare un'e-mail a tips@sophos.com, commentare uno qualsiasi dei nostri articoli o contattarci sui social: @NakedSecurity.

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

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

TUTTI E DUE.  Stai al sicuro!

[MODE MUSICALE]

Timestamp:

Di più da Sicurezza nuda