Klikk og dra på lydbølgene nedenfor for å hoppe til et hvilket som helst punkt. Du kan også lytte direkte på Soundcloud.
Med Paul Ducklin og Chester Wisniewski.
Intro- og outromusikk av Edith Mudge.
Du kan lytte til oss på Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher og hvor som helst hvor du finner gode podcaster. Eller bare dropp URL til RSS-feeden vår inn i din favoritt podcatcher.
LES TRANSKRIPTET
[MUSIKK MODEM]
AND. Velkommen til podcasten, alle sammen.
Jeg er ikke Douglas... jeg er Paul Ducklin.
Doug er på ferie, så jeg får selskap av min gode venn og kollega, Chester Wisniewski, fra Vancouver-kontoret vårt.
Hei, Chet!
CHET. Hei, Duck.
Hvordan går det?
AND. Jeg har det veldig bra, takk.
Vi hadde vårt første regn i Oxfordshire i dag i... må være minst et par måneder.
Vi fikk i det minste litt vann i bakken, for det har vært veldig, veldig tørt her – atypisk tørt.
Hva med deg?
CHET. Vel, jeg kommer meg etter DEF CON til tross for at jeg ikke har deltatt på Defcon, som jeg ikke engang visste var noe.
AND. [LETER] Å, ja!
CHET. Jeg tilbrakte hele helgen med øynene klistret til Twitter og Twitch og Discord og alle disse plattformene som du på en måte kunne pseudo-delta i alle festlighetene.
Og jeg må si, det er mye morsommere når du faktisk er i Las Vegas.
Men med tanke på at antallet personer jeg kjenner som har kommet tilbake med COVID allerede nærmer seg flere fingre og tomler enn jeg har, tror jeg at jeg har gjort det riktige valget, og jeg er glad for å være utslitt av over-internett hele helgen.
AND. Tror du de virkelig har fått en koronavirusinfeksjon, eller kom de bare tilbake med følelsen, hvordan kan jeg si det ... "uvel" på grunn av å ha Black Hat etterfulgt av DEF CON.
CHET. Du vet, så ille som CON FLU kan være...
AND. KON FLUSEN?! [LETER] Å, kjære!
CHET. …Jeg er ganske sikker på at i dette tilfellet er det COVID, fordi ikke bare folk tester, men for de fleste jeg er kjent med, er COVID betydelig mer smertefullt enn til og med CON FLU.
Så de to sammen var nok ekstra forferdelige, må jeg tenke. [LATTER]
AND. Ja!
Men la oss ikke vente på DEF CON coronavirus/CON FLU-problemer ...
…la oss rette oppmerksomheten mot en *tale* som ble holdt på DEF CON.
Dette handler om en Zoom null-dag som ble skrevet opp av Patrick Wardle, og presentert på DEF CON.
Snarere en uheldig serie med feil, inkludert en som ikke ble riktig korrigert, Chester?
CHET. Vel, Patrick er ikke den eneste macOS-sikkerhetsforskeren i verden, men han er ganske fantastisk når det gjelder å finne problemer.
Og siste gang jeg så Patrick Wardle til stede var på Virus Bulletin-konferansen, flere ganger, og hver gang tok han Apple på en måte til skolen over noen tvilsomme avgjørelser om signaturverifisering, sertifikatverifisering, denne typen ting.
Og jeg begynner å få inntrykk av at Apple i stor grad har formet sikkerhetsstillingen deres rundt noen av disse tingene.
Og nå er han ute på jakt etter flere leverandører som kan gjøre lignende kryptografiske feil som kan tillate skadelig programvare på plattformen.
AND. Jeg antar at i gamle dager tenkte alle: "Vel, så lenge du har en TLS-tilkobling," eller, "Så lenge du har noe som er digitalt signert av *noen*."
Så, koden ville ofte ikke gidde å gå og sjekke.
Men i dette tilfellet bestemte de seg for å sjekke nedlastede oppdateringspakker for å sikre at de var fra Zoom.
Men de gjorde det ikke så bra, gjorde de det?
I stedet for å kalle det offisielle system-API, som forsvinner, utfører kontrollen, og kommer i utgangspunktet tilbake med en sann eller usann...
…de har liksom "strikket sine egne", ikke sant?
CHET. Ja.
Jeg mener, å strikke dine egne ting relatert til krypto slutter alltid smertefullt.
Og jeg husker, i den siste podcasten snakket du om den nye kvantesikre kryptoalgoritmen som ble knekt på en time på en bærbar datamaskin.
AND. SIKE!
CHET. Alle var så fokusert på kvantesiden av det at de liksom savnet den konvensjonelle siden, selv blant noen av verdens smarteste matematikere og kryptografer, ikke sant?
Så det er veldig lett å gjøre feil som kan være ødeleggende.
Og å strikke ditt eget er noe du og jeg har snakket om, jeg vil si, i nærmere 20 år, i forskjellige kommunikasjonsformater, på vegne av Sophos.
Og jeg tror aldri vi har endret standpunkt om at det er en forferdelig idé!
AND. Problemet her er ikke at de bestemte seg for å bruke sine egne digitale signaturalgoritmer, eller finne opp sin egen elliptiske kurve.
Det er bare det i stedet for å si: "Her er en fil. Kjære operativsystem, bruk det standardiserte API-baserte verktøyet ditt for å verifisere det og kom tilbake Sant/False,» valgte de i hovedsak å betale ut...
… de kjørte pkgutil kommandolinjeverktøy i bakgrunnen, som er det du kan gjøre fra kommandolinjen hvis du ønsker å få en lesbar, visuell visning av hvem som signerte hva.
Og så skrev de et program som ville sende den tekstbaserte utgangen av dette for å avgjøre om de ønsket å få svaret "sant" eller "usant".
De fikk ut en liste over sertifikatkjeden, og de lette etter "Zoom", etterfulgt av "Developer Certification Authority", etterfulgt av "Apple Root CA".
Så de ser etter disse strengene *hvor som helst i utdataene*, Chester!
Så [ler] det viser seg at hvis du opprettet en pakke som hadde et navn på linje med Zoom Video Communications Inc Developer ID Certification Authority Apple Root CA.pkg, da når pkgutil skrev filnavnet inn i utdataene, ville alle tre magiske strengene vises!
Og Zooms ganske udugelige parser ville bestemme at det bare kunne skje hvis det hadde blitt signert, i riktig rekkefølge, av de tre organisasjonene.
Mens det faktisk bare var navnet du oppga.
Å kjære!
CHET. Problemet her er at det som fører til problemet er denne typen rudimentær signatursjekk som de gjør.
Men det virkelige problemet er selvfølgelig at det betyr at enhver pakke som kan gitt det navnet vil bli installert *som root* på systemet, selv om brukeren som kjører oppdateringsprosessen er uprivilegert.
AND. Det var hele problemet.
Fordi det så ut til at det som skjedde, i tide for DEF CON, *fikset* dette problemet.
De bruker API-en riktig, og de bekrefter pålitelig integriteten og autentisiteten til filen de skal kjøre.
Men da de flyttet den til den midlertidige katalogen som Zoom orkestrerer installasjonen fra, lot de den skrives over hele verden!
Så katalogen var beskyttet, og alt i katalogen var beskyttet ... *bortsett fra den viktigste filen*.
Så gjett hva du kan gjøre?
Hvis du tidsbestemte det akkurat (en såkalt løp tilstand), kunne den opprinnelige brukeren endre filen *etter* den hadde bestått sin digitale identitetssjekk, men *før* den ble brukt for alvor.
Installasjonsprogrammet bruker en fil som den tror har blitt validert, og faktisk ble validert ...
…men ble ugyldig i gapet mellom valideringen og bruken.
CHET. Ja, og som du påpeker i artikkelen, Duck, blir denne typen sårbarhet, snarere enn bare å være en enkel rasetilstand, ofte referert til som en TOCTOU, som for meg høres ut som en slags karibisk fugl.
Men det refererer til et mer komplisert, vitenskapelig navn for feilen, kalt a Time-of-check til Time-of-use.
Så, T-O-C-T-O-U ... "Toctou"!
AND. Som deg har jeg alltid forestilt meg at det var en slags veldig pen polynesisk papegøye.
Men det er faktisk, som du sier, en stygg form for feil der du sjekker faktaene dine, men du sjekker dem for tidlig, og når du kommer til å stole på disse faktaene, har de endret seg.
Så Zoom fikset det – og Patrick Wardle sa at han ga dem gratulasjoner … de fikset det innen én dag etter at han hadde skrevet oppgaven på DEF CON.
De låste rettighetene på filen riktig før de startet prosessen med å validere den i utgangspunktet.
Så valideringen, når den var fullført, forble gyldig til slutten av installasjonen.
Problemet løst.
Skulle egentlig aldri ha vært der i utgangspunktet, burde det vel?
CHET. Hvis du er en Mac-bruker, kan du sjekke versjonsnummeret ditt for å være sikker på at du er på den faste.
Versjonen som er løst er 5.11.5 eller høyere – jeg vet ikke om det har vært utgivelser senere.
[Merk. En ytterligere oppdatering til 5.11.6 kom ut mellom innspilling og publisering av denne episoden.]
AND. Nå betyr det ikke at en utenforstående kan bryte seg inn på datamaskinen din hvis du ikke har denne oppdateringen, men det er et ekkelt problem å ha ...
…hvor en kjeltring som har brutt seg inn i nettverket ditt, men bare har for eksempel gjesteprivilegier, plutselig kan heve seg selv og få root- eller sysadmin-superkrefter.
Det er akkurat det ransomware-skurker elsker å gjøre.
De kommer inn med lav effekt, og så jobber de seg opp til de er på lik linje med de vanlige systemadministratorene.
Og så, dessverre, er det veldig liten grense for hva de kan gjøre for dårlig etterpå.
Chester, la oss gå videre til neste feil.
Dette er en feil kjent som … vel, det er A og E skrevet sammen, som er en gammel engelsk bokstav – den brukes ikke på engelsk lenger, og det er bokstaven som heter ash, men i dette tilfellet er det ment å være APIC/EPIC.
APIC, fordi det påvirker APIC-er Avansert programmerbar avbruddskontroller, og de anser det for å være en EPISK lekkasje.
CHET. Jeg fant det interessant, men la oss begynne med det faktum at jeg ikke synes det er fullt så episk, kanskje, som navnet tilsier.
APIC er absolutt involvert, men jeg er ikke så sikker på EPIC!
Sannheten i saken, når du løser opp alt dette, er at det påvirker en del av Intels prosessorer kjent som SGX, som er ... jeg kommer til å glemme nå ... Software Guard -utvidelser, Jeg vil si?
AND. Du har rett!
CHET. Vel, dette er ikke den første feilen som påvirker SGX.
Jeg talte ikke alle, men jeg fant minst syv tidligere tilfeller, så den har ikke hatt noen god merittliste når det gjelder å gjøre akkurat det den er designet for å gjøre.
Og den eneste praktiske bruken av det jeg kunne finne hvor som helst var at du trenger denne funksjonaliteten for å lagre de hemmelige nøklene for å spille av UltraHD Blu-ray-disker på Windows.
Og med brikker som ikke støtter SGX, har du tilsynelatende ikke lov til å se filmer.
AND. Noe som er ironisk, for Intel har nå, i 12. generasjon av CPU-ene deres... de har avviklet SGX for såkalte "klient"-brikker.
Så brikkene du nå får hvis du har en helt ny bærbar datamaskin – dette gjelder ikke, fordi det ikke er SGX i den.
Det ser ut til at de ser det som noe som kan være nyttig på servere.
CHET. Vel, jeg tror det er rettferdig å si at SGXs skjebne er beseglet ved at Intel allerede har trukket den ut av 12. generasjons CPUer.
Hvis ikke for det faktum at dette er som den åttende forskjellige smarte måten noen har funnet for å trekke ut hemmeligheter ... fra tingen som er designet for å bare holde hemmeligheter.
AND. Ja, det er en påminnelse om at ytelsen kommer i veien.
Fordi min forståelse er at måten dette fungerer på er at den gammeldagse måten å få dataene ut av den programmerbare avbruddskontrolleren, APIC, i utgangspunktet var å lese dem ut av en minneblokk som ble tildelt spesifikt til den enheten.
Minneblokken som ble brukt for avbruddsdataene som ble trukket ut var 4KB … én minneside stor.
Men det var ikke så mye data å trekke ut, og det som var der før – for eksempel i systembufferen – ble skrevet tilbake.
Med andre ord, avbruddsprosessoren tømte ikke ut minnet den skulle bruke før den skrev i bytene den hadde til hensikt å levere.
Så noen ganger leverte den ved et uhell dataverdier fra vilkårlige andre deler av minnet som CPU-en nylig hadde tilgang til.
Og ved å kontrollere hva som skjedde, og i hvilken rekkefølge, fant forskerne at de kunne overtale RAM-innhold som skulle være forseglet i disse SGX "enklavene" til å dukke opp som et slags uinitialisert minne midt i avbruddshåndtering.
Så, alltid en påminnelse om at når du prøver å få fart på ting ved å ta sikkerhetssnarveier, kan du ende opp med alle slags problemer.
CHET. Hvis du skal stole på at denne tingen holder hemmeligheter, trenger den mye gransking.
Og det føles som om denne SGX-teknologien var på en måte halvferdig da den ble lansert.
AND. Kompleksitet kommer alltid med kostnad/risiko, ikke sant?
Hvis du tenker, Chester, tilbake til 6502-prosessoren som var kjent i Apple II, VIC-20, Commodore 64 ... hvis du er fra Storbritannia, var det i BBC Micro.
Jeg tror den brikken hadde rundt 4000 transistorer.
Så det var virkelig en Reduced Instruction Set Chip, eller RISC.
Mens jeg forstår at den nyeste Apple M2-prosessoren har 20 milliarder (som i 20,000,000,000) transistorer, bare i én CPU.
Så, du kan se at når du begynner å legge til ting som avbruddskontrolleren (som kan gå inn i brikken), den sikre enklaven (vel, som kan gå inn i brikken), hyperthreading (som kan gå inn i brikken), [HASTIGHET] OPP MANISK] vektorinstruksjoner (de kan gå inn i brikken), spekulativ utførelse, omorganisering av instruksjoner, flerkjerner...
…alle de tingene, det er ikke overraskende at noen ganger ikke fungerer som du kanskje forventer, og at det tar ganske lang tid før noen legger merke til det.
CHET. Vel, godt arbeid til forskerne som fant det, for det er absolutt interessant forskning.
Og hvis du vil forstå litt mer om det, din Naked Security-artikkel forklarer det utrolig godt for folk som vanligvis ikke er kjent med ting som APIC-kontrollere.
Så jeg anbefaler at folk sjekker det ut, fordi det er et perfekt eksempel på utilsiktede konsekvenser fra enkle avgjørelser tatt om svært komplekse ting.
AND. Jeg synes det er en utmerket måte å si det på. Chester.
Det gir oss også frihet til å gå videre til en annen kontroversiell sak, og det er det faktum at den amerikanske regjeringen er det tilby en belønning som det står er "opp til $10 millioner" for informasjon om Conti ransomware-mannskapet.
Nå ser det ut til at de ikke kjenner noens virkelige navn.
Disse menneskene er bare kjent som Dandis, Professor, Reshaev, Target og Tramp.
Og bildene deres er bare silhuetter...
CHET. Ja, da jeg først så artikkelen, trodde jeg beskrivelsen av forbryterne var som folkene på Gilligan's Island.
Vi har professoren og trampen ... og jeg var ikke helt sikker på hvor dette skulle hen med kallenavnene.
Jeg håper dette forsøket er mer vellykket enn det forrige... Jeg mener, det var en annen gruppe som de tilbød $10 millioner for, som var Evil Corp-gruppen.
Og så vidt jeg vet har ingen arrestasjoner eller noen form for rettslige skritt blitt tatt ennå. Så antagelig var ikke de 10 millioner dollarene for å få Evil Corp nok som et insentiv for folk til å snu på gjerningsmennene til den gruppen.
Så forhåpentligvis er denne litt mer vellykket.
Men det var et fantastisk bilde som forårsaket mange spekulasjoner og samtaler på Twitter og til og med på Naked Security, i innlegget du skrev, av en av de antatte gjerningsmennene.
Vi vet ikke om han er medlem av kontrollgruppen som drev eller drev Ransomware-as-a-Service, eller om han rett og slett kanskje var en tilknyttet selskap som brukte skadevaren, og bidro til å betale provisjoner for dårlig oppnådde gevinster fra ofre.
Men du kunne ikke bli mer stereotypisk russisk ... jeg mener, vi ser på dette: fyren har en rød stjerne på hetten, og jeg spekulerer i en liten flaske vodka i hånden, og det er en balalaika.
Dette er nesten for godt til å være sant.
AND. Og i god hacker-kjole har han på seg en slags puffy jakke med hettegenser på...
… selv om han har hettegenseren nede, så det teller kanskje ikke?
Tror du, Chester, at de har siktet mot Conti-gjengen fordi de så å si hadde litt vanære blant tyver?
For omtrent et år siden ble noen av tilknyttede selskaper veldig oppstemte, hevdet at de ble dratt av, og det var et datainnbrudd, var det ikke der, hvor en av dem dumpet en hel mengde bruksanvisninger og programvarefiler?
CHET. Du vet, det er mange stykker der.
Som du påpeker – jeg tror det var i august 2021 – noen lekket bruksanvisningene deres, eller deres "playbook", som det har blitt referert til.
Etter invasjonen av Ukraina så det ut til at Conti som en enhet kom ut som veldig pro-russisk, noe som fikk en gjeng ukrainere som var en del av planen deres til å snu seg mot dem og lekke en haug med informasjon om deres operasjoner og ting også.
Så det har absolutt vært ting der.
Jeg tror en annen grunn, Duck, ganske enkelt er enorme mengder skader de har forårsaket.
Jeg mener, da vi skrev opp fra vårt Rapid Response Team, var Conti uten tvil den mest produktive gruppen i 2021 som forårsaket skade.
Ingen kjøper egentlig at de er ute av den kriminelle undergrunnen.
Det er ikke slik at de tok pengene sine og gikk bort... de har rett og slett utviklet seg til nye ordninger, og delt seg opp i forskjellige løsepengevaregrupper, og spiller andre roller i samfunnet enn de var.
Og sist kan noen ha hørt at det var noen angrep mot den costaricanske regjeringen som ble tilskrevet Conti, og det var ikke engang veldig lenge siden.
Så jeg tror det er lag her, og et av disse lagene kan være at Dandis, professor, Reshaev...
…disse personene har i viss grad blitt doxx offentlig [fikk personopplysninger lekket bevisst] av folk som hevder å vite hvem de er, men uten å fremlegge bevis som ville være verdig til tiltale og domfellelse.
Og så kanskje dette er et håp om at de kanskje vil trå frem hvis prisen er høy nok, og tenner på sine tidligere kamerater.
AND. Men selv om de alle blir slått i morgen, og de alle blir siktet, og de alle blir dømt, ville det gjøre en innhugg i løsepenge-prosedyrer, ikke sant?
Men dessverre ville det vært en *bulk*, ikke *slutten på*.
CHET. Absolutt.
Dessverre er det den verden vi lever i i disse dager.
Jeg tror vi vil fortsette å se disse forbrytelsene utvikle seg på forskjellige måter, og det vil forhåpentligvis gi litt lettelse etter hvert som vi blir bedre og bedre til å forsvare oss selv.
Men med 25 millioner dollar potensielle løsepenger der ute, er det mange mennesker som er villige til å ta en sjanse og fortsette å begå disse forbrytelsene, enten disse kriminalitetsherrene sitter ved roret eller ikke.
AND. Ja.
Du tenker: «Å, vel, de ville aldri fått 25 millioner dollar. De ville nok nøye seg med mindre til slutt."
Men selv om det tallet kommer ned til for eksempel $250,000 XNUMX..
…som US Rewards for Justice-teamet påpeker: siden 2019 hevder de at Conti-gjengen alene (siterer fra RfJ-siden), at løsepengevaren deres har blitt brukt til å utføre mer enn 1000 løsepengeangrep rettet mot amerikansk og internasjonal kritisk infrastruktur.
Legetjenester, 9-1-1 ekspedisjonssentraler, tettsteder, kommuner.
Og de antyder at av helsevesen og førstehjelpsnettverk alene – ting som ambulansesjåfører, brannvesen, sykehus – har mer enn 400 over hele verden blitt truffet, inkludert 290 i USA.
Så hvis du multipliserer 290 med (jeg bruker gigantiske luftkurser her) med "rabattgebyret" på $250,000 XNUMX som skulle ha gått med til å gi helsetjenester ...
…du får et enormt stort antall uansett.
CHET. Husk for fire år siden da vi publiserte en rapport om SamSam og vi ble overrasket over at de tjente 6 millioner dollar over tre år?
AND. Det er fortsatt mye penger, Chester!
Vel, det er for meg ... kanskje du er en høyflyver. [LATTER]
Jeg vet at du har et emne – vi har ikke skrevet dette om Naked Security, men det er noe du er veldig interessert i...
…og det er det faktum at det ikke kan være «én ring som styrer dem alle» når det gjelder cybersikkerhet.
Spesielt når det gjelder ting som helsetjenester og førstehjelp, der alt som kan komme i veien for å gjøre sikkerheten bedre, faktisk kan gjøre tjenesten farlig dårligere.
Og du har en historie fra National Institutes of Health å fortelle...
CHET. Ja, jeg tror det er en viktig påminnelse om at vi først og fremst er ansvarlige for å håndtere risiko, ikke resultater som ender opp i perfekt sikkerhet.
Og jeg tror mange utøvere glemmer det for ofte.
Jeg ser mange av disse argumentene på gang, spesielt i sosiale medier: "det perfekte er fienden til det gode", som vi også har snakket om tidligere i podcaster ...
…hvor, "Du bør gjøre det på denne måten, og dette er den eneste riktige måten å gjøre det på."
Og jeg synes dette er interessant – dette studie av forholdet mellom sykehus som hadde et datainnbrudd og pasientutfall i kjølvannet av disse datainnbruddene.
Det er kanskje ikke fornuftig på overflaten, men la meg lese de viktigste funnene for deg, som jeg tror gjør det ganske klart hva vi snakker om.
De viktigste funnene er:
Sykehusets tid til elektrokardiogram økte med så mye som 2.7 minutter, og 30-dagers akutt hjerteinfarktdødelighet økte så mye som 0.36 prosentpoeng, i løpet av treårsvinduet etter et datainnbrudd.
I hovedsak er det vi sier en tredjedel av en prosent flere mennesker døde av hjerteinfarkt på sykehus som hadde datainnbrudd etterpå enn før, som en prosentandel av pasienter som hadde dødelige utfall.
AND. Antagelig er implikasjonen det at hvis de hadde vært i stand til å få den elektrokardiogrammaskinen på seg og få resultatene ut og ta en klinisk avgjørelse raskere, kunne de ha vært i stand til å redde et ubetydelig antall av de menneskene som døde?
CHET. Ja, og jeg tror at når du tenker på et travelt sykehus, hvor folk regelmessig kommer inn med hjerteinfarkt og slag, er 1 av 300 pasienter som dør på grunn av nye sikkerhetsprotokoller en slags bekymring.
Og Health and Human Services Administration i USA fortsetter med at de anbefaler at sykehus som har blitt brutt, "nøye vurderer tiltak for å oppnå bedre datasikkerhet uten å påvirke pasientresultatene negativt."
Og jeg tror det virkelig er her vi må være veldig forsiktige, ikke sant?
Vi ønsker alle bedre informasjonssikkerhet, og jeg vil at pasientjournalene mine oppbevares trygt når jeg besøker sykehuset.
Og vi vil absolutt være sikre på at folk ikke får tilgang til datamaskiner og poster de ikke burde, og at folk ikke deler ut medisiner som de ikke burde, som kan være skadelige.
På den annen side er dette liv og død.
Og selv om dette kanskje ikke gjelder for advokatfirmaet ditt, eller markedsføringsselskapet eller fabrikken som du er ansvarlig for sikkerheten til... tror jeg det er en viktig påminnelse om at det ikke finnes én størrelse som passer alle for hvordan vi bør gjøre sikkerhet.
Vi må evaluere hver situasjon, og sørge for at vi skreddersyr den med den risikoen vi er villige til å akseptere.
Og personlig er jeg villig til å akseptere mye større risiko for at journalene mine blir kompromittert enn jeg er risikoen for å dø fordi noen måtte hente en tofaktorkode for å låse opp elektrokardiogrammaskinen!
AND. Vel, Chester, du er en type 1-diabetiker, er du ikke?
Og du har en av de magiske insulinpumpene.
Nå, jeg vedder på at du ikke skynder deg å installere den nyeste Linux-kjernen på det øyeblikket den kommer ut!
CHET. Absolutt!
Jeg mener, disse enhetene går gjennom strenge tester ... det er ikke å si at de er feilfrie, men det kjente er bedre enn det ukjente når du snakker om helsen din og er i stand til å håndtere den.
Og det er absolutt programvarefeil i disse enhetene, og de blir modernisert og inkluderer teknologier som Bluetooth ... eller det store spranget for enheten min var at den fikk en fargeskjerm som forteller deg hvor gammel noe av teknologien som går inn i disse ting er!
Medisinske myndigheter for å godkjenne disse enhetene har en veldig, veldig lang prosess.
Og "utprøvd og sann" (som i den tidligere samtalen om transistorer og prosessorer), enkle ting som vi kan forstå, er mye foretrukket fremfor nye, kompliserte ting som er mye vanskeligere å finne ut og finne disse sikkerhetsfeilene.
Jeg kan ikke forestille meg, hvis det var noe slikt som en patch-tirsdag for denne insulinpumpen, at jeg ville stå i kø for å være den første fyren på blokken på tirsdag for å installere oppdateringen!
For alle dens vorter vet jeg nøyaktig hvordan det fungerer, og hvordan det ikke gjør det.
Og til poenget ditt, jeg sameksisterer godt med det...
… enheten kjenner sitt ansvar for å holde seg konsekvent, og jeg har lært hvordan jeg kan utnytte den til min fordel for å forbedre helsen min.
Enhver endring i det kan være skummelt og forstyrrende.
Så svaret er ikke alltid bedre, raskere og smartere.
Noen ganger er det "kjente kjente" i påliteligheten og tilliten.
AND. Når det er sagt, hjelper det også å ikke ha datainnbrudd!
Og det er noen overraskende enkle ting du kan gjøre for å beskytte organisasjonen din mot at data kommer ut der de ikke burde.
CHET. Og en av tingene, Duck, er at vi ikke har tiden vi pleide å ha.
Kriminelle skanner hele tiden internett på jakt etter noen av disse feilene du kan ha gjort, enten det er en utdatert policy å tillate for mange ting, eller om det er eksponerte tjenester som kanskje var helt greit å avsløre for ti år siden, men som nå er farlige å ha. eksponert for Internett.
AND. "RDP glemte den gang."
CHET. Ja, vel, jeg er trist å tenke på at RDP fortsetter å komme opp, men faktisk, på Black Hat forrige uke, ga vi nettopp ut et papir og skrev en blogg om en situasjon der en organisasjon hadde tre forskjellige løsepenge-angrep i løpet av få uker, alle innenfor samme organisasjon, som skjedde noe samtidig.
Og det er ikke første gang vi har sett mer enn én angriper i et nettverk.
Jeg tror det kan være første gang vi har sett *tre* i samme nettverk.
AND. Å herregud, overlappet de hverandre?
Hadde de bokstavelig talt fortsatt å gjøre med angrep A da angrep B kom?
CHET. Ja, jeg tror det var et gap mellom angriper B og angriper C, men A og B var inne på samme tid, og kom antagelig inn på grunn av nøyaktig samme verktøyfeil for fjerntilgang som de begge hadde funnet og utnyttet.
Og så, tror jeg, gruppe B installerte sitt eget fjerntilgangsverktøy, på en måte som en sekundær bakdør i tilfelle den første ble lukket...
…og gruppe C fant fjerntilgangsverktøyet sitt og kom inn.
AND. Golly... vi burde ikke le, men det er liksom en komedie av feil.
Det er lett å si: "Vel, i et hvilket som helst halvt godt administrert nettverk bør du vite hva det offisielle fjerntilgangsverktøyet ditt er, slik at alt som ikke er det, bør skille seg ut åpenbart."
Men la meg spørre lytterne våre dette: Hvis du er ansvarlig for et nettverk, kan du legge hånden på hjertet ditt og fortelle meg nøyaktig hvor mange telekonferanseverktøy du har i bruk i bedriften din akkurat nå?
CHET. Ja absolutt.
Vi hadde ett offer vi skrev opp tidligere i år som jeg tror hadde *åtte* forskjellige fjerntilgangsverktøy som vi fant under etterforskningen vår, noen av dem ble lovlig brukt for ti år siden, og de sluttet å bruke dem, men fjernet dem aldri.
Og andre som hadde blitt introdusert av flere trusselaktører.
Så dette er absolutt noe å holde øye med!
AND. Vel, Chester, la oss håpe det er et optimistisk nok forslag til å avslutte, for vi er ute av tid denne uken.
Tusen takk, som alltid, for at du tok opp mikrofonen på veldig kort varsel.
Og som alltid gjenstår det bare for meg å si: Til neste gang...
BÅDE. Hold deg trygg!
[MUSIKK MODEM]
- AEPISK
- blockchain
- coingenius
- Conti
- cryptocurrency lommebøker
- kryptoverveksling
- kryptografi
- cybersikkerhet
- nettkriminelle
- Cybersecurity
- innenriksdepartementet
- digitale lommebøker
- brannmur
- helsetjenester
- Intel
- Kaspersky
- Lov og orden
- malware
- Mcafee
- Naken sikkerhet
- Naken sikkerhetspodcast
- NexBLOC
- plato
- plato ai
- Platon Data Intelligence
- Platon spill
- PlatonData
- platogaming
- podcast
- privatliv
- ransomware
- VPN
- nettside sikkerhet
- zephyrnet
- zoom
