S3 Ep107: Åtte måneder på å sparke ut skurkene, og du synes det er BRA? [Lyd + tekst]

Klikk og dra på lydbølgene nedenfor for å hoppe til et hvilket som helst punkt. Du kan også lytte direkte på Soundcloud.

DOUG.  Mange patcher, grufulle terapiøkter og casestudier innen dårlig nettsikkerhet.

Alt det, og mer, på Naked Security-podcasten.

[MUSIKK MODEM]

Velkommen til podcasten, alle sammen.

Jeg er Doug Aamoth; han er Paul Ducklin.

Paul, hvordan har du det?

Vi har et stort show i dag.

---

AND.  Ja, la oss håpe vi kommer oss gjennom dem alle, Doug!

---

DOUG.  La oss gjøre vårt beste!

Vi starter selvfølgelig med vårt Tech History-segment...

..denne uken, 02. november 1815, ble George Boole født i Lincolnshire, England.

Paul, sant eller usant: Boole ga flere gode bidrag til matematikk, informasjonsalderen og videre?

HVIS du har litt kontekst SÅ hører jeg gjerne på den ELLERS kan vi gå videre.

---

AND.  Vel, Doug, la meg bare si det, for jeg forberedte noe jeg kunne lese opp...

…e skrev et veldig kjent vitenskapelig arbeid med tittelen, og du vil se hvorfor jeg skrev det ned [LETER]:

En undersøkelse av tankelovene som de matematiske teoriene om logikk og sannsynlighet er basert på

---

DOUG.  Ruller rett av tungen!

---

AND.  Han var rett bak symbolsk logikk, og han påvirket Augustus De Morgan. (Folk kjenner kanskje til De Morgans lover.)

Og DeMorgan var Ada Lovelace sin matematikklærer.

Hun tok disse store ideene om symbolsk logikk og tenkte: "Hei, når vi får programmerbare datamaskiner, kommer dette til å forandre verden!"

Og hun hadde rett! [LETER]

---

DOUG.  Utmerket.

Tusen takk, George Boole, må du hvile i fred.

Paul, vi har massevis av oppdateringer å snakke om denne uken, så hvis du kunne oppdatere oss om alle disse oppdateringene...

La oss begynne med OpenSSL:

Historien om OpenSSL-sikkerhetsoppdatering – hvordan kan du fortelle hva som må fikses?

---

AND.  Ja, det er den alle har ventet på.

OpenSSL gjør det stikk motsatte av Apple, som sier absolutt ingenting før oppdateringene akkurat kommer. [LATTER]

OpenSSL sier: "Hei, vi kommer til å gi ut oppdateringer på XYZ-datoen, så du vil kanskje gjøre deg klar. Og den verste oppdateringen i denne batchen vil ha nivået ..."

Og denne gangen skrev de KRITISK med store bokstaver.

Det skjer ikke ofte med OpenSSL, og når de er et kryptografisk bibliotek, tenker alle tilbake på... hva var det, 2014?

«Å, nei, det kommer til å bli som dårlig som Heartbleed igjen, fordi det kan være, for alt du vet:

Anatomien til en datalekkasjefeil – OpenSSL "Heartbleed" bufferoverløp

Så vi hadde en uke med venting og bekymringer, og "Hva skal vi gjøre?"

Og 01. november 2022, oppdateringene faktisk falt.

La oss starte med tallene: OpenSSL 1.1.1 går til versjon S-for-Sierra, fordi den bruker bokstaver for å betegne de individuelle oppdateringene.

Og OpenSSL 3.0 går til 3.0.7:

OpenSSL-patcher er ute – KRITISK feil nedgradert til HØY, men patch uansett!

Nå, den kritiske oppdateringen ... faktisk viste det seg at mens de undersøkte den første oppdateringen, fant de en andre relatert oppdatering, så det er faktisk to av dem ... de gjelder bare for OpenSSL 3.0, ikke for 1.1.1.

Så jeg sier ikke: "Ikke lapp hvis du har 1.1.1", men det er mindre presserende, kan du si.

Og det fineste er at CRITICAL-nivået, alt med store bokstaver, ble nedgradert til HØY alvorlighetsgrad, fordi det føles at feilene, som er relatert til TLS-sertifikatvalidering, nesten helt sikkert kan brukes til tjenestenekt, men er sannsynligvis kommer til å være veldig vanskelig å gjøre om til ekstern kodeutførelse.

Det er bufferoverløp, men de er på en måte begrenset.

Det er to feil... la meg bare gi tallene slik at du kan referere til dem.

Det er CVE 2022-3602, hvor du kan overskrive fire byte av stabelen: bare fire byte, en halv 64-biters adresse.

Selv om du kan skrive hva du vil, er mengden skade du kan gjøre sannsynligvis, men ikke nødvendigvis, begrenset til tjenestenekt.

Og den andre feilen heter CVE-2022-3786, og i den kan du gjøre så stor stackoverflyt som du vil, tilsynelatende [ler]... dette er ganske morsomt.

Men du kan bare skrive prikker, heksdesimal 0x2E i ASCII.

Så selv om du kan ødelegge stabelen fullstendig, er det en grense for hvor kreativ du kan være i enhver ekstern kodeutførelse du prøver å finne på.

Det andre er at, generelt sett... ikke i alle tilfeller, men i de fleste tilfeller, spesielt for ting som webservere, der folk kanskje bruker OpenSSL og de får panikk: "Hva om folk kan stjele hemmeligheter fra webserveren vår som de kunne i Heartbleed-dagene?»

De fleste webservere ber ikke klienter som kobler til, besøkende, om å gi et sertifikat for å validere seg selv.

De bryr seg ikke; alle er velkommen til å besøke.

Men serveren sender et sertifikat til klienten slik at klienten, hvis den ønsker det, kan bestemme, "Hei, jeg besøker virkelig Sophos", eller Microsoft, eller hvilken side jeg tror det er.

Så det ser ut som om den mest sannsynlige måten dette vil bli utnyttet på er at useriøse servere krasjer klienter, i stedet for omvendt.

Og jeg tror du vil være enig i at servere som krasjer klienter er dårlig, og du kan gjøre dårlige ting med det: for eksempel kan du blokkere noen fra å få oppdateringer, fordi det stadig mislykkes om og om igjen og igjen og igjen.

Men det ser ikke like sannsynlig ut at denne feilen kan utnyttes for enhver tilfeldig person på Internett bare for å begynne å skanne alle nettserverne dine og krasje dem etter eget ønske.

Jeg tror ikke det er sannsynlig.

---

DOUG.  Vi har en leserkommentar her: «Jeg aner ikke hva jeg skal oppdatere. Chrome firefox windows. Hjelp?"

Du vet aldri..., det er alle disse forskjellige smakene av SSL.

---

AND.  Den gode nyheten her er at selv om noen Microsoft-produkter bruker og inkluderer sin egen kopi av OpenSSL, er det min forståelse at verken Chrome, Firefox eller Edge bruker det.

Så jeg tror svaret på spørsmålet er at selv om du aldri vet, fra et rent Windows, Chrome, Firefox, Edge-perspektiv, tror jeg ikke du trenger å bekymre deg for denne.

Det er hvis du kjører servere, spesielt Linux-servere, der Linux-distroen din kommer med en eller begge versjoner av OpenSSL, eller hvis du har spesifikke Windows-produkter du har installert som tilfeldigvis kommer sammen med OpenSSL ... og produktet vil normalt fortelle deg hvis det gjør det.

Eller du kan lete etter libcrypto*.dll eller libssl*.dll.

Og et godt eksempel på det, Doug, er Nmap, det veldig kjente og veldig nyttige nettverksskanningsverktøyet som mange Red Teams bruker.

Det programmet kommer ikke bare med OpenSSL 1.1.1, pakket sammen med seg selv, men også med OpenSSL 3.0, så vidt jeg kan se.

Og begge for øyeblikket, i hvert fall når jeg så i går kveld, er utdaterte.

Jeg burde ikke si dette, men...

---

DOUG.  [INTERRPTS, LUNGHING] Hvis jeg er et Blue Team-medlem …

---

AND.  Nøyaktig! NØYAKTIG! [LETER]

Hvis du er en Blue Teamer som prøver å beskytte nettverket ditt og du tenker «Å, det røde teamet kommer til å skanne som gale, og de elsker Nmap-en deres», har du en kjempesjanse til å mothakke!

[HØYT LATTER]

---

DOUG.  OK, vi har noen andre oppdateringer å snakke om: Chrome, Apple og SHA-3-oppdateringer.

La oss starte med Chrome, som hastet null-dagers løsning, og de lappet det ganske raskt...

…men de var ikke veldig klare på hva som foregikk:

Chrome har utstedt en hasteløsning – oppdater nå!

---

AND.  Jeg vet ikke om tre advokater skrev disse ordene, som hver la til et ekstra nivå av indirekte, men du vet at Google har denne rare måten å snakke om null-dager på, akkurat som Apple, hvor de forteller den *bokstavelige* sannheten:

Google er klar over rapporter om at en utnyttelse av dette sikkerhetsproblemet, CVE-2022-3723, finnes i naturen.

Som er på en måte to nivåer av indirektion unna å si: "Det er en 0-dag, folkens!"

I stedet er det: "Noen skrev en rapport som sier at den eksisterer, og så fortalte de oss om rapporten."

Jeg tror vi alle kan være enige om at det må lappes, og Google må være enig, fordi...

…for å være rettferdig mot dem, løste de det nesten umiddelbart.

Ironisk nok gjorde de en stor sikkerhetsfiks samme dag som denne feilen ble rapportert, som jeg tror var 25. oktober 2022, og Google hadde fikset det innen hva, tre dager?

To dager, faktisk.

Og Microsoft har selv fulgt opp med en veldig klar rapport om Edge-utgivelsesnotatene deres: 31. oktober 2022 slipper de en oppdatering, og den sa eksplisitt at den fikser feilen rapportert av Google og Chromium-teamet.

---

DOUG.  Ok veldig bra.

Jeg er tilbakeholden med å ta dette opp, men er vi trygge på å snakke om Apple nå?

Har vi noe mer klarhet på denne Apple-nulldagen?

Oppdateringer til Apples null-dagers oppdateringshistorie – iPhone- og iPad-brukere leser dette!

---

AND.  Vel, den kritiske avtalen her er da vi skrev om oppdateringen som inkluderte iOS 16.1 og iPadOS 16, som faktisk viste seg å være iPadOS 16.1 tross alt...

… folk spør oss, forståelig nok, «Hva med iOS 15.7? Må jeg gå til iOS 16 hvis jeg kan? Eller kommer det en 15.7.1? Eller har de droppet støtten for iOS 15 helt, spillet er over?"

Og se og se, heldigvis (jeg tror det dagen etter at vi spilte inn forrige ukes podcast [LETER]), sendte de plutselig ut et varsel som sa: «Hei, iOS 15.7.1 er ute, og det fikser seg nøyaktig de samme hullene som iOS 16.1 og iPadOS 16/16.1 gjorde."

Så nå vet vi at hvis du bruker iOS eller iPadOS, *kan* du holde deg til versjon 15 hvis du vil, og det er en 15.7.1 du må skaffe deg.

Men hvis du har en eldre telefon som ikke støtter iOS 16, må du definitivt få 15.7.1 fordi det er den eneste måten å fikse nulldagen på.

Og vi ser også ut til å ha forsikret oss om at iOS og iPadOS nå begge har samme kode, med samme rettelser, og de er begge på 16.1, uansett hva sikkerhetsbulletinene måtte ha antydet.

---

DOUG.  Ok, flott jobb, alle sammen, vi klarte det.

Flott arbeid ... tok noen dager, men greit!

Og sist, men absolutt ikke minst i oppdateringshistoriene våre...

…det føles som om vi fortsetter å snakke om dette, og fortsetter å prøve å gjøre det rette med kryptografi, men innsatsen vår blir ikke alltid belønnet.

Så, for eksempel, dette nye SHA-3-feil?

SHA-3 kodeutførelsesfeil lappet i PHP – sjekk din versjon!

---

AND.  Ja, dette er litt forskjellig fra OpenSSL-feilene vi nettopp snakket om, fordi i dette tilfellet ligger problemet faktisk i selve SHA-3 kryptografiske algoritmen ... i en implementering kjent som XKCP, det er X-ray, Kilo, Charlie , pappa.

Og det er, hvis du vil, referanseimplementeringen til selve teamet som oppfant SHA-3, som opprinnelig ble kalt Keccak [uttales 'ketchak', som 'ketchup'].

Det ble godkjent for omtrent ti år siden, og de bestemte seg: "Vel, vi skal skrive en samling standardiserte algoritmer for alle kryptografiske ting vi gjør, inkludert SHA-3, som folk kan bruke hvis de vil."

Dessverre ser det ut som om programmeringen deres ikke var fullt så nøye og robust som den opprinnelige kryptografiske designen, fordi de laget samme type feil som Chester og jeg snakket om for noen måneder siden i et produkt som heter NetUSB:

Hjemmerutere med NetUSB-støtte kan ha kritiske kjernehull

Så i koden prøvde de å sjekke: "Ber du oss hash for mye data?"

Og den teoretiske grensen var 4GB minus en byte, bortsett fra at de glemte at det skal være 200 reservebyte på slutten.

Så de skulle sjekke om du prøvde å hash mer enn 4 GB minus én byte *minus 200 byte*.

Men det gjorde de ikke, og det forårsaket et heltallsoverløp, som kan forårsake bufferoverløp, som kan forårsake enten tjenestenekt.

Eller, i verste fall, en potensiell ekstern kjøring av kode.

Eller bare hashverdier beregnet feil, noe som alltid vil ende i tårer fordi du kan forestille deg at enten en god fil kan ende opp med å bli dømt som dårlig, eller en dårlig fil kan bli feilaktig gjenkjent som god.

---

DOUG.  Så hvis dette er en referanseimplementering, er dette noe å få panikk over på utbredt grunnlag, eller er det mer innesluttet?

---

AND.  Jeg tror det er mer innesluttet, fordi de fleste produktene, spesielt inkludert OpenSSL, heldigvis ikke bruker XKCP-implementeringen.

Men PHP *bruker* XKCP-koden, så du vil enten forsikre deg om at du har PHP 8.0.25 eller nyere, eller PHP 8.1.12 eller nyere.

Og den andre forvirrende er Python.

Nå har Python 3.11, som er den siste, gått over til en helt ny implementering av SHA-3, som ikke er denne, så det er ikke sårbart.

Python 3.9 og 3.10 ... noen bygg bruker OpenSSL, og noen bruker XKCP-implementeringen.

Og vi har litt kode i artikkelen vår, litt Python-kode, som du kan bruke for å finne ut hvilken versjon Python-implementeringen din bruker.

Det gjør en forskjell: man kan på en pålitelig måte få den til å krasje; den andre kan ikke.

Og Python 3.8 og tidligere har tilsynelatende denne XKCP-koden i seg.

Så du vil enten legge inn begrensninger i din egen kode for å gjøre bufferlengdekontrollen riktig selv, eller å bruke nødvendige oppdateringer når de kommer ut.

---

DOUG.  OK, veldig bra, vi skal holde øye med det.

Og nå skal vi runde av showet med to virkelig oppløftende historier, og starter med hva som skjer når det veldig private og veldig personlige innholdet i tusenvis av psykoterapiøkter blir lekket ut online...

Mistenkt for utpressing av psykoterapi: arrestordre utstedt

---

AND.  Bakgrunnen er det som nå er en beryktet, og faktisk konkurs, psykoterapiklinikk.

De hadde et datainnbrudd, tror jeg, i 2018, og enda et i 2019.

Og det viste seg at disse intime sesjonene som folk hadde hatt med sine psykoterapeuter, hvor de avslørte sine dypeste og antagelig noen ganger mørkeste hemmeligheter, og hva de tenkte om vennene sine og familien...

…alle disse tingene som er så personlige at du på en måte håper at de ikke blir spilt inn i det hele tatt, men bare blir lyttet til og det grunnleggende destillert.

Men tilsynelatende ville terapeutene skrive detaljerte notater, og deretter lagre dem til senere.

Vel, kanskje det er greit hvis de skal lagre dem riktig.

Men på et tidspunkt, antar jeg, hadde de "rushet til skyen".

Disse tingene ble tilgjengelige på Internett, og angivelig var det en slags ueberkonto der hvem som helst kunne få tilgang til alt hvis de visste passordet.

Og tilsynelatende var det en standard.

Å, kjære, hvordan kan folk fortsatt gjøre dette?

---

DOUG.  Uff!

---

AND.  Så hvem som helst kunne komme inn, og noen gjorde det.

Og selskapet så egentlig ikke ut til å gjøre mye med det, så vidt jeg kan fortelle, og det ble ikke avslørt eller rapportert ...

...fordi hvis de hadde handlet raskt, kunne kanskje politiet ha blitt involvert tidlig og avsluttet hele saken i tide.

Men det kom først ut i vask i oktober 2020, tilsynelatende, da spørsmålet om bruddet ikke lenger kunne avvises.

Fordi noen som hadde skaffet seg dataene, enten den opprinnelige inntrengeren eller noen som hadde kjøpt dem på nettet, kan du tenke deg, begynte å prøve å utpresse dem.

Og tilsynelatende prøvde de først å utpresse selskapet ved å si "Betal oss"... Jeg tror beløpet var et sted rundt en halv million euro.

"Betal oss dette engangsbeløpet i bitcoins, og vi får dataene til å forsvinne."

Men, hindret av selskapet, bestemte personen med dataene seg: "Jeg vet hva, jeg kommer til å utpresse hver person av titusenvis i databasen individuelt."

---

DOUG.  Å, gutt...

---

AND.  Så de begynte å sende e-poster som sa: "Hei, betal meg 200 euro selv, så skal jeg sørge for at dataene dine ikke blir eksponert."

Uansett, det ser ut til at dataene ikke ble frigitt ... og prøver å finne bunnlinjen i dette, Doug: [A] de finske myndighetene har nå utstedt en arrestordre, og [B] de kommer til å gå etter administrerende direktør for det tidligere selskapet (som jeg sa, det er nå konkurs), og sa at selv om selskapet var et offer for kriminalitet, var selskapet selv så langt under pari i hvordan det håndterte bruddet at det må møte en form for straff.

De rapporterte ikke bruddet når det kan ha gjort en stor forskjell, og de bare, gitt arten av dataene de vet at de har, gjorde de alt for dårlig.

Og dette er ikke bare, "Å, du kan få en regulatorisk bot."

Tilsynelatende kan han risikere opptil tolv måneders fengsel.

---

DOUG.  OK, det er noe!

Men for ikke å bli overgått, har vi en casestudie i cybersikkerhetsutuglighet og en virkelig, virkelig dårlig svar etter brudd med denne "Se billetter"-tingen:

Online-billettselskapet "See" har tjent i 2.5 år av angripere

---

AND.  Ja, dette er et veldig stort billettselskap ... Det er "Se", S-E-E, ikke "C" som i programmeringsspråket.

Dette virker også som en slik komedie av feil, Doug...

---

DOUG.  Det er virkelig fantastisk.

25. juni 2019 ... innen denne datoen tror vi at nettkriminelle hadde implantert skadelig programvare som stjeler data på betalingssidene som drives av selskapet.

Så dette er ikke det at folk blir phishet eller lurt, for når du gikk for å sjekke ut, kunne dataene dine ha blitt overført.

---

AND.  Så dette er "skadelig programvare på nettstedet"?

---

DOUG.  Ja.

---

AND.  Det er ganske nært knyttet til transaksjonen din, i sanntid!

---

DOUG.  De vanlige mistenkte, som navn, adresse, postnummer, men så kredittkortnummeret ditt...

...så du sier: "OK, du har nummeret mitt, men gjorde de også...?"

Og ja, de har utløpsdatoen din, og de har CVV-nummeret ditt, det lille tresifrede nummeret du skriver inn for å være sikker på at du er legitim med kredittkortet ditt.

---

AND.  Ja, fordi du ikke skal lagre det etter at du har fullført transaksjonen...

---

DOUG.  Nei herre!

---

AND.  …men du har den i minnet *mens du gjør transaksjonen*, av nødvendighet.

---

DOUG.  Og så nesten to år senere, i april 2021 (to år senere!), ble See Tickets varslet om aktivitet som indikerte potensiell uautorisert tilgang, [IRONIC], og de satte i gang.

---

AND.  Å, det er sånn SHEIN brudd vi snakket om for et par uker siden, ikke sant?

Motemerket SHEIN bøtelagt 1.9 millioner dollar for å ha løyet om datainnbrudd

De fant ut av noen andre ... kredittkortselskapet sa: "Vet du hva, det er en hel masse skumle transaksjoner som ser ut til å gå tilbake til deg."

---

DOUG.  De starter en etterforskning.

Men de stenger faktisk ikke alt som skjer før [DRAMATISK PAUSE] januar 2022!

---

AND.  Åtte og en halv måned senere, ikke sant?

---

DOUG.  Ja!

---

AND.  Så det var deres trusselrespons?

De hadde et tredjeparts etterforskningsteam, de hadde alle ekspertene i, og mer enn *åtte måneder* senere sa de: "Hei, gjett hva folkens, vi tror vi har kastet skurkene ut nå"?

---

DOUG.  Så fortsatte de med å si, i oktober 2022, at "Vi er ikke sikre på at informasjonen din ble påvirket", men de varslet til slutt kundene.

---

AND.  Så, i stedet for å si: "Kurkene hadde malware på serveren som hadde som mål å stjele alles data, og vi kan ikke si om de var vellykkede eller ikke", med andre ord, "Vi var så dårlige på dette at vi kan" ikke engang fortelle hvor flinke skurkene var"...

...de sa faktisk: "Å, ikke bekymre deg, ikke bekymre deg, vi klarte ikke å bevise at dataene dine ble stjålet, så kanskje det ikke var det"?

---

DOUG.  "Denne tingen som har pågått i to og et halvt år under nesen vår ... vi er bare ikke sikre."

OK, så e-posten som See Tickets sender ut til kundene sine inneholder noen råd, men det er faktisk ikke råd som gjelder denne spesielle situasjonen ... [HØRES BESEIRET] som var ironisk og forferdelig, men litt morsomt.

---

AND.  Ja.

Selv om jeg er enig i deres råd, og det er vel verdt å ta med i betraktningen, nemlig: sjekk alltid regnskapet regelmessig, og se opp for phishing-e-poster som prøver å lure deg til å utlevere dine personlige data...

…du tror de kan ha tatt med litt av en culpa der, og forklart hva *de* skulle gjøre i fremtiden for å forhindre det som *hendte*, som ingen av disse tingene kunne ha forhindret, fordi du sjekker utsagnene dine viser deg bare at du har blitt brutt etter at det har skjedd, og det var ingen phishing i dette tilfellet.

---

DOUG.  Så det reiser et godt spørsmål.

Den som en leser tar opp ... og vår kommentar her om denne lille kerfuffle er at Naked Security-leser Lawrence spør rettferdig: "Jeg trodde PCI-samsvar krevde sikkerhetstiltak på alle disse tingene. Ble de aldri revidert?»

---

AND.  Jeg vet ikke svaret på det spørsmålet...

Men selv om de var kompatible, og ble sjekket for samsvar, betyr ikke det at de ikke kunne ha fått en skadelig programvare-infeksjon dagen etter at samsvarskontrollen ble utført.

Samsvarskontrollen innebærer ikke en fullstendig revisjon av absolutt alt på nettverket.

Min analogi, som folk i Storbritannia vil være kjent med, er at hvis du har en bil i Storbritannia, må den ha en årlig sikkerhetssjekk.

Og det er veldig tydelig, når du består en test, at *dette er ikke et bevis på at bilen er trafikkdyktig*.

Den har bestått de lovpålagte testene, som tester de åpenbare tingene som hvis du ikke har gjort riktig, betyr at bilen din er *farlig* usikker og ikke bør være på veien, for eksempel "bremser fungerer ikke", "en frontlykt er ut», den slags.

Da PCI DSS først ble en ting, kritiserte mange mennesker det og sa: "Å mann, det er for lite, for sent."

Og svaret var: "Vel, du må begynne et sted."

Så det er fullt mulig at de hadde PCI DSS-merket for godkjenning, men de ble fortsatt brutt.

Og så la de bare ikke merke til... og så svarte de ikke veldig raskt... og så sendte de heller ikke en veldig meningsfull e-post til kundene sine.

Min personlige mening er at hvis jeg var en kunde hos dem, og jeg mottok en slik e-post, med tanke på hvor lang tid dette hadde utspilt seg, ville jeg vurdert det som nesten nonsjalans.

Og jeg tror ikke jeg ville vært best fornøyd!

---

DOUG.  Ok, og jeg er enig med deg.

Vi vil holde øye med det – etterforskningen pågår selvfølgelig fortsatt.

Og tusen takk, Lawrence, for at du sendte inn den kommentaren.

Hvis du har en interessant historie, kommentar eller spørsmål du vil sende inn, vil vi gjerne lese den på podcasten.

Du kan sende en e-post til tips@sophos.com, eller du kan kommentere en av artiklene våre, eller du kan kontakte oss på sosiale medier: @NakedSecurity.

Det er showet vårt for i dag; tusen takk for at du lyttet.

For Paul Ducklin, jeg er Doug Aamoth, og minner deg på neste gang...

---

BÅDE.  Hold deg trygg!

[MUSIKK MODEM]