Klicka och dra på ljudvågorna nedan för att hoppa till valfri punkt. Du kan också lyssna direkt på Soundcloud.
Med Paul Ducklin och Chester Wisniewski.
Intro och outro musik av Edith Mudge.
Du kan lyssna på oss på soundcloud, Apple Podcasts, Google Podcasts, Spotify, häft och överallt där bra poddar finns. Eller bara släpp URL till vårt RSS-flöde till din favoritpodcatcher.
LÄS TRANSKRIPTET
[MUSIKALT MODEM]
ANKA. Välkommen till podden, alla.
Jag är inte Douglas... jag är Paul Ducklin.
Doug är på semester, så jag får sällskap av min gode vän och kollega, Chester Wisniewski, från vårt kontor i Vancouver.
Hej, Chet!
CHET. Hej Anka.
Hur mår du
ANKA. Jag mår väldigt bra tack.
Vi hade vårt första regn i Oxfordshire idag för... måste vara minst ett par månader.
Vi fick i alla fall ner lite vatten i marken, för det har varit väldigt, väldigt torrt här – atypiskt torrt.
Vad tycker du?
CHET. Tja, jag håller på att återhämta mig från DEF CON trots att jag inte har gått på Defcon, vilket jag inte ens visste var något.
ANKA. [SKratt] Åh, ja!
CHET. Jag tillbringade hela helgen med ögonen klistrade vid Twitter och Twitch och Discord och alla dessa plattformar som man på distans kunde pseudodeltaga i alla festligheter.
Och, jag måste säga, det är mycket roligare när du faktiskt är i Las Vegas.
Men med tanke på att antalet människor jag känner som har kommit tillbaka med covid redan närmar sig fler fingrar och tummar än vad jag har, tror jag att jag gjorde rätt val, och jag är glad över att vara utmattad av överinternet hela helgen.
ANKA. Tror du att de verkligen fick en coronavirusinfektion, eller kom de bara tillbaka med känslan, hur kan jag uttrycka det... "illamående" på grund av att de har Black Hat följt av DEF CON.
CHET. Du vet, så illa som CON FLU kan vara...
ANKA. KON FLUSEN?! [skrattar] Åh, kära!
CHET. …Jag är ganska säker på att det i det här fallet är covid, för det är inte bara människor som testar, utan för de flesta människor jag är bekant med är covid betydligt mer smärtsamt än till och med CON FLU.
Så de två kombinerade var nog extra hemska.
ANKA. Jag måste tänka: ja.
Men låt oss inte dröja vid problem med DEF CON coronavirus/CON FLU...
…låt oss rikta vår uppmärksamhet mot ett föredrag som hölls på DEF CON.
Det här handlar om en Zoom noll-dag som skrevs upp av Patrick Wardle och presenterades på DEF CON.
Snarare en olycklig serie av buggar, inklusive en som inte blev ordentligt korrigerad, Chester?
CHET. Tja, Patrick är inte den enda macOS-säkerhetsforskaren i världen, men han är ganska fantastisk på att hitta problem.
Och sista gången jag såg Patrick Wardle närvarande var på Virus Bulletin-konferensen, flera gånger, och varje gång tog han Apple till skolan över några tvivelaktiga beslut om signaturverifiering, certifikatverifiering, den här typen av saker.
Och jag börjar få intrycket av att Apples till stor del format sin säkerhetsställning kring några av dessa saker.
Och så nu är han ute och letar efter ytterligare leverantörer som kan göra liknande kryptografiska fel som kan tillåta skadlig programvara på plattformen.
ANKA. Jag antar att förr i tiden tänkte alla, "Tja, så länge du har en TLS-anslutning" eller, "så länge du har något som är digitalt signerat av någon."
Så, kod skulle ofta inte bry sig om att gå och kolla.
Men i det här fallet bestämde de sig för att kontrollera nedladdade uppdateringspaket för att se till att de var från Zoom.
Men de gjorde det inte så bra, eller hur?
Istället för att anropa det officiella systemets API, som försvinner, gör kontrollen och i princip kommer tillbaka med en sann eller falsk ...
…de typ "stickade sina egna", eller hur?
CHET. Ja.
Jag menar, att sticka dina egna saker relaterade till krypto slutar alltid smärtsamt.
Och jag minns att du i förra podcasten pratade om den nya kvantsäkra kryptoalgoritmen som knäcktes på en timme på en bärbar dator.
ANKA. SIKE!
CHET. Alla var så fokuserade på kvantsidan av det att de typ missade den konventionella sidan, även bland några av världens smartaste matematiker och kryptografer, eller hur?
Så det är verkligen lätt att göra misstag som kan vara förödande.
Och att sticka eget är något som du och jag har pratat om, vill jag säga, i närmare 20 år, i olika kommunikationsformat, på uppdrag av Sophos.
Och jag tror aldrig att vi har ändrat vår ståndpunkt att det är en hemsk idé!
ANKA. Problemet här är inte att de bestämde sig för att använda sina egna digitala signaturalgoritmer, eller uppfinna sin egen elliptiska kurva.
Det är bara det istället för att säga: ”Här är en fil. Bästa operativsystem, använd dina standardiserade API-baserade verktyg för att verifiera det och återkomma Sant/falskt”, valde de att i huvudsak betala ut.
De drev pkgutil kommandoradsverktyg i bakgrunden, vilket är vad du kan göra från kommandoraden om du vill få en läsbar, visuell visning av vem som signerade vad.
Och sedan skrev de ett program som skulle skicka den textbaserade produktionen av detta för att avgöra om de ville få svaret "sant" eller "falskt".
De fick ut en lista över certifikatkedjan, och de letade efter "Zoom", följt av "Developer Certification Authority", följt av "Apple Root CA".
Så de letar efter dessa strängar *var som helst i utgången*, Chester!
Så det visar sig att om du skapade ett paket som hade ett namn i stil med Zoom Video Communications Inc Developer ID Certification Authority Apple Root CA.pkg, då när pkgutil skrev filnamnet i dess utdata, alla tre magiska strängarna skulle dyka upp!
Och Zooms ganska odugliga parser skulle besluta att det bara kunde hända om det hade undertecknats, i rätt ordning, av dessa tre organisationer.
Medan det faktiskt bara var namnet du angav.
Kära nån!
CHET. Problemet här är att det som leder till problemet är den här typen av rudimentär signaturkontroll som de gör.
Men det verkliga problemet är naturligtvis att alla paket som kan få det namnet kommer att installeras *som root* på systemet, även om användaren som kör uppdateringsprocessen är oprivilegierad.
ANKA. Det var hela problemet.
Eftersom det verkade som att det som hände, i tid för DEF CON, *fixade* det här problemet.
De använder API:t på rätt sätt och de verifierar på ett tillförlitligt sätt integriteten och äktheten hos filen de ska köra.
Men när de flyttade den till den tillfälliga katalogen från vilken Zoom orkestrerar installationen, lämnade de det världsskrivbart!
Så, katalogen var skyddad, och allt i katalogen var skyddad... *förutom den viktigaste filen*.
Så gissa vad du kan göra?
Om du tog rätt tid (en sk loppskick), kunde den ursprungliga användaren ändra filen *efter* att den hade klarat sin digitala identitetskontroll, men *innan* den användes på allvar.
Installationsprogrammet använder en fil som den tror har validerats och som faktiskt har validerats...
…men blev ogiltig i gapet mellan valideringen och användningen.
CHET. Ja, och som du påpekar i artikeln, Anka, kallas denna typ av sårbarhet, snarare än att bara vara ett enkelt rastillstånd, ofta som en TOCTOU, vilket för mig låter som någon sorts karibisk fågel.
Men det syftar på ett mer komplicerat, vetenskapligt namn för felet, kallat a Time-of-check till Time-of-use.
Så TOCTOU... "Toctou"!
ANKA. Precis som du har jag alltid föreställt mig att det var någon sorts väldigt vacker polynesisk papegoja.
Men det är faktiskt, som du säger, en ful form av bugg där du kontrollerar dina fakta, men du kontrollerar dem för tidigt och när du kommer att förlita dig på dessa fakta har de förändrats.
Så Zoom fixade det – och Patrick Wardle sa att han gratulerade dem… de fixade det inom en dag efter att han hade skrivit tidningen på DEF CON.
De låste privilegierna på filen korrekt innan de började validera den i första hand.
Så valideringen, när den väl var klar, förblev giltig till slutet av installationen.
Problemet löst.
Borde dock aldrig ha varit där i första hand, eller hur?
CHET. Om du är en Mac-användare kan du kontrollera ditt versionsnummer för att vara säker på att du är på den fasta.
Den version som är fixad är 5.11.5 eller högre. Jag vet inte om det har släppts efteråt.
[Notera. En ytterligare uppdatering till 5.11.6 kom ut mellan inspelning och publicering av detta avsnitt.]
ANKA. Nu betyder det inte att en utomstående kan bryta sig in i din dator om du inte har den här patchen, men det är ett otäckt problem att ha...
…där en skurk som har brutit sig in i ditt nätverk men bara har, säg gästprivilegier, plötsligt kan höja sig själv och få "root" eller "admin" superkrafter.
Det är precis vad ransomware-skurkar älskar att göra.
De kommer in med låg effekt, och sedan arbetar de sig upp tills de är jämställda med de vanliga systemadministratörerna.
Och sedan finns det tyvärr väldigt liten gräns för vad de kan göra för dåligt efteråt.
Chester, låt oss gå vidare till nästa bugg.
Detta är också en känd bugg, det är A och E skrivna tillsammans, vilket är en gammal engelsk bokstav... den används inte längre på engelska, och det är bokstaven som heter Ash, men i det här fallet är det menat att vara APIC/EPIC.
APIC, eftersom det påverkar APIC:er Avancerad programavbrottskontroll, och de anser att det är en EPISK läcka.
CHET. Jag tyckte det var intressant, men låt oss börja med det faktum att jag kanske inte tycker att det är riktigt så episkt som namnet antyder.
APIC är verkligen inblandad, men jag är inte så säker på EPIC!
Sanningen i saken, när du reder ut allt detta, är att det påverkar en del av Intels processorer som kallas SGX, vilket är... Jag kommer att glömma det nu... Software Guard -tillägg, Jag vill säga?
ANKA. Du har rätt!
CHET. Tja, detta är inte det första felet som påverkar SGX.
Jag räknade inte alla, men jag hittade minst sju tidigare instanser, så det har inte haft någon bra meritlista när det gäller att göra just det den är designad för att göra.
Och den enda praktiska användningen av det jag kunde hitta någonstans var att du behöver den här funktionen för att lagra de hemliga nycklarna för att spela upp UltraHD Bluray-skivor på Windows.
Och med chips som inte stöder SGX får du tydligen inte titta på film.
ANKA. Vilket är ironiskt, eftersom Intel har nu, i den 12:e generationen av sina CPU:er... de har avbrutit SGX för så kallade "klient"-chips.
Så markerna som du nu får om du har en helt ny bärbar dator – detta gäller inte, eftersom det inte finns någon SGX i den.
Det verkar som om de ser det som något som kan vara användbart på servrar.
CHET. Tja, jag tycker att det är rättvist att säga att SGX:s öde har beseglats genom att Intel redan har tagit ut den ur 12:e generationens processorer.
Om inte för det faktum att det här är som det åttonde olika smarta sättet som någon har hittat för att extrahera hemligheter... från det som är designat för att bara hålla hemligheter.
ANKA. Ja, det är en påminnelse om att prestation kommer i vägen.
För min uppfattning är att sättet detta fungerar är att det gammaldags sättet att få ut data från programgränssnittskontrollern, APIC, i princip var att läsa den ur ett minnesblock som var tilldelat specifikt till den enheten.
Minnesblocket som användes för avbrottsdata som extraherades var 4KB... en minnessida stor.
Men det fanns inte så mycket data att extrahera, och det som fanns innan – till exempel i systemcachen – skrevs tillbaka.
Med andra ord, avbrottsprocessorn spolade inte ur minnet den skulle använda innan den skrev in de bytes som den avsåg att leverera.
Så ibland levererade den av misstag datavärden från godtyckliga andra delar av minnet som CPU:n nyligen hade tillgång till.
Och genom att kontrollera vad som hände, och i vilken ordning, fann forskarna att de kunde övertala RAM-innehåll som skulle vara förseglat i dessa SGX "enklaver" att dyka upp som ett slags oinitierat minne mitt under avbrottshantering.
Så, alltid en påminnelse om att när du försöker påskynda saker och ting genom att ta säkerhetsgenvägar, kan du sluta med alla möjliga problem.
CHET. Om du ska lita på att den här saken håller hemligheter behöver den en hel del granskning.
Och det känns som att den här SGX-tekniken var halvfärdig när den lanserades.
ANKA. Komplexitet kommer alltid med kostnadsrisk, eller hur?
Om du tänker, Chester, tillbaka till 6502-processorn som var berömd i Apple II, VIC-20, Commodore 64... om du är från Storbritannien, var det i BBC Micro.
Jag tror att chipset hade cirka 4000 transistorer.
Så det var verkligen ett Reduced Instruction Set Chip, eller RISC.
Medan jag förstår att den senaste Apple M2-processorn har 20 miljarder (som i 20,000,000,000 XNUMX XNUMX XNUMX) transistorer, bara i en CPU.
Så, du kan se att när du börjar lägga till saker som avbrottskontrollern (som kan gå in i chippet), den säkra enklaven (nåja, den kan gå i chippet), hypertrådning (som kan gå i chipet), [SPEEDING UPP MANISKT] vektorinstruktioner (de kan gå in i chippet), spekulativ exekvering, instruktionsomordning...
…allt det där är det inte förvånande att saker ibland inte fungerar som man kan förvänta sig, och att det tar ganska lång tid för någon att märka.
CHET. Bra jobbat till forskarna som hittade det, för det är verkligen intressant forskning.
Och om du vill förstå lite mer om det, förklarar din Naked Security-artikel det otroligt bra för människor som normalt inte är bekanta med saker som APIC-kontroller.
Så jag rekommenderar att folk kollar upp det, eftersom det är ett perfekt exempel på oavsiktliga konsekvenser av enkla beslut som fattats om mycket komplexa saker.
ANKA. Jag tycker att det är ett utmärkt sätt att uttrycka det. Chester.
Det ger oss också frihet att gå vidare till en annan kontroversiell fråga, och det är det faktum att den amerikanska regeringen är det erbjuda en belöning som det står är "upp till 10 miljoner dollar" för information om Conti ransomware-teamet.
Nu verkar det som att de inte känner till någons riktiga namn. Dessa människor är bara kända som Dandis, Professor, Reshaev, Target och Tramp.
Och deras bilder är bara silhuetter...
CHET. Ja, när jag först såg artikeln trodde jag att beskrivningen av brottslingarna var som människorna på Gilligan's Island.
Vi har professorn och luffaren... och jag var inte helt säker på vart det här var på väg med smeknamnen.
Jag hoppas att detta försök är mer framgångsrikt än det förra... Jag menar, det fanns en annan grupp som de erbjöd $10 miljoner för, vilket var Evil Corp-gruppen.
Och såvitt jag vet har inga arresteringar eller någon form av rättslig åtgärd vidtagits ännu. Så förmodligen var 10 miljoner dollar för att få Evil Corp inte tillräckligt som ett incitament för människor att vända på förövarna i den gruppen.
Så förhoppningsvis är den här lite mer framgångsrik.
Men det var ett fantastiskt foto som orsakade många spekulationer och samtal på Twitters och till och med på Naked Security i inlägget som du skrev upp av en av de påstådda förövarna.
Vi vet inte om han är medlem i kontrollgruppen som drev eller drev Ransomware-as-a-Service, eller om han helt enkelt kanske var en affiliate som använde den skadliga programvaran och bidrog till att betala provisioner för oförglömda vinster från offer.
Men du kan inte bli mer stereotypt rysk... Jag menar, vi tittar på det här: killen har en röd stjärna på mössan, och jag spekulerar i en liten flaska vodka i handen, och det finns en balalaika.
Det här är nästan för bra för att vara sant.
ANKA. I bra hackerklänning har han en sorts pösig jacka med luvtröja på...
…fast han har hoodien nere, så det kanske inte räknas?
Tror du, Chester, att de har riktat sig mot Conti-gänget för att de så att säga hade lite vanära bland tjuvar?
För ungefär ett år sedan blev några av affiliates väldigt upprörda, hävdade att de blev lurade och att det fanns ett dataintrång, var det inte där, där en av dem dumpade en hel mängd bruksanvisningar och programvarufiler?
CHET. Du vet, det finns många bitar där.
Som du påpekar – jag tror att det var i augusti 2021 – läckte någon deras bruksanvisningar, eller deras "playbook", som det har hänvisats till.
Efter invasionen av Ukraina verkade Conti som entitet vara väldigt pro-rysk. Vilket fick ett gäng ukrainare som var en del av deras plan att vända sig mot dem och läcka en massa information om deras verksamhet och saker också.
Så det har säkert funnits saker där.
Jag tror att en annan anledning, Duck, helt enkelt är den enorma mängd skada de har orsakat.
Jag menar, när vi gjorde våra skrivningar från vårt Rapid Response Team, var Conti utan tvekan den mest produktiva gruppen 2021 som orsakade skada.
Ingen köper verkligen att de är utanför den kriminella underjorden.
Det är inte som att de tog sina pengar och gick därifrån... de har helt enkelt utvecklats till nya system och delat upp sig själva i olika ransomware-grupper och spelar andra roller i samhället än de gjorde.
Och senast kan en del ha hört att det förekom några attacker mot Costa Ricas regering som tillskrevs Conti, och det var inte ens särskilt länge sedan.
Så jag tror att det finns lager här, och ett av dessa lager kan vara att Dandi, Protessor, Reshaev...
…dessa personer har i viss mån blivit doxxed offentligt [fått personuppgifter läckta medvetet] av människor som påstår sig veta vem de är, men utan att tillhandahålla bevis som skulle vara värda åtal och fällande domar.
Och så kanske det här är en förhoppning om att de kanske kliver fram om priset är tillräckligt högt, och vänder sig mot sina tidigare kamrater.
ANKA. Men även om de alla blir fastnade imorgon, och de alla åtalas, och de alla blir dömda, skulle det väl göra ett hack i ransomware-förfarandet?
Men tyvärr skulle det vara en buckla, inte "slutet på".
CHET. Absolut.
Tyvärr, den värld vi lever i nuförtiden, tror jag att vi kommer att fortsätta att se dessa brott utvecklas på olika sätt, och det kommer förhoppningsvis att ge lite lättnad när vi blir bättre och bättre på att försvara oss själva.
Men med $25 miljoner potentiella lösensummor där ute, finns det massor av människor som är villiga att ta en chans och fortsätta att begå dessa brott, oavsett om dessa brottsherrar sitter vid rodret eller inte.
ANKA. Ja.
Du tänker, "Åh, de skulle aldrig få 25 miljoner dollar. De skulle förmodligen nöja sig med mindre till slut.”
Men även om den siffran kommer ner till, säg, $250,000 XNUMX..
...som US Rewards for Justice-teamet påpekar: sedan 2019 hävdar de att Conti-gänget ensamt (citerar från RfJ-webbplatsen), att deras ransomware har använts för att utföra mer än 1000 ransomware-attacker riktade mot amerikansk och internationell kritisk infrastruktur.
Sjukvård, 9-1-1 utskänkningscentraler, orter, kommuner.
Och de antyder att enbart av hälso- och sjukvårds- och första räddningsnätverk – saker som ambulansförare, brandkårer, sjukhus – har mer än 400 över hela världen drabbats, inklusive 290 i USA.
Så, om du multiplicerar 290 med (jag använder gigantiska luftkurser här) med "rabattavgiften" på $250,000 XNUMX som borde ha gått till att tillhandahålla sjukvård...
…du får ett enormt stort antal ändå.
CHET. Kommer du ihåg för fyra år sedan när vi publicerade en rapport om SamAam och vi blev förvånade över att de tjänade 6 miljoner dollar under tre år?
ANKA. Det är fortfarande mycket pengar, Chester!
Tja, det är för mig...kanske du är en högflygare. [SKRATT]
Jag vet att du har ett ämne som vi inte har skrivit om det här om Naked Security, men det är något som du är väldigt intresserad av.
Och det är det faktum att det inte kan finnas "en ring som styr dem alla" när det gäller cybersäkerhet.
Särskilt när det kommer till saker som sjukvård och första responders, där allt som kan komma i vägen för att förbättra säkerheten faktiskt kan göra tjänsten farligt sämre.
Och du har en historia från National Institutes of Health att berätta...
CHET. Ja, jag tycker att det är en viktig påminnelse om att vi först och främst är ansvariga för att hantera risker, inte resultat som hamnar i perfekt säkerhet.
Och jag tror att många utövare glömmer det för ofta.
Jag ser många av dessa argument pågå, särskilt i sociala medier, där "det perfekta är det godas fiende", som vi har pratat om tidigare i podcaster också...
… där, "Du borde göra det på det här sättet, och det här är det enda rätta sättet att göra det."
Och jag tycker att det här är intressant – det här studie av relationen mellan sjukhus som hade ett dataintrång och patientutfall i kölvattnet av dessa dataintrång.
Det kanske inte är vettigt på ytan, men låt mig läsa upp de viktigaste resultaten för dig, som jag tror gör det ganska tydligt vad vi pratar om. De viktigaste resultaten är:
Sjukhusets tid till elektrokardiogram ökade så mycket som 2.7 minuter, och 30 dagars dödlighet i akut hjärtinfarkt ökade så mycket som 0.36 procentenheter under treårsperioden efter ett dataintrång.
I grund och botten, vad vi säger är en tredjedel av en procent fler människor dog av hjärtinfarkt på sjukhus som hade dataintrång efteråt än tidigare, som en procentandel av patienter som hade dödliga utfall.
ANKA. Antagligen är implikationen där att om de hade kunnat få den där elektrokardiogrammaskinen på sig och få ut resultaten och fatta ett kliniskt beslut snabbare, skulle de ha kunnat rädda ett obetydligt antal av de människor som dog?
CHET. Ja, och jag tror att när man tänker på ett hektiskt sjukhus, där människor regelbundet kommer in med hjärtinfarkt och stroke, så är 1 av 300 patienter som dör på grund av nya säkerhetsprotokoll ett slags oro.
Och Health and Human Services Administration i USA fortsätter att de rekommenderar att sjukhus som har brutit mot "noggrannt utvärderar avhjälpande säkerhetsinitiativ för att uppnå bättre datasäkerhet utan att negativt påverka patientresultaten."
Och jag tror att det verkligen är här vi måste vara extra försiktiga, eller hur?
Vi vill alla ha bättre informationssäkerhet och jag vill att mina patientjournaler ska förvaras säkert när jag besöker sjukhuset.
Och vi vill verkligen vara säkra på att människor inte får tillgång till datorer och register som de inte borde, och att människor inte delar ut mediciner som de inte borde, vilket kan vara skadligt.
Å andra sidan är detta liv och död.
Och även om detta kanske inte gäller din advokatbyrå, eller marknadsföringsföretag eller fabrik som du är ansvarig för säkerheten för... Jag tror att det är en viktig påminnelse om att det inte finns någon storlek som passar alla för hur vi ska göra säkerhet.
Vi måste utvärdera varje situation och se till att vi skräddarsyr den med den risk som vi är villiga att acceptera.
Och personligen är jag villig att acceptera mycket större risk för att mina journaler äventyras än att jag riskerar att dö eftersom någon var tvungen att hämta en tvåfaktorskod för att låsa upp EKG-maskinen!
ANKA. Tja, Chester, du är typ 1-diabetiker, eller hur?
Och du har en av de där magiska insulinpumparna.
Nu slår jag vad om att du inte skyndar dig att installera den senaste Linux-kärnan i det ögonblicket den kommer ut!
CHET. Absolut!
Jag menar, dessa enheter går igenom rigorösa tester... det betyder inte att de är buggfria, men det kända är bättre än det okända när du pratar om din hälsa och att kunna hantera den.
Och visst finns det programvarubuggar i dessa enheter när de moderniseras och inkluderar teknologier som Bluetooth… eller det stora steget för min enhet var att den fick en färgskärm, som berättar hur gammal en del av tekniken som används i dessa saker är!
De medicinska myndigheterna för att godkänna dessa enheter har en mycket, mycket lång process.
Och "beprövad och sann" (i det tidigare samtalet om transistorer och processorer), enkla saker som vi kan förstå, är mycket föredragna framför nya, komplicerade saker som är mycket svårare att ta reda på för att hitta dessa säkerhetsbrister.
Jag kan inte föreställa mig, om det fanns något sådant som en patch tisdag för denna insulinpump, att jag skulle stå i kö för att vara den första killen på blocket på tisdag för att installera uppdateringen!
Trots alla våra vårtor vet jag exakt hur det fungerar och hur det inte gör det.
Och till din poäng, hur kan man samexistera med det.
Enheten vet sitt ansvar att vara konsekvent, och jag har lärt mig hur man utnyttjar den till min fördel för att förbättra min hälsa.
Varje förändring i det kan vara skrämmande och störande.
Så svaret är inte alltid bättre, snabbare och smartare.
Ibland är det "kända kända" i tillförlitligheten och förtroendet.
ANKA. Med det sagt hjälper det också att inte ha dataintrång!
Och det finns några förvånansvärt enkla saker du kan göra för att skydda din organisation från att data kommer ut där den inte borde.
CHET. Och en av sakerna, Duck, är att vi inte har den tid vi brukade ha.
Brottslingar söker ständigt igenom internet och letar efter något av dessa misstag du kan ha gjort, oavsett om det är en föråldrad policy att tillåta för många saker eller om det är exponerade tjänster som kanske var helt okej att avslöja för tio år sedan, men som nu är farliga att ha exponeras för Internet.
ANKA. "RDP glömde den gången."
CHET. Ja, jag är ledsen att tro att RDP fortsätter att dyka upp, men faktiskt, på Black Hat förra veckan, släppte vi precis en tidning och skrev en blogg om en situation där en organisation hade tre olika ransomware-attacker inom några veckor, alla inom samma organisation, som inträffade något samtidigt.
Och det är inte första gången vi har sett mer än en angripare i ett nätverk.
Jag tror att det kan vara första gången vi har sett *tre* i samma nätverk.
ANKA. Herregud, överlappade de varandra?
Hade de bokstavligen fortfarande att göra med attack A när attack B kom?
CHET. Ja, jag tror att det fanns ett gap mellan angripare B och angripare C, men A och B var med samtidigt och antagligen kom in genom exakt samma fel på verktyget för fjärråtkomst som de båda hade hittat och utnyttjat.
Och sedan, tror jag, installerade grupp B sitt eget fjärråtkomstverktyg, ungefär som en sekundär bakdörr ifall den första stängdes...
…och grupp C hittade sitt fjärråtkomstverktyg och kom in.
ANKA. Golly... vi borde inte skratta, men det är en sorts komedi av misstag.
Det är lätt att säga: "Tja, i vilket halvt välskött nätverk som helst bör du veta vad ditt officiella fjärråtkomstverktyg är, så att allt som inte är det självklart ska sticka ut."
Men låt mig fråga våra lyssnare detta: Om du är ansvarig för ett nätverk, kan du lägga handen på ditt hjärta och berätta exakt hur många telekonferensverktyg du har i ditt företag just nu?
CHET. Ja absolut.
Vi hade ett offer som vi skrev upp tidigare i år som jag tror hade *åtta* olika fjärråtkomstverktyg som vi hittade under vår undersökning, av vilka några användes lagligt för tio år sedan, och de slutade bara använda dem men tog aldrig bort dem.
Och andra som hade introducerats av flera hotaktörer.
Så det här är verkligen något att hålla utkik efter!
ANKA. Nåväl, Chester, låt oss hoppas att det är ett tillräckligt optimistiskt förslag att avsluta på, för vi har inte tid den här veckan.
Tack så mycket, som alltid, för att du steg upp till mikrofonen med mycket kort varsel.
Och som alltid återstår det bara för mig att säga: Tills nästa gång...
BÅDE. Håll dig säker!
[MUSIKALT MODEM]
