Fare clic e trascinare sulle onde sonore sottostanti per passare a qualsiasi punto. Puoi anche ascolta direttamente su Soundcloud.
Con Paul Ducklin e Chester Wisniewski.
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
[MODE MUSICALE]
ANATRA. Benvenuti nel podcast, a tutti.
Non sono Douglas... sono Paul Ducklin.
Doug è in vacanza, quindi con me si unisce il mio caro amico e collega Chester Wisniewski, del nostro ufficio di Vancouver.
Ciao, Chet!
CHET. Ciao, Anatra.
Come te la passi?
ANATRA. Sto molto bene, grazie.
Oggi nell'Oxfordshire è piovuto per la prima volta da... devono essere almeno un paio di mesi.
Almeno abbiamo messo un po’ d’acqua nel terreno, perché qui è stato molto, molto secco – atipicamente secco.
Come su di te?
CHET. Bene, mi sto riprendendo dal DEF CON nonostante non abbia frequentato il Defcon, cosa che non sapevo nemmeno esistesse.
ANATRA. [RISANDO] Oh, sì!
CHET. Ho passato l'intero fine settimana con gli occhi incollati su Twitter, Twitch e Discord e tutte queste piattaforme su cui potresti pseudo-partecipare da remoto a tutti i festeggiamenti.
E, devo dire, è molto più divertente quando sei effettivamente a Las Vegas.
Ma considerando che il numero di persone che conosco che sono già tornate con il COVID si avvicina a più di me, penso di aver fatto la scelta giusta e sono felice di essere esausto per aver usato troppo Internet per tutto il fine settimana.
ANATRA. Pensi che abbiano davvero contratto un'infezione da coronavirus, o sono semplicemente tornati con la sensazione, come posso dire... di "malessere" a causa del Black Hat seguito da DEF CON.
CHET. Sai, per quanto grave possa essere la CON FLU...
ANATRA. CON INFLUENZA?! [RISA] Oh, caro!
CHET. …Sono abbastanza fiducioso che in questo caso si tratti di COVID, perché non solo le persone stanno effettuando i test, ma per la maggior parte delle persone che conosco, il COVID è significativamente più doloroso persino della CON FLU.
Quindi i due combinati erano probabilmente davvero orribili, devo pensare. [RISATA]
ANATRA. Sì!
Ma non indugiamoci sui problemi DEF CON coronavirus/CON FLU...
… rivolgiamo la nostra attenzione ad un *discorso* tenuto al DEF CON.
Si tratta di a Zoom zero-day che è stato scritto da Patrick Wardle e presentato al DEF CON.
Piuttosto una sfortunata serie di bug, incluso uno che non è stato corretto correttamente, Chester?
CHET. Bene, Patrick non è l'unico ricercatore di sicurezza macOS al mondo, ma è piuttosto prodigioso nell'individuare problemi.
E l'ultima volta che ho visto Patrick Wardle presente è stato alla conferenza Virus Bulletin, diverse volte, e ogni volta ha portato Apple a scuola per alcune decisioni discutibili sulla verifica della firma, sulla verifica dei certificati, questo tipo di cose.
E sto iniziando ad avere l’impressione che Apple abbia ampiamente modellato la propria strategia di sicurezza attorno ad alcune di queste cose.
E così ora è alla ricerca di altri fornitori che potrebbero commettere errori crittografici simili che potrebbero consentire l’ingresso di malware sulla piattaforma.
ANATRA. Immagino che ai vecchi tempi tutti pensassero: "Beh, a patto che tu abbia una connessione TLS" o "A patto che tu abbia qualcosa firmato digitalmente da *qualcuno*".
Quindi, il codice spesso non si preoccupa di andare a controllare.
Ma in questo caso, hanno deciso di controllare i pacchetti di aggiornamento scaricati per assicurarsi che provenissero da Zoom.
Ma non lo hanno fatto molto bene, vero?
Invece di chiamare l'API ufficiale del sistema, che se ne va, esegue il controllo e sostanzialmente ritorna con un vero o falso...
…hanno “lavorato a maglia da soli”, vero?
CHET. Sì.
Voglio dire, lavorare a maglia le proprie cose legate alle criptovalute finisce sempre in modo doloroso.
E ricordo che nell'ultimo podcast parlavi del nuovo algoritmo crittografico quantistico che è stato violato in un'ora su un laptop.
ANATRA. SÌ!
CHET. Tutti erano così concentrati sul lato quantistico che in un certo senso si sono concentrati mancato il lato convenzionale, anche tra alcuni dei matematici e crittografi più intelligenti del mondo, giusto?
Quindi è davvero facile commettere errori che possono essere devastanti.
E lavorare a maglia è qualcosa di cui tu ed io parliamo, voglio dire, da quasi 20 anni, in diversi formati di comunicazione, per conto di Sophos.
E non credo che abbiamo mai cambiato la nostra posizione secondo cui è un’idea terribile!
ANATRA. Il problema qui non è che abbiano deciso di utilizzare i propri algoritmi di firma digitale o di inventare la propria curva ellittica.
È solo che invece di dire: “Ecco un file. Caro sistema operativo, usa i tuoi strumenti standardizzati basati su API per verificarlo e tornare Vero/Falso", hanno scelto di sborsare essenzialmente...
…hanno eseguito il pkgutil utilità della riga di comando in background, che è ciò che puoi fare dalla riga di comando se desideri ottenere una visualizzazione visiva leggibile dall'uomo di chi ha firmato cosa.
E poi hanno scritto un programma che avrebbe passato l'output basato su testo per decidere se volevano ottenere la risposta "vero" o "falso".
Hanno ottenuto un elenco della catena di certificati e hanno cercato "Zoom", seguito da "Autorità di certificazione per sviluppatori", seguito da "Apple Root CA".
Quindi, cercano quelle stringhe *ovunque nell'output*, Chester!
Quindi [RISA] si scopre che se hai creato un pacchetto che avesse un nome sulla falsariga di Zoom Video Communications Inc Developer ID Certification Authority Apple Root CA.pkg, poi quando pkgutil scrivesse il nome del file nel suo output, apparirebbero tutte e tre le stringhe magiche!
E il parser piuttosto inetto di Zoom deciderebbe che ciò potrebbe accadere solo se fosse stato firmato, nel giusto ordine, da quelle tre organizzazioni.
Mentre, in realtà, era semplicemente il nome che hai fornito.
Oh caro!
CHET. Il problema qui è che ciò che sta causando il problema è questo tipo di controllo rudimentale della firma che stanno facendo.
Ma il vero problema, ovviamente, è che qualsiasi pacchetto a cui è possibile dare quel nome verrà installato *come root* sul sistema, anche se l'utente che esegue il processo di aggiornamento non ha privilegi.
ANATRA. Questo era il problema.
Perché sembrava che quello che è successo, in tempo per DEF CON, Zoom *abbia* risolto questo problema.
Usano correttamente l'API e verificano in modo affidabile l'integrità e l'autenticità del file che stanno per eseguire.
Ma spostandolo nella directory temporanea da cui Zoom orchestra l'installazione, lo hanno lasciato scrivibile da tutti!
Quindi, la directory era protetta e tutto al suo interno era protetto... *tranne il file più importante*.
Allora, indovina cosa potresti fare?
Se hai calcolato il momento giusto (un cosiddetto condizione di gara), l'utente originale poteva modificare il file *dopo* che avesse superato il controllo dell'identità digitale, ma *prima* che fosse utilizzato seriamente.
Il programma di installazione sta utilizzando un file che ritiene sia stato convalidato e in effetti è stato convalidato...
…ma è stato invalidato nel divario tra la validazione e l’utilizzo.
CHET. Sì, e come fai notare nell'articolo, Duck, questo tipo di vulnerabilità, piuttosto che essere semplicemente una semplice condizione di razza, viene spesso definita TOCTOU, che a me sembra una specie di uccello dei Caraibi.
Ma si riferisce a un nome scientifico più complicato per il difetto, chiamato a Dal tempo di controllo al tempo di utilizzo.
Quindi, T-O-C-T-O-U… “Toctou”!
ANATRA. Come te, ho sempre immaginato che fosse una specie di pappagallo polinesiano molto carino.
Ma in realtà è, come dici tu, una brutta forma di bug in cui controlli i tuoi fatti, ma li controlli troppo presto e quando arrivi a fare affidamento su quei fatti, sono cambiati.
Quindi Zoom ha risolto il problema e Patrick Wardle ha detto di essersi congratulato con loro... hanno risolto il problema entro un giorno dalla conclusione del documento al DEF CON.
Hanno bloccato correttamente i privilegi sul file prima di avviare il processo di convalida.
Quindi la validazione, una volta completata, è rimasta valida fino al termine dell'installazione.
Problema risolto.
Ma non avrebbe mai dovuto essere lì fin dall'inizio, vero?
CHET. Se sei un utente Mac, puoi controllare il numero di versione per essere sicuro di avere quello corretto.
La versione corretta è la 5.11.5 o successiva – non so se ci siano state versioni successive.
[Nota. Un ulteriore aggiornamento alla versione 5.11.6 è uscito tra la registrazione e la pubblicazione di questo episodio.]
ANATRA. Ora, ciò non significa che un estraneo possa entrare nel tuo computer se non hai questa patch, ma è un brutto problema avere...
…dove un truffatore che è entrato nella tua rete ma ha, ad esempio, solo privilegi di ospite, può improvvisamente elevarsi e ottenere superpoteri di root o amministratore di sistema.
Questo è esattamente ciò che i criminali ransomware amano fare.
Entrano con una potenza ridotta e poi si fanno strada fino a raggiungere un livello di parità con gli amministratori di sistema regolari.
E poi, sfortunatamente, c’è ben poco limite a ciò che possono fare di male in seguito.
Chester, passiamo al prossimo bug.
Questo è un bug noto come... beh, sono A ed E scritte insieme, che è una vecchia lettera inglese – non è più usata in inglese, ed è la lettera chiamata cenere, ma in questo caso deve essere APIC/EPIC.
APIC, perché influisce sugli APIC, il Controller di interrupt programmabile avanzato, e la considerano una fuga di notizie EPICA.
CHET. L’ho trovato interessante, ma cominciamo con il fatto che non penso che sia così epico, forse, come suggerisce il nome.
L’APIC è certamente coinvolto, ma non sono così sicuro dell’EPIC!
La verità, quando si svela tutto questo, è che colpisce parte delle CPU Intel note come SGX, che è... ora me lo dimenticherò... Estensioni di protezione del software, Voglio dire?
ANATRA. Hai ragione!
CHET. Bene, questo non è il primo bug che colpisce SGX.
Non li ho contati tutti, ma ho trovato almeno sette casi precedenti, quindi non ha avuto un ottimo track record nel fare esattamente ciò per cui è stato progettato.
E l'unico utilizzo pratico che ho trovato ovunque è che hai bisogno di questa funzionalità per memorizzare le chiavi segrete per riprodurre i dischi Blu-ray UltraHD su Windows.
E con i chip che non supportano SGX, a quanto pare non ti è permesso guardare film.
ANATRA. Il che è ironico, perché Intel è arrivata alla dodicesima generazione di CPU... ha interrotto la produzione di SGX per i cosiddetti chip "client".
Quindi i chip che ottieni ora se hai un laptop nuovo di zecca – questo non si applica, perché non contiene SGX.
Sembra che lo vedano come qualcosa che potrebbe essere utile sui server.
CHET. Bene, penso che sia giusto dire che il destino di SGX è stato segnato dal fatto che Intel lo ha già eliminato dalle CPU di dodicesima generazione.
Se non fosse per il fatto che questo è come l'ottavo modo intelligente che qualcuno ha trovato per estrarre segreti... da una cosa progettata per contenere solo segreti.
ANATRA. Sì, ricorda che le prestazioni sono d'intralcio.
Perché da quanto ho capito, il modo in cui funziona è che il modo vecchio stile di estrarre i dati dal controller di interruzione programmabile, l'APIC, era fondamentalmente leggerli da un blocco di memoria allocato specificamente a quel dispositivo.
Il blocco di memoria utilizzato per i dati di interruzione estratti era di 4 KB... una pagina di memoria.
Ma non c’erano molti dati da estrarre e quello che c’era prima, ad esempio nella cache di sistema, veniva riscritto.
In altre parole, il processore di interrupt non ha svuotato la memoria che avrebbe utilizzato prima di scrivere i byte che intendeva consegnare.
Pertanto, a volte forniva accidentalmente valori di dati da altre parti arbitrarie della memoria a cui la CPU aveva avuto accesso di recente.
E controllando cosa accadeva e in quale ordine, i ricercatori hanno scoperto che potevano persuadere i contenuti della RAM che avrebbero dovuto essere sigillati in queste “enclavi” SGX a emergere come una sorta di memoria non inizializzata nel mezzo della gestione degli interrupt.
Quindi, ricorda sempre che quando provi ad accelerare le cose prendendo scorciatoie di sicurezza, puoi finire con ogni sorta di problema.
CHET. Se hai intenzione di fidarti che questa cosa mantenga i segreti, ha bisogno di molti controlli.
E sembra che questa tecnologia SGX fosse un po' cotta a metà quando è stata lanciata.
ANATRA. La complessità comporta sempre costi/rischi, non è vero?
Se pensi, Chester, al processore 6502 che era notoriamente presente nell'Apple II, nel VIC-20, nel Commodore 64... se vieni dal Regno Unito, era nel BBC Micro.
Credo che quel chip avesse circa 4000 transistor.
Quindi era davvero un chip con set di istruzioni ridotto, o RISC.
Considerando che da quanto mi risulta, l'ultimo processore Apple M2 ha 20 miliardi (come in 20,000,000,000) di transistor, solo in una CPU.
Quindi, puoi vederlo quando inizi ad aggiungere cose come l'Interrupt Controller (che può andare nel chip), l'enclave sicura (beh, che può andare nel chip), l'hyperthreading (che può andare nel chip), [SPEEDING UP MANICAMENTE] istruzioni vettoriali (quelle che potrebbero andare nel chip), esecuzione speculativa, riordino delle istruzioni, multicore…
…tutte queste cose, non sorprende che a volte le cose non funzionino come ci si potrebbe aspettare, e che ci voglia molto tempo prima che qualcuno se ne accorga.
CHET. Bene, buon lavoro ai ricercatori che l’hanno trovato, perché è sicuramente una ricerca interessante.
E se vuoi capirne qualcosa in più, il tuo articolo Naked Security lo spiega incredibilmente bene per persone che normalmente non hanno familiarità con cose come i controller APIC.
Quindi consiglio alle persone di verificarlo, perché è un perfetto esempio di conseguenze non intenzionali derivanti da decisioni semplici prese su cose molto complesse.
ANATRA. Penso che sia un modo eccellente per dirlo. Chester.
Ci lascia inoltre liberi di passare ad un’altra questione controversa, ovvero il fatto che il governo degli Stati Uniti lo sia offrendo una ricompensa che si dice siano "fino a 10 milioni di dollari" per informazioni sulla squadra del ransomware Conti.
Ora, sembra che non conoscano il vero nome di nessuno.
Queste persone sono conosciute solo come Dandis, Professor, Reshaev, Target e Tramp.
E le loro foto sono solo sagome…
CHET. Sì, quando ho visto l’articolo per la prima volta, ho pensato che la descrizione dei criminali fosse come la gente dell’isola di Gilligan.
Abbiamo il Professore e il Vagabondo... e non ero del tutto sicuro di dove andasse a parare con i soprannomi.
Spero che questo tentativo abbia più successo del precedente... voglio dire, c'era un altro gruppo per il quale offrirono 10 milioni di dollari, che era il gruppo Evil Corp.
E per quanto ne so, non è stato ancora intrapreso alcun arresto o alcun tipo di azione legale. Quindi presumibilmente i 10 milioni di dollari per ottenere Evil Corp non erano un incentivo sufficiente per le persone a rivoltarsi contro gli autori di quel gruppo.
Quindi, si spera, questo ha un po’ più successo.
Ma c'era una foto fantastica che ha causato molte speculazioni e conversazioni su Twitter e anche su Naked Security, nel post che hai scritto, di uno dei presunti autori.
Non sappiamo se sia un membro del gruppo di controllo che gestiva o gestiva il Ransomware-as-a-Service, o se fosse semplicemente forse un affiliato che ha utilizzato il malware e ha contribuito a pagare commissioni su guadagni illeciti da vittime.
Ma non si potrebbe diventare più stereotipicamente russi... Voglio dire, stiamo guardando questo: il ragazzo ha una stella rossa sul berretto, e immagino abbia una piccola bottiglia di vodka in mano, e c'è una balalaika.
Questo è quasi troppo bello per essere vero.
ANATRA. E, vestito da buon hacker, indossa una specie di giubbotto imbottito con una felpa con cappuccio...
…anche se ha abbassato la felpa con cappuccio, quindi forse non conta?
Credi, Chester, che abbiano preso di mira la banda Conti perché avevano un po' di disonore tra i ladri, per così dire?
Circa un anno fa, alcuni affiliati si sono arrabbiati molto, hanno affermato di essere stati derubati e si è verificata una violazione dei dati, non è vero, dove uno di loro ha scaricato un intero carico di manuali operativi e file di software?
CHET. Sai, ci sono molti pezzi lì.
Come fai notare – credo che fosse nell’agosto del 2021 – qualcuno hanno fatto trapelare i loro manuali operativi, o il loro "playbook", come è stato definito.
Dopo l’invasione dell’Ucraina, Conti come entità sembrava essere molto filo-russo, il che ha portato un gruppo di ucraini che facevano parte del loro piano ad rivoltarsi contro di loro e a far trapelare un sacco di informazioni sulle loro operazioni e cose del genere.
Quindi, c'è sicuramente stato qualcosa lì.
Penso che un altro motivo, Duck, sia semplicemente il enorme quantità di danni hanno causato.
Voglio dire, quando abbiamo redatto i nostri resoconti dal nostro team di risposta rapida, senza dubbio il gruppo più prolifico nel 2021 che ha causato danni è stato Conti.
Nessuno crede veramente di essere fuori dal mondo criminale.
Non è che abbiano preso i loro soldi e se ne siano andati... si sono semplicemente evoluti in nuovi schemi, si sono suddivisi in diversi gruppi di ransomware e stanno svolgendo ruoli diversi nella comunità rispetto a prima.
E più recentemente, alcune persone potrebbero aver sentito che ci sono stati alcuni attacchi contro il governo costaricano attribuiti a Conti, e non è passato nemmeno molto tempo.
Quindi penso che ci siano degli strati qui, e uno di questi strati potrebbe essere che Dandis, il Professore, Reshaev...
…queste persone sono state in qualche modo derubate pubblicamente [i dati personali sono trapelati deliberatamente] da persone che affermano di sapere chi sono, ma senza fornire prove che meriterebbero accuse e condanne.
E quindi forse questa è la speranza che forse si faranno avanti se il prezzo sarà abbastanza alto, e si rivolteranno contro i loro ex compagni.
ANATRA. Tuttavia, anche se domani venissero arrestati tutti, accusati e condannati, ciò intaccherebbe le procedure relative al ransomware, non è vero?
Ma sfortunatamente, sarebbe un *ammaccatura*, non la *fine di*.
CHET. Assolutamente.
Sfortunatamente, questo è il mondo in cui viviamo oggigiorno.
Penso che continueremo a vedere questi crimini evolversi in modi diversi e, si spera, ciò fornirà un po’ di sollievo man mano che diventeremo sempre più bravi a difenderci.
Ma con i potenziali riscatti da 25 milioni di dollari disponibili, ci sono molte persone disposte a rischiare e continuare a perpetrare questi crimini, indipendentemente dal fatto che questi particolari signori del crimine siano al timone o meno.
ANATRA. Sì.
Pensi: “Oh, beh, non otterrebbero mai 25 milioni di dollari. Probabilmente alla fine si accontenterebbero di meno”.
Ma anche se quella cifra scendesse, diciamo, a 250,000 dollari...
…come sottolinea il team statunitense di Rewards for Justice: dal 2019, sostengono che solo la banda Conti (citando dal sito RfJ), che il loro ransomware sia stato utilizzato per condurre più di 1000 attacchi ransomware contro infrastrutture critiche statunitensi e internazionali.
Servizi medici, centri di emergenza 9-1-1, città, comuni.
E suggeriscono che delle sole reti sanitarie e di primo soccorso – cose come autisti di ambulanze, vigili del fuoco, ospedali – più di 400 in tutto il mondo sono state colpite, di cui 290 negli Stati Uniti.
Quindi, se moltiplichi 290 per (qui sto usando quotazioni aeree giganti) per la “commissione di sconto” di $ 250,000 che avrebbe dovuto essere utilizzata per fornire assistenza sanitaria…
... ottieni comunque un numero enormemente grande.
CHET. Ricordi quattro anni fa quando pubblicammo a rapporto su SamSam e siamo rimasti stupiti dal fatto che abbiano guadagnato 6 milioni di dollari in tre anni?
ANATRA. Sono comunque tanti soldi, Chester!
Beh, per me è così... forse sei un volantino alto. [RISATA]
So che hai un argomento: non ne abbiamo parlato su Naked Security, ma è qualcosa che ti interessa molto...
…e questo è il fatto che non può esserci “un unico anello per dominarli tutti” quando si tratta di sicurezza informatica.
Soprattutto quando si tratta di settori come l’assistenza sanitaria e i primi soccorritori, dove qualsiasi cosa possa ostacolare il miglioramento della sicurezza potrebbe in realtà peggiorare pericolosamente il servizio.
E tu hai una storia del National Institutes of Health da raccontare...
CHET. Sì, penso che sia importante ricordare che noi, innanzitutto, siamo responsabili della gestione del rischio, non dei risultati che si traducono in perfetta sicurezza.
E penso che molti praticanti lo dimentichino troppo spesso.
Vedo molte di queste discussioni, soprattutto nei social media: “il perfetto è nemico del bene”, di cui abbiamo parlato in precedenza anche nei podcast…
…dove “Dovresti farlo in questo modo, e questo è l’unico modo giusto per farlo”.
E penso che questo sia interessante – questo studio della relazione tra gli ospedali che hanno subito una violazione dei dati e gli esiti dei pazienti a seguito di tali violazioni dei dati.
A prima vista potrebbe non avere senso, ma permettetemi di leggervi i principali risultati, che credo rendano abbastanza chiaro di cosa stiamo parlando.
I risultati principali sono:
Il tempo impiegato dall’ospedale per eseguire l’elettrocardiogramma è aumentato di 2.7 minuti e la mortalità per infarto miocardico acuto a 30 giorni è aumentata di 0.36 punti percentuali, durante la finestra di tre anni successiva a una violazione dei dati.
In sostanza, ciò che stiamo dicendo è che un terzo di percentuale in più di persone sono morte per attacchi di cuore negli ospedali che hanno subito successivamente violazioni dei dati rispetto a prima, come percentuale dei pazienti che hanno avuto esiti fatali.
ANATRA. Presumibilmente l'implicazione è che se fossero stati in grado di portare su di loro quella macchina per l'elettrocardiogramma, ottenere i risultati e prendere una decisione clinica più rapidamente, avrebbero potuto salvare un numero non banale di quelle persone che sono morte?
CHET. Sì, e penso che quando si pensa a un ospedale affollato, dove le persone entrano regolarmente con infarti e ictus, 1 paziente su 300 che muore a causa dei nuovi protocolli di sicurezza sia una specie di preoccupazione.
E la Health and Human Services Administration negli Stati Uniti continua raccomandando agli ospedali violati di “valutare attentamente le iniziative di sicurezza correttive per ottenere una migliore sicurezza dei dati senza influire negativamente sui risultati dei pazienti”.
E penso che sia proprio qui che dobbiamo essere molto cauti, giusto?
Vogliamo tutti una migliore sicurezza delle informazioni e voglio che i dati dei miei pazienti siano tenuti al sicuro quando visito l'ospedale.
E vogliamo certamente essere sicuri che le persone non accedano a computer e dati che non dovrebbero, e che non dispensino farmaci che non dovrebbero e che potrebbero essere dannosi.
D'altra parte, questa è vita o morte.
E anche se questo potrebbe non applicarsi al tuo studio legale, alla società di marketing o alla fabbrica di cui sei responsabile della sicurezza… penso che sia un importante promemoria del fatto che non esiste una soluzione unica valida per tutti su come dovremmo gestire la sicurezza.
Dobbiamo valutare ogni situazione e assicurarci di adattarla alla quantità di rischio che siamo disposti ad accettare.
E personalmente, sono disposto ad accettare un rischio molto maggiore che la mia cartella clinica venga compromessa rispetto al rischio di morire perché qualcuno ha dovuto ottenere un codice a due fattori per sbloccare la macchina dell'elettrocardiogramma!
ANATRA. Beh, Chester, sei un diabetico di tipo 1, vero?
E tu hai una di quelle magiche pompe per insulina.
Ora, scommetto che non avrai fretta di installare l'ultimo kernel Linux nel momento in cui esce!
CHET. Assolutamente!
Voglio dire, questi dispositivi vengono sottoposti a test rigorosi... questo non vuol dire che siano privi di bug, ma il noto è meglio dell'ignoto quando parli della tua salute e della capacità di gestirla.
E certamente ci sono bug software in questi dispositivi, e si stanno modernizzando includendo tecnologie come Bluetooth... o il grande passo avanti per il mio dispositivo è stato quello di avere uno schermo a colori, che ti dice quanti anni hanno alcune delle tecnologie che entrano in questi dispositivi le cose sono!
Le autorità mediche per approvare questi dispositivi hanno un processo molto, molto lungo.
E “provate e vere” (come nella conversazione precedente su transistor e processori), le cose semplici che possiamo capire, sono di gran lunga preferite a cose nuove e complicate che sono molto più difficili da capire e trovare quei difetti di sicurezza.
Non riesco a immaginare, se esistesse un Patch Tuesday per questa pompa per insulina, che mi metterei in fila per essere il primo martedì sul blocco a installare l'aggiornamento!
Nonostante tutte le sue verruche, so esattamente come funziona e come no.
E secondo te, convivo bene con esso...
…il dispositivo conosce la sua responsabilità di rimanere coerente e ho imparato a sfruttarlo a mio vantaggio per migliorare la mia salute.
Qualsiasi cambiamento in questo senso può essere spaventoso e distruttivo.
Quindi, la risposta non è sempre migliore, più veloce e più intelligente.
A volte sono i “conosciuti” nell’affidabilità e nella fiducia.
ANATRA. Detto questo, anche il fatto di non subire violazioni dei dati aiuta!
E ci sono alcune cose sorprendentemente semplici che puoi fare per proteggere la tua organizzazione dai dati che escono dove non dovrebbero.
CHET. E una delle cose, Duck, è che non abbiamo più il tempo che avevamo prima.
I criminali scansionano continuamente Internet alla ricerca di uno qualsiasi di questi errori che potresti aver commesso, sia che si tratti di una politica obsoleta che consente troppe cose, sia che si tratti di servizi esposti che forse era perfettamente giusto esporre dieci anni fa, ma che ora sono pericolosi da avere. esposto a Internet.
ANATRA. “Il RDP quella volta dimenticato”.
CHET. Sì, beh, mi dispiace pensare che il programma RDP continui a presentarsi, ma in effetti, al Black Hat della scorsa settimana, abbiamo appena pubblicato un documento e ha scritto un blog su una situazione in cui un'organizzazione ha subito tre diversi attacchi ransomware nel giro di poche settimane, tutti all'interno della stessa organizzazione, avvenuti in qualche modo contemporaneamente.
E non è la prima volta che vediamo più di un aggressore all’interno di una rete.
Penso che potrebbe essere la prima volta che ne vediamo *tre* all'interno della stessa rete.
ANATRA. Oh, cavolo, si sono sovrapposti?
Stavano letteralmente ancora affrontando l’attacco A quando è arrivato l’attacco B?
CHET. Sì, credo che ci fosse un divario tra l'aggressore B e l'aggressore C, ma A e B erano presenti nello stesso momento, presumibilmente attraverso lo stesso identico difetto dello strumento di accesso remoto che entrambi avevano trovato e sfruttato.
E poi, credo, il gruppo B ha installato il proprio strumento di accesso remoto, una sorta di backdoor secondaria nel caso in cui la prima venisse chiusa...
…e il gruppo C ha trovato il proprio strumento di accesso remoto ed è entrato.
ANATRA. Accidenti... non dovremmo ridere, ma è una specie di commedia degli equivoci.
È facile dire: "Beh, in qualsiasi rete gestita anche solo parzialmente, dovresti sapere qual è il tuo strumento ufficiale di accesso remoto, in modo che tutto ciò che non sia quello dovrebbe risaltare ovviamente".
Ma lasciami chiedere ai nostri ascoltatori questo: se sei responsabile di una rete, puoi metterti la mano sul cuore e dirmi esattamente quanti strumenti di teleconferenza hai in uso nella tua azienda in questo momento?
CHET. Sì, assolutamente.
Abbiamo avuto una vittima di cui abbiamo parlato all'inizio di quest'anno e che credo avesse *otto* diversi strumenti di accesso remoto che abbiamo trovato durante la nostra indagine, alcuni dei quali sono stati utilizzati legittimamente dieci anni fa, e hanno semplicemente smesso di usarli ma non li hanno mai rimossi.
E altri introdotti da più autori di minacce.
Quindi questo è sicuramente qualcosa da tenere d'occhio!
ANATRA. Bene, Chester, speriamo che sia un suggerimento abbastanza ottimista con cui concludere, perché per questa settimana abbiamo scaduto il tempo a disposizione.
Grazie mille, come sempre, per essere intervenuto al microfono con brevissimo preavviso.
E, come sempre, non mi resta che dirvi: alla prossima volta…
TUTTI E DUE. Stai al sicuro!
[MODE MUSICALE]
- EPICO
- blockchain
- geniale
- Conti
- portafogli di criptovaluta
- cryptoexchange
- crittografia
- sicurezza informatica
- i criminali informatici
- Cybersecurity
- Dipartimento di Sicurezza Nazionale
- portafogli digitali
- firewall
- assistenza sanitaria
- Intel
- Kaspersky
- Legge e ordine
- il malware
- Mcafee
- Sicurezza nuda
- Podcast di sicurezza nudo
- NextBLOC
- Platone
- platone ai
- Platone Data Intelligence
- Gioco di Platone
- PlatoneDati
- gioco di plato
- Podcast
- Privacy
- ransomware
- VPN
- sicurezza del sito Web
- zefiro
- zoom
