S3 Ep108: Hai nascosto TRE MILIARDI di dollari in una scatola di popcorn?

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

DOUG.  Truffe su Twitter, Patch Tuesday e criminali che hackerano i criminali.

Tutto questo e molto altro sul podcast Naked Security.

[MODE MUSICALE]

Benvenuti nel podcast, a tutti.

Sono Doug.

Lui è Paul Ducklin.

Paolo, come stai oggi?

---

ANATRA.  Molto bene, Doug.

Non abbiamo avuto l'eclissi lunare qui in Inghilterra, ma ho avuto un breve assaggio della *piena* luna piena attraverso un minuscolo spazio tra le nuvole che è emerso come l'unico buco nell'intero strato di nuvole nel momento in cui sono uscito per dare un'occhiata!

Ma non avevamo quella luna arancione come voi ragazzi nel Massachusetts.

---

DOUG.  Iniziamo lo spettacolo con Questa settimana nella storia della tecnologia... questo risale a molto tempo fa.

Questa settimana, l'08 novembre 1895, il professore di fisica tedesco Wilhelm Röntgen si imbatté in una forma di radiazione ancora sconosciuta che lo spinse a riferirsi a detta radiazione semplicemente come "X".

Come nei raggi X.

Che ne dici di... la scoperta accidentale dei raggi X?

---

ANATRA.  Abbastanza sorprendente

Ricordo che mia madre mi diceva: negli anni '1950 (deve essere stato lo stesso negli States), a quanto pare, nei negozi di scarpe...

---

DOUG.  [SA COSA STA ARRIVANDO] Sì! [RIDE]

---

ANATRA.  La gente prendeva i propri figli... tu stavi in ​​questa macchina, ti mettevi le scarpe e invece di dire semplicemente: "Cammina in giro, sono stretti? Ti pizzicano?", eri in una macchina a raggi X, che praticamente ti ha immerso nelle radiazioni di raggi X e ha scattato una foto dal vivo e hai detto: "Oh sì, sono della giusta dimensione".

---

DOUG.  Sì, tempi più semplici. Un po' pericoloso, ma...

---

ANATRA.  UN PICCOLO PERICOLO?

Riesci a immaginare le persone che lavoravano nei negozi di scarpe?

Devono aver fatto il bagno ai raggi X tutto il tempo.

---

DOUG.  Assolutamente... beh, oggi siamo un po' più al sicuro.

E in tema di sicurezza, il primo martedì del mese è il Patch Tuesday di Microsoft.

So cosa abbiamo imparato questo Patch Tuesday qui a novembre 2022?

Scambio 0 giorni fissi (finalmente) – più 4 nuovissimi giorni Patch Martedì 0!

---

ANATRA.  Bene, la cosa super eccitante, Doug, è che tecnicamente Patch Tuesday non ha risolto uno, non due, non tre... ma *quattro* zero-day.

Ma in realtà le patch che potresti ottenere per i prodotti Microsoft martedì hanno fissato *sei* zero-day.

Ricorda quegli zero-day di Exchange che notoriamente non sono stati aggiornati lo scorso Patch Tuesday: CVE-2002-41040 e CVE-2022-41082, quelli che sono diventati noti come ProxyNotShell?

S3 Ep102.5: Bug di scambio “ProxyNotShell” – parla un esperto [Audio + Testo]

Bene, quelli sono stati risolti, ma essenzialmente in una "linea laterale" separata per Patch Tuesday: Exchange November 2022 SU, o Software Update, che dice semplicemente:

Gli aggiornamenti software di Exchange di novembre 2022 contengono correzioni per le vulnerabilità zero-day segnalate pubblicamente il 29 settembre 2022.

Tutto quello che devi fare è aggiornare Exchange.

Accidenti, grazie Microsoft... Penso che sapessimo che era quello che avremmo dovuto fare quando finalmente le patch sarebbero uscite!

Quindi, *sono* fuori e ci sono due giorni zero fissi, ma non sono nuovi e tecnicamente non sono nella parte "Patch Tuesday".

Lì, abbiamo altri quattro giorni zero fissi.

E se credi nella priorità delle patch, allora ovviamente quelle sono quelle che vuoi affrontare per prime, perché qualcuno sa già come fare cose cattive con loro.

Questi vanno da un bypass di sicurezza, a due elevazioni di privilegi e un'esecuzione di codice remoto.

Ma ce ne sono di più 60 patch in totalee se guardi l'elenco generale dei prodotti e dei componenti Windows interessati, c'è un elenco enorme, come al solito, che include tutti i componenti/prodotti Windows di cui hai sentito parlare e molti probabilmente no.

Microsoft corregge 62 vulnerabilità, tra cui Kerberos, Mark of the Web ed Exchange... più o meno

Quindi, come sempre: Non ritardare/Fallo oggi, Douglas!

---

DOUG.  Molto buono.

Parliamo ora di un bel ritardo...

Hai una storia molto interessante sul Mercato della droga della Via della Setae un promemoria che i criminali che rubano ai criminali sono ancora un crimine, anche se sono passati circa dieci anni da quando sei effettivamente catturato per questo.

L'hacker del mercato della droga di Silk Road si dichiara colpevole, deve affrontare 20 anni dentro

---

ANATRA.  Sì, anche le persone che sono abbastanza nuove alla sicurezza informatica o all'online probabilmente avranno sentito parlare di "Via della seta", forse il primo mercato del dark web noto, grande, diffuso e ampiamente utilizzato in cui praticamente tutto è permesso.

Quindi, tutto è andato in fiamme nel 2013.

Perché il fondatore, originariamente conosciuto solo come Il terribile pirata Roberts, ma alla fine si è rivelato essere Ross Ulbricht… la sua scarsa sicurezza operativa è stata sufficiente per legare a lui le attività.

Il fondatore di Silk Road Ross Ulbricht ottiene l'ergastolo senza condizionale

Non solo la sua sicurezza operativa non era molto buona, sembra che alla fine del 2012 abbiano avuto (puoi crederci, Doug?) un errore nell'elaborazione dei pagamenti in criptovaluta...

---

DOUG.  [GASPS IN FALSO orrore]

---

ANATRA.  …del tipo che abbiamo visto ripetere tante volte da allora, che andava in giro non facendo una vera e propria partita doppia, dove per ogni addebito c'è un credito corrispondente e viceversa.

E questo attaccante ha scoperto, se metti del denaro nel tuo account e poi lo paga molto rapidamente ad altri account, che potresti effettivamente pagare cinque volte (o anche più) gli stessi bitcoin prima che il sistema si rendesse conto che il primo addebito era andato attraverso.

Quindi potresti praticamente mettere dei soldi e poi ritirarli ancora e ancora e ancora, e ottenere una scorta più grande ...

... e poi potresti tornare in quello che potresti chiamare un "ciclo di mungitura di criptovalute".

E si stima... gli inquirenti non erano sicuri, che avesse iniziato con tra i 200 e i 2000 bitcoin (se li avesse comprati o li abbia estratti, non lo sappiamo), e molto, molto rapidamente li ha trasformati in, aspettalo, Doug: 50,0000 bitcoin!

---

DOUG.  Wow!

---

ANATRA.  Più di 50,000 bitcoin, proprio così.

E poi, ovviamente immaginando che qualcuno se ne sarebbe accorto, è scappato mentre era in vantaggio con 50,000 bitcoin...

…ognuno del valore di $ 12 incredibili, in aumento rispetto alle frazioni di centesimo di pochi anni prima. [RIDE]

Quindi è scappato con $ 600,000, proprio così, Doug.

[PAUSA DRAMMATICA]

Nove anni dopo...

[RISATA]

...quasi *esattamente* nove anni dopo, quando fu arrestato e la sua casa fu perquisita con un mandato, i poliziotti andarono a cercare e trovarono una pila di coperte nel suo armadio, sotto la quale era nascosta una scatola di popcorn.

Strano posto dove tenere i tuoi popcorn.

Dentro c'era una specie di portafoglio freddo computerizzato.

All'interno del quale c'era una grande percentuale di detti bitcoin!

Al momento in cui è stato arrestato, i bitcoin erano qualcosa a nord di $ 65,535 (o 2¹⁶-1) ciascuno.

Nel frattempo erano aumentati di oltre mille volte.

Quindi, all'epoca, è stato il più grande fallimento di criptovalute di sempre!

Nove anni dopo, apparentemente incapace di smaltire i suoi guadagni illeciti, forse temendo che anche se avesse provato a infilarli in un bicchiere, tutte le dita avrebbero puntato a lui...

…ha avuto tutti questi 3 miliardi di dollari di bitcoin che sono rimasti in una scatola di popcorn per nove anni!

---

DOUG.  Mamma mia.

---

ANATRA.  Quindi, dopo essere stato seduto su questo spaventoso tesoro per tutti quegli anni, chiedendosi se sarebbe stato catturato, ora si chiede: "Per quanto tempo andrò in prigione?"

E la pena massima per l'accusa che deve affrontare?

20 anni, Doug.

---

DOUG.  Un'altra storia interessante in corso proprio ora. Se sei stato su Twitter ultimamente, saprai che c'è molta attività. per dirlo diplomaticamente...

---

ANATRA.  [IMPERSONAZIONE DI BOB DYLAN DI QUALITÀ DA BASSA A MEDIA] Bene, i tempi stanno cambiando.

---

DOUG.  ...compresa a un certo punto l'idea di addebitare $ 20 per un assegno blu verificato, che, ovviamente, quasi immediatamente ha provocato alcune truffe.

Truffe e-mail di Twitter Blue Badge: non innamorarti!

---

ANATRA.  È solo un promemoria, Doug, che ogni volta che c'è qualcosa che ha attirato molto interesse, i truffatori sicuramente seguiranno.

E la premessa era: "Ehi, perché non arrivi presto? Se hai già un segno blu, indovina un po'? Non dovrai pagare $ 19.99 al mese se ti registri. Te lo lasceremo tenere".

Sappiamo che non è stata un'idea di Elon Musk, come ha affermato, ma è il genere di cose che fanno molte aziende, vero?

Molte aziende ti daranno qualche tipo di vantaggio se rimani con il servizio.

Quindi non è del tutto incredibile.

Come dici tu... cosa gli hai dato?

B-meno, vero?

---

DOUG.  Do all'e-mail iniziale un B-meno... potresti forse essere ingannato se lo leggi velocemente, ma ci sono alcuni problemi di grammatica; le cose non sembrano a posto.

E poi una volta che fai clic, darei alle pagine di destinazione C-meno.

Diventa ancora più rischioso.

---

ANATRA.  Che è da qualche parte tra 5/10 e 6/10?

---

DOUG.  Sì, diciamo così.

E abbiamo qualche consiglio, in modo che anche se si tratta di una truffa A-plus, non importa perché sarai comunque in grado di contrastarlo!

A partire dal mio preferito personale: Usa un gestore di password.

Un gestore di password risolve molti problemi quando si tratta di truffe.

---

ANATRA.  Lo fa.

Un gestore di password non ha alcuna intelligenza simile a quella umana che può essere fuorviata dal fatto che la bella immagine è giusta, o il logo è perfetto, o il modulo web è esattamente nella giusta posizione sullo schermo con esattamente lo stesso carattere , quindi lo riconosci.

Tutto quello che sa è: "Mai sentito parlare di questo sito prima".

---

DOUG.  E naturalmente, attiva 2FA se puoi.

Aggiungi sempre un secondo fattore di autenticazione, se possibile.

---

ANATRA.  Naturalmente, questo non ti protegge necessariamente da te stesso.

Se vai su un sito falso e hai deciso "Ehi, è perfetto per i pixel, deve essere un vero affare", e sei determinato ad accedere e hai già inserito il tuo nome utente e la tua password, e poi ti chiede di passare attraverso il processo 2FA...

...è molto probabile che tu lo faccia.

Tuttavia, ti dà quel po' di tempo per fare lo "Stop. Pensare. Collegare." cosa e dì a te stesso: "Aspetta, cosa ci faccio qui?"

Quindi, in un certo senso, il piccolo ritardo introdotto dalla 2FA può effettivamente essere non solo una piccola seccatura, ma anche un modo per migliorare effettivamente il flusso di lavoro della sicurezza informatica... introducendo un aumento di velocità sufficiente che sei incline a prendere la sicurezza informatica un po' più seriamente.

Quindi non vedo quale sia il lato negativo, davvero.

---

DOUG.  E, naturalmente, un'altra strategia che è difficile da rispettare per molte persone, ma è molto efficace, è quella di farlo evita i collegamenti di accesso e i pulsanti di azione nelle e-mail.

Quindi, se ricevi un'e-mail, non limitarti a fare clic sul pulsante... vai al sito stesso e sarai in grado di dire abbastanza rapidamente se quell'e-mail era legittima o meno.

---

ANATRA.  Fondamentalmente, se non puoi fidarti completamente della corrispondenza iniziale, non puoi fare affidamento su nessun dettaglio in essa contenuto, che sia il link su cui cliccherai, il numero di telefono che chiamerai, l'indirizzo email che Li contatteremo su , l'account Instagram a cui invierai i DM, qualunque esso sia.

Non usare ciò che c'è nell'e-mail... trova la tua strada lì e metterai in corto circuito molte truffe di questo tipo.

---

DOUG.  E infine, ultimo ma non meno importante... questo dovrebbe essere il buon senso, ma non lo è: Non chiedere mai al mittente di un messaggio incerto se sono legittimi.

Non rispondere dicendo "Ehi, sei davvero Twitter?"

---

ANATRA.  Sì, hai proprio ragione.

Perché il mio consiglio precedente, "Non fare affidamento sulle informazioni nell'e-mail", come non telefonare al loro numero di telefono... alcune persone sono tentate di dire: "Beh, chiamo il numero di telefono e vedo se è davvero sono loro. [IRONIC] Perché, ovviamente, se risponde il cuoco, daranno il loro vero nome".

---

DOUG.  Come diciamo sempre: In caso di dubbio/Non darlo.

E questo è un buon ammonimento, la prossima storia: quando le scansioni di sicurezza, che sono strumenti di sicurezza legittimi, rivelare più di quanto dovrebbero, cosa succede allora?

Strumenti di scansione degli URL pubblici: quando la sicurezza porta all'insicurezza

---

ANATRA.  Questo è un noto ricercatore di nome Fabian Bräunlein in Germania... l'abbiamo già presentato un paio di volte.

È tornato con un rapporto dettagliato intitolato urlscan.io's SOAR spot: strumenti di sicurezza loquaci che trapelano dati privati.

E in questo caso lo è urlscan.io, un sito web che puoi utilizzare gratuitamente (o come servizio a pagamento) dove puoi inviare un URL, o un nome di dominio, o un numero IP, o qualunque esso sia, e puoi cercare: “Cosa sa la community a questo proposito?"

E rivelerà l'URL completo di cui altre persone hanno chiesto.

E queste non sono solo cose che le persone copiano e incollano di propria scelta.

A volte, la loro posta elettronica, ad esempio, potrebbe passare attraverso uno strumento di filtro di terze parti che estrae a sua volta URL, chiama a casa urlscan.io, esegue la ricerca, ottiene il risultato e lo utilizza per decidere se inviare indesiderato, bloccare lo spam o passare il messaggio.

Ciò significa che a volte, se l'URL include dati segreti o semisegreti, informazioni di identificazione personale, altre persone a cui è capitato di cercare il nome di dominio giusto entro un breve periodo vedrebbero tutti gli URL che sono stati cercati, inclusi cose che potrebbero essere nell'URL.

Sai, tipo blahblah?username=doug&passwordresetcode= seguito da una lunga stringa di caratteri esadecimali e così via.

E Bräunlein ha fornito un elenco affascinante del tipo di URL, in particolare quelli che possono apparire nelle e-mail, che possono essere regolarmente inviati a terzi per essere filtrati e quindi indicizzati per la ricerca.

Il tipo di e-mail che riteneva sicuramente sfruttabile includeva, ma non si limitava a: collegamenti alla creazione dell'account; Link per la consegna di regali Amazon; chiavi API; Richieste di firma di DocuSign; trasferimenti di file nella casella personale; tracciabilità del pacco; reimpostazione della password; fatture PayPal; Condivisione di documenti su Google Drive; Inviti di SharePoint; e link di annullamento dell'iscrizione alla newsletter.

Non puntare il dito su SharePoint, Google Drive, PayPal, ecc.

Questi erano solo esempi di URL in cui si è imbattuto e potenzialmente sfruttabili in questo modo.

---

DOUG.  Abbiamo alcuni consigli alla fine di quell'articolo, che si riducono a: leggi il rapporto di Bräunlein; leggere urlscan.iopost sul blog di; fai una tua revisione del codice; se si dispone di codice che esegue ricerche di sicurezza online; scoprire quali funzionalità di privacy esistono per gli invii online; e, soprattutto, impara come segnalare dati non autorizzati a un servizio online se li vedi.

Ho notato che ci sono tre... specie di limerick?

Mini-poesie molto creative alla fine di questo articolo...

---

ANATRA.  [MOCK HORROR] No, non sono limerick! I limerick hanno una struttura a cinque linee molto formale...

---

DOUG.  [RIDENDO] Mi dispiace tanto. È vero!

---

ANATRA.  ...sia per metro che per rima.

Molto strutturato, Doug!

---

DOUG.  Mi dispiace così tanto, così vero. [RIDE]

---

ANATRA.  Questo è solo un doggerel. [RISATA]

Di nuovo: In caso di dubbio/Non darlo.

E se stai raccogliendo dati: Se non dovrebbe essere dentro/Infilalo dritto nel cestino.

E se stai scrivendo un codice che chiama API pubbliche che potrebbero rivelare i dati dei clienti: Non far piangere mai i tuoi utenti/Da come chiami l'API.

---

DOUG.  [RIDE] Questo è nuovo per me, e mi piace molto!

E per ultimo, ma non meno importante nella nostra lista qui, abbiamo parlato settimana dopo settimana di questo bug di sicurezza di OpenSSL.

La grande domanda ora è: "Come puoi dirlo cosa c'è da aggiustare?"

La storia dell'aggiornamento della sicurezza di OpenSSL: come puoi dire cosa deve essere corretto?

---

ANATRA.  Infatti, Doug, come facciamo a sapere quale versione di OpenSSL abbiamo?

E ovviamente, su Linux, basta aprire un prompt dei comandi e digitare openssl versione ti dice la versione che hai.

Ma OpenSSL è una libreria di programmazione e non esiste una regola che dice che il software non può avere una propria versione.

La tua distribuzione potrebbe utilizzare OpenSSL 3.0, eppure c'è un'app che dice: "Oh, no, non abbiamo aggiornato alla nuova versione. Preferiamo OpenSSL 1.1.1, perché è ancora supportato e, nel caso non lo possiedi, stiamo portando la nostra versione".

E quindi, sfortunatamente, proprio come in quel famigerato caso Log4Shell, dovevi andare a cercare i tre? 12? 154? chissà quanti posti sulla tua rete in cui potresti avere un programma Log4J obsoleto.

Lo stesso per OpenSSL.

In teoria, gli strumenti XDR o EDR potrebbero essere in grado di dirtelo, ma alcuni non lo supporteranno e molti lo scoraggeranno: in realtà eseguendo il programma per scoprire di quale versione si tratta.

Perché, dopotutto, se è il buggy o quello sbagliato, e in realtà devi eseguire il programma per farlo segnalare la propria versione...

...è come mettere il carro davanti ai buoi, vero?

Quindi abbiamo pubblicato un articolo per quei casi speciali in cui vuoi effettivamente caricare la DLL, o la libreria condivisa, e vuoi effettivamente chiamarla TellMeThyVersion() codice software.

In altre parole, ti fidi abbastanza del programma da caricarlo in memoria, eseguirlo ed eseguirne alcuni componenti.

Ti mostriamo come farlo in modo da poter essere assolutamente certo che tutti i file OpenSSL periferici che hai sulla tua rete siano aggiornati.

Perché anche se questo è stato declassato da CRITICAL a HIGH, è ancora un bug che devi e vuoi correggere!

---

DOUG.  In merito alla gravità di questo bug, abbiamo ottenuto un domanda interessante dal lettore di sicurezza Naked Svet, che scrive, in parte:

Com'è possibile che un bug che è enormemente complesso per lo sfruttamento e può essere utilizzato solo per attacchi denial of service, continua a essere classificato come ALTO?

---

ANATRA.  Sì, penso che abbia detto qualcosa su "Oh, il team di OpenSL non ha sentito parlare di CVSS?", che è uno standard del governo degli Stati Uniti, se vuoi, per codificare il livello di rischio e di complessità dei bug in un modo che può essere filtrato automaticamente dagli script.

Quindi, se ha un punteggio CVSS basso (che è il Sistema comune di valutazione delle vulnerabilità), perché le persone si entusiasmano?

Perché dovrebbe essere ALTO?

E quindi la mia risposta è stata: "Perché *non dovrebbe* essere ALTO?"

È un bug in un motore crittografico; potrebbe mandare in crash un programma, diciamo, che sta cercando di ottenere un aggiornamento... quindi andrà in crash ancora e ancora e ancora, il che è un po' più di una semplice negazione del servizio, perché in realtà ti impedisce di eseguire correttamente la tua sicurezza.

C'è un elemento di bypass di sicurezza.

E penso che l'altra parte della risposta sia, quando si tratta di trasformare le vulnerabilità in exploit: "Mai dire mai!"

Quando hai qualcosa come un overflow del buffer dello stack, in cui puoi manipolare altre variabili nello stack, possibilmente inclusi gli indirizzi di memoria, ci sarà sempre la possibilità che qualcuno possa capire un exploit praticabile.

E il problema, Doug, è che una volta che l'hanno capito, non importa quanto sia stato complicato capirlo...

…una volta che sai come sfruttarlo, *chiunque* può farlo, perché puoi vendere loro il codice per farlo.

Penso che tu sappia cosa sto per dire: "Non che mi senta fortemente al riguardo".

[RISATA]

È, ancora una volta, una di quelle cose da “dannati se lo fanno, dannati se non lo fanno”.

---

DOUG.  Molto bene, grazie mille, Svet, per aver scritto quel commento e averlo inviato.

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

---

TUTTI E DUE.  Stai al sicuro!