S3 Ep105: WONTFIX! MS Office-krypteringsfilen som "ikke er en sikkerhetsfeil" [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.  Fantastiske brudd, dekrypterbar kryptering og mange patcher.

Alt det 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 i dag, sir?

---

AND.  Doug...jeg vet, fordi du fortalte meg på forhånd hva som kommer inn Denne uken i teknisk historie, og det er FLOTT!

---

DOUG.  OK!

Denne uken, den 18. oktober 1958, ble et oscilloskop og en datamaskin bygget for å simulere vindmotstand sammenkoblet med tilpassede aluminiumskontrollere, og spillet Tennis for to var født.

Tennis for Two ble vist frem på en tredagers utstilling på Brookhaven National Laboratory, og viste seg å være ekstremt populær, spesielt blant elever på videregående.

Hvis du hører på dette, må du gå til Wikipedia og slå opp "Tennis for to".

Det er en video der for noe som ble bygget i 1958 ...

…Jeg tror du vil være enig med meg, Paul, det var ganske utrolig.

---

AND.  Jeg vil *elske* å spille det i dag!

Og, som Asteroids og Battle Zone, og de spesielt huskede spillene fra 1980-tallet...

…fordi det er et oscilloskop: vektorgrafikk!

Ingen pikselering, ingen forskjeller avhengig av om en linje er på 90 grader, eller 30 grader eller 45 grader.

Og lydtilbakemeldingen fra reléene i kontrollerene ... det er flott!

Det er utrolig at dette var 1958.

Å gå tilbake til en tidligere Denne uken i teknisk historie, det var på slutten av transistorrevolusjonen.

Tilsynelatende var beregningshalvdelen en blanding av termioniske ventiler (vakuumrør) og releer.

Og skjermkretsene var alle transistorbaserte, Doug

Så det var rett ved blandingen av alle teknologier: releer, ventiler og transistorer, alt i ett banebrytende videospill.

---

DOUG.  Veldig kult.

Sjekk det ut på Wikipedia: Tennis for to.

La oss nå gå videre til vår første historie.

Paul, jeg vet at du er veldig flink til å skrive et flott dikt...

…Jeg har skrevet et veldig kort dikt for å introdusere denne første historien, hvis du vil unne meg.

---

AND.  Så det blir to linjer da, vil det? [LETER]

---

DOUG.  Det går litt sånn som dette.

Zoom for Mac/Ikke får kapret.

[VELDIG LANG STILLHET]

Slutt dikt.

---

AND.  Åh, beklager!

Jeg trodde det var tittelen, og at du skulle lage diktet nå.

---

DOUG.  Så, det er diktet.

---

AND.  OK.

[UTEN FØLELSER] Herlig, Doug.

---

DOUG.  [IRONISK] Takk.

---

AND.  Rimet var spektakulært!

Men ikke alle dikt må rime...

---

DOUG.  Det er sant.

---

AND.  Vi vil bare kalle det frie vers, skal vi?

---

DOUG.  OK, vær så snill.

---

AND.  Dessverre var dette en gratis bakdør til Zoom for Mac.

[FØLER SKYLDIGHET] Beklager, det var ikke en veldig god sak, Doug.

[LER] Du tråkker på andres gress, du kommer ofte til kort...

---

DOUG.  Nei, det er bra!

Jeg prøvde ut dikt denne uken; du prøver ut segues.

Vi må ut av komfortsonene våre innimellom.

---

AND.  Jeg antar at dette var kode som var ment å bli kompilert ut når den endelige byggingen var ferdig, men som ved et uhell ble liggende inne.

Den er bare for Zoom for Mac-versjonen, og den har blitt oppdatert, så sørg for at du er oppdatert.

I utgangspunktet, under noen omstendigheter, når en videostrøm ville starte eller kameraet ble aktivert av selve appen, ville det utilsiktet tro at du kanskje vil feilsøke programmet.

Fordi, hei, kanskje du var en utvikler! [LETER]

Det er ikke ment å skje i utgivelsesbygg, selvsagt.

Og det betydde at det var en TCP-feilsøkingsport åpen på det lokale nettverksgrensesnittet.

Det betydde at alle som kunne sende pakker til den porten, som antagelig kunne være en hvilken som helst annen lokalt tilkoblet bruker, så det ville ikke trenge å være en administrator eller til og med deg... selv en gjestebruker, det ville være nok.

Så en angriper som hadde en slags proxy-malware på datamaskinen din som kunne motta pakker utenfra og injisere dem i det lokale grensesnittet, kunne i utgangspunktet utstede kommandoer til programmets tarm.

Og de typiske tingene som feilsøkingsgrensesnitt tillater inkluderer: dump noe minne; trekke ut hemmeligheter; endre oppførselen til programmet; justere konfigurasjonsinnstillingene uten å gå gjennom det vanlige grensesnittet slik at brukeren ikke kan se det; ta opp all lyden uten å fortelle det til noen, uten å dukke opp opptaksadvarselen; alt sånt.

Den gode nyheten er at Zoom fant det av seg selv, og de lappet det ganske raskt.

Men det er en god påminnelse om at som vi sier så ofte, [ler] "Det er mange glipper "twixt koppen og leppen."

---

DOUG.  Greit, veldig bra.

La oss bli ombord på lapptoget og dra inn på neste stasjon.

Og denne historien... kanskje den mest interessante delen av denne historien om den siste Patch Tuesday var hva Microsoft *ikke* inkluderte?

---

AND.  Dessverre, patchene som alle sannsynligvis ventet – og vi spekulerte i en nylig podcast, «Vel, det ser ut som om Microsoft kommer til å få oss til å vente enda en uke til Patch Tuesday, og ikke gjøre en tidlig utgivelse utenfor bandet. ”  er de to Exchange-nulldagene med nylig minne.

Det som ble kjent som E00F, eller Bytt Dobbel Zero-day Flaw i min terminologi, eller ProxyNotShell som det kanskje er litt forvirrende kjent i Twittersphere.

Så det var den store historien i denne månedens Patch Tuesday: disse to feilene ble spektakulært ikke fikset.

Og så vi vet ikke når det kommer til å skje.

Du må forsikre deg om at du har brukt eventuelle begrensninger.

Som jeg tror vi har sagt før, fant Microsoft stadig ut at de tidligere begrensningene de foreslo … vel, kanskje de ikke var helt gode nok, og de fortsatte å endre melodien og tilpasse historien.

Så hvis du er i tvil, kan du gå tilbake til nakedsecurity.sophos.com, søke etter uttrykket ProxyNotShell (alt ett ord), og så gå og les opp hva vi har å si.

Og du kan også koble til den nyeste versjonen av Microsofts utbedring...

...fordi, av alle tingene i Patch Tuesday, var det det mest interessante, som du sier: fordi det ikke var der.

---

DOUG.  OK, la oss nå skifte gir til a veldig frustrerende historie.

Dette er et slag på hånden for et stort selskap hvis cybersikkerhet er så dårlig at de ikke en gang la merke til at de var blitt brutt!

---

AND.  Ja, dette er et merke som de fleste sannsynligvis vil kjenne som SHEIN («she-in»), skrevet som ett ord, alt med store bokstaver. (På tidspunktet for bruddet var selskapet kjent som Zoetop.)

Og de er det som kalles "fast fashion".

Du vet, de samler det høyt og selger det billig, og ikke uten kontroverser om hvor de får designene sine fra.

Og som nettforhandler ville du kanskje forvente at de hadde detaljene om nettsikkerhet på nett.

Men som du sier, det gjorde de ikke!

Og kontoret til statsadvokaten i staten New York i USA bestemte at det ikke var fornøyd med måten innbyggere i New York ble behandlet på som var blant ofrene for dette bruddet.

Så de tok rettslige skritt mot dette selskapet ... og det var en absolutt litani av tabber, feil og til slutt tildekning – med et ord, Douglas, uærlighet.

De hadde dette bruddet som de ikke la merke til.

Dette, i det minste tidligere, pleide å være skuffende vanlig: selskaper ville ikke innse at de hadde blitt misligholdt før en kredittkortbehandler eller en bank ville kontakte dem og si: «Vet du hva, vi har hatt utrolig mye av klager om svindel fra kunder denne måneden.»

"Og når vi så tilbake på det de kaller CPP, den felles kjøpssted, den eneste kjøpmannen som hvert enkelt offer ser ut til å ha kjøpt noe fra er deg. Vi regner med at lekkasjen kom fra deg.»

Og i dette tilfellet var det enda verre.

Tilsynelatende kom en annen betalingsbehandler og sa: "Å, forresten, vi fant en hel transje av kredittkortnumre for salg, tilbudt som stjålet fra dere."

Så de hadde klare bevis på at det enten hadde vært et brudd i bulk, eller et brudd bit for bit.

---

DOUG.  Så da dette selskapet ble gjort oppmerksom på dette, gikk de raskt for å rette opp situasjonen, ikke sant?

---

AND.  Vel, det kommer an på hvordan du … [LETER] Jeg burde ikke le, Doug, som alltid.

Det kommer an på hva du mener med "rett opp".

---

DOUG.  [LETER] Å, gud!

---

AND.  Så det ser ut til at de *taklet* problemet ... det var faktisk deler av det som de dekket opp veldig bra.

Tilsynelatende.

Det ser ut til at de plutselig bestemte seg: "Oi, vi bør bli PCI DSS-kompatible".

Det var de tydeligvis ikke, fordi de tilsynelatende hadde ført feilsøkingslogger som hadde kredittkortopplysninger om mislykkede transaksjoner ... alt du ikke skal skrive til disken, skrev de.

Og så skjønte de at det hadde skjedd, men de kunne ikke finne hvor de la disse dataene i sitt eget nettverk!

Så tydeligvis visste de at de ikke var PCI DSS-kompatible.

De begynte å gjøre seg selv PCI DSS-kompatibel, tilsynelatende, noe de oppnådde innen 2019. (Bruket skjedde i 2018.)

Men da de ble fortalt at de måtte underkaste seg en revisjon, en rettsmedisinsk etterforskning ...

…ifølge New York Attorney General, kom de ganske bevisst i veien for etterforskeren.

De tillot i utgangspunktet etterforskerne å se systemet slik det var *etter* at de fikset det, og sveiset det og polerte det, og de sa: "Å nei, du kan ikke se sikkerhetskopiene," noe som høres ganske slemt ut for meg .

---

DOUG.  Uh-he.

---

AND.  Og måten de avslørte bruddet til kundene sine, vakte betydelig iver fra staten New York.

Spesielt ser det ut til at det var ganske åpenbart at 39,000,000 5 XNUMX brukeres detaljer på en eller annen måte hadde blitt gjort bort med, inkludert svært svakt hash-krypte passord: et tosifret salt og en runde med MDXNUMX.

Ikke bra nok i 1998, enn si 2018!

Så de visste at det var et problem for dette store antallet brukere, men tilsynelatende begynte de bare å kontakte de 6,000,000 av de brukerne som faktisk hadde brukt kontoene deres og lagt inn bestillinger.

Og så sa de: "Vel, vi har i det minste kontaktet alle disse menneskene."

Og *så* viste det seg at de egentlig ikke hadde kontaktet alle 6,000,000 XNUMX XNUMX millioner brukere!

De hadde nettopp kontaktet de av de seks millionene som tilfeldigvis bodde i Canada, USA eller Europa.

Så hvis du kommer fra noe annet sted i verden, uflaks!

Som du kan forestille deg, falt det ikke i god jord hos myndighetene, hos regulatoren.

Og jeg må innrømme... til min overraskelse, Doug, ble de bøtelagt 1.9 millioner dollar.

Som for et så stort selskap...

---

DOUG.  Ja!

---

AND.  …og gjøre så grove feil, og så ikke være helt anstendig og ærlig om hva som hadde skjedd, og bli bebreidet for å lyve om bruddet, med disse ordene, av statsadvokaten i New York?

Jeg så for meg at de kunne ha lidd en mer alvorlig skjebne.

Kanskje til og med inkludere noe som ikke bare kunne betales ned ved å komme opp med noen penger.

Å, og den andre tingen de gjorde er at når det var åpenbart at det var brukere hvis passord var i fare... fordi de var dypt knekkelige på grunn av det faktum at det var et tosifret salt, noe som betyr at du kan bygge 100 forhåndsberegnet ordbøker …

---

DOUG.  Er det vanlig?

Bare et tosifret salt virker veldig lavt!

---

AND.  Nei, du vil vanligvis ha 128 bits (16 byte), eller til og med 32 byte.

Løst sett gjør det ikke en vesentlig forskjell for cracking-hastigheten uansett, fordi (avhengig av blokkstørrelsen på hashen) legger du bare til to ekstra sifre i blandingen.

Så det er ikke engang som om selve beregningen av hashen tar lenger tid.

Så langt tilbake som i 2016 kunne folk som bruker datamaskiner med åtte GPUer som kjører "hashcat"-programmet, gjøre 200 milliarder MD5-er i sekundet.

Den gang! (Det beløpet er omtrent fem eller ti ganger høyere nå.)

Så veldig, veldig eminent knekkelig.

Men i stedet for å faktisk kontakte folk og si: "Passordet ditt er i fare fordi vi lekket hashen, og det var ikke veldig bra, bør du endre det", [LATER] sa de bare...

…det var veldig tøffe ord, ikke sant?

---

DOUG.  «Passordet ditt har et lavt sikkerhetsnivå og kan være i fare. Vennligst endre påloggingspassordet ditt."

Og så endret de det til "Passordet ditt har ikke blitt oppdatert på mer enn 365 dager. For din beskyttelse, vennligst oppdater den nå."

---

AND.  Ja, "Passordet ditt har et lavt sikkerhetsnivå ..."

---

DOUG.  "PÅ GRUNN AV OSS!"

---

AND.  Det er ikke bare nedlatende, er det?

Det er ved eller over grensen til offerskyldning, i mine øyne.

Uansett, dette virket ikke for meg å være et veldig sterkt insentiv for selskaper som ikke ønsker å gjøre det rette.

---

DOUG.  Greit, hør av i kommentarfeltet, vi vil gjerne høre hva du synes!

Den artikkelen heter: Motemerket SHEIN bøtelagt 1.9 millioner dollar for å ha løyet om datainnbrudd.

Og over til en annen frustrerende historie...

.., en annen dag, en annen advarende historie om å behandle upålitelige innspill!

---

AND.  Aaargh, jeg vet hva det kommer til å bli, Doug.

Det er Apache Commons -tekst feil, ikke sant?

---

DOUG.  Det er!

---

AND.  Bare for å være klar, det er ikke Apache Web Server.

Apache er en programvarestiftelse som har en hel rekke produkter og gratisverktøy ... og de er veldig nyttige, og de er åpen kildekode, og de er flotte.

Men vi har hatt, i Java-delen av deres økosystem (Apache Web Server httpd er ikke skrevet i Java, så la oss se bort fra det foreløpig – ikke bland Apache med Apache Web Server)...

…det siste året har vi hatt tre lignende problemer i Apaches Java-biblioteker.

Vi hadde beryktet Log4Shell bug i det såkalte Log4J-biblioteket (Logging for Java).

Så hadde vi en lignende feil, hva var det?... Apache Commons-konfigurasjon, som er et verktøysett for å administrere alle slags konfigurasjonsfiler, for eksempel INI-filer og XML-filer, alt på en standardisert måte.

Og nå i et enda lavere nivå bibliotek kalt Apache Commons -tekst.

Feilen i tingen som i Java er generelt kjent som "strenginterpolering".

Programmerere på andre språk ... hvis du bruker ting som PowerShell eller Bash, vil du kjenne det som "strengerstatning".

Det er der du på magisk vis kan få en setning full av karakterer til å bli til et slags miniprogram.

Hvis du noen gang har brukt Bash-skallet, vil du vite det hvis du skriver kommandoen echo USER, vil den ekko, eller skrive ut, strengen USER og du vil se, på skjermen U-S-E-R.

Men hvis du kjører kommandoen echo $USER, så betyr det ikke å gjenta et dollartegn etterfulgt av U-S-E-R.

Hva det betyr er: "Erstatt den magiske strengen med navnet på den påloggede brukeren, og skriv den ut i stedet."

Så på min datamaskin, hvis du echo USER, du får USER, men hvis du echo $USER, du får ordet duck i stedet.

Og noen av Java-strengerstatningene går mye, mye, mye lenger enn det … som alle som led gleden av fikser Log4Shell over julen 2021 vil huske!

Det finnes alle slags smarte små miniprogrammer som du kan legge inn i strenger som du deretter behandler med dette strengbehandlingsbiblioteket.

Så det er det åpenbare: å lese brukernavnet, setter du ${env: (for "les miljøet") user}… du bruker snirklete parenteser.

Det er dollartegn; snirklete brakett; en magisk kommando; squiggly brakett som er den magiske delen.

Og dessverre, i dette biblioteket, var det ukontrollert standardtilgjengelighet av magiske kommandoer som: ${url:...}, som lar deg lure strengbehandlingsbiblioteket til å nå ut på internett, laste ned noe og skrive ut det det får tilbake fra den nettserveren i stedet for strengen ${url:...}.

Så selv om det ikke er helt kodeinjeksjon, fordi det bare er rå HTML, betyr det fortsatt at du kan legge alle slags søppel og rare og fantastiske upålitelige ting i folks loggfiler eller nettsider.

Det er ${dns:...}, som betyr at du kan lure noens server, som kan være en forretningslogikkserver inne i nettverket...

…du kan lure den til å gjøre et DNS-oppslag for en navngitt server.

Og hvis du eier det domenet, som en kjeltring, så eier og driver du også DNS-serveren som er relatert til det domenet.

Så når DNS-oppslag skjer, gjett hva?

Det oppslaget avsluttes *på serveren din*, og kan hjelpe deg med å kartlegge innsiden av noens forretningsnettverk ... ikke bare deres webserver, men ting dypere i nettverket.

Og til slutt, og mest bekymringsverdig, i det minste med eldre versjoner av Java, var det … [LAGER] du vet hva som kommer her, Doug!

Kommandoen ${script:...}.

"Hei, la meg gi deg litt JavaScript og vær så snill å kjøre det for meg."

Og du tenker sannsynligvis: "Hva?! Vent, dette er en feil i Java. Hva har JavaScript med det å gjøre?"

Vel, inntil relativt nylig ... og husk, mange bedrifter bruker fortsatt eldre versjoner av Java Development Kit som fortsatt støttes.

Inntil nylig inneholdt Java ... [LETER] (igjen, jeg burde ikke le) ... Java Development Kit inneholdt, inne i seg selv, en full, fungerende JavaScript-motor, skrevet i Java.

Nå er det ikke noe forhold mellom Java og JavaScript bortsett fra de fire bokstavene "Java", men du kan sette ${script:javascript:...}og kjør kode etter eget valg.

Og, irriterende nok, er en av tingene du kan gjøre i JavaScript-motoren i Java-runtime fortelle JavaScript-motoren, "Hei, jeg vil kjøre denne tingen via Java."

Så du kan få Java til å kalle *inn i* JavaScript, og JavaScript egentlig til å kalle *ut* til Java.

Og så, fra Java, kan du gå, "Hei, kjør denne systemkommandoen."

Og hvis du går til Naked Security-artikkelen, vil du se at jeg bruker en mistenkt kommando for å [HOSTE UNSKYLDIGT] ta en calc, Doug!

En HP RPN-kalkulator, selvfølgelig, fordi det er jeg som lager kalkulatoren...

---

DOUG.  Det må det være, ja!

---

AND.  …denne er en HP-10.

Så selv om risikoen ikke er som flott som Log4Shell, du kan egentlig ikke utelukke det hvis du bruker dette biblioteket.

Vi har noen instruksjoner i Naked Security-artikkelen om hvordan du finner ut om du har Commons Text-biblioteket ... og du kan ha det, som mange mennesker gjorde med Log4J, uten å være klar over det, fordi det kan ha kommet sammen med en app.

Og vi har også noen eksempelkode der som du kan bruke til å teste om eventuelle avbøtende tiltak du har satt i verk har fungert.

---

DOUG.  Greit, gå over til Naked Security.

Den artikkelen heter: Farlig hull i Apache Commons-tekst – som Log4Shell på nytt.

Og vi avslutter med et spørsmål: "Hva skjer når krypterte meldinger bare er kryptert?"

---

AND.  Ah, du sikter til det som, antar jeg, var en offisiell feilrapport innlevert av cybersikkerhetsforskere ved det finske selskapet WithSecure nylig ...

…om den innebygde krypteringen som tilbys i Microsoft Office, eller mer presist, en funksjon kalt Office 365 Message Encryption eller OME.

Det er ganske praktisk å ha en liten funksjon som den innebygd i appen.

---

DOUG.  Ja, det høres enkelt og praktisk ut!

---

AND.  Ja, bortsett fra... å, kjære!

Det ser ut til at årsaken til dette er bakoverkompatibilitet, Doug ...

...at Microsoft ønsker at denne funksjonen skal fungere helt tilbake til folk som fortsatt bruker Office 2010, som har ganske gamle dekrypteringsevner innebygd.

I utgangspunktet ser det ut til at denne OME-prosessen med å kryptere filen bruker AES, som er den nyeste og beste NIST-standardiserte krypteringsalgoritmen.

Men den bruker AES i feil såkalt krypteringsmodus.

Den bruker det som er kjent som ECB, eller elektronisk kodebok modus.

Og det er rett og slett måten du refererer til rå AES.

AES krypterer 16 byte om gangen... forresten, den krypterer 16 byte enten du bruker AES-128, AES-192 eller AES-256.

Ikke bland sammen blokkstørrelsen og nøkkelstørrelsen – blokkstørrelsen, antallet byte som blir churnet opp og kryptert hver gang du dreier sveiven på den kryptografiske motoren, er alltid 128 bis eller 16 byte.

Uansett, i elektronisk kodebok-modus tar du ganske enkelt 16 byte med input, snur sveiven én gang under en gitt krypteringsnøkkel, og tar utdataene, rå og ubearbeidet.

Og problemet med det er at hver gang du får den samme inngangen i et dokument justert på den samme 16-byte-grensen...

…du får nøyaktig de samme dataene i utdataene.

Så mønstre i inngangen avsløres i utgangen, akkurat som de er i en Caesar chiffer eller en Vigenère chiffer:

Nå betyr det ikke at du kan knekke chifferen, for du har fortsatt å gjøre med biter som er 128 bits brede om gangen.

Problemet med elektronisk kodebokmodus oppstår nettopp fordi det lekker mønstre fra klarteksten inn i chifferteksten.

Kjente rentekstangrep er mulig når du vet at en bestemt inndatastreng krypterer på en bestemt måte, og for gjentatt tekst i et dokument (som en overskrift eller et firmanavn), reflekteres disse mønstrene.

Og selv om dette ble rapportert som en feil til Microsoft, har tilsynelatende selskapet bestemt seg for at det ikke kommer til å fikse det fordi det "ikke oppfyller baren" for en sikkerhetsfiks.

Og det ser ut til at grunnen er: "Vel, vi ville gjøre en bjørnetjeneste for folk som fortsatt bruker Office 2010."

---

DOUG.  Uff!

---

AND.  Ja!

---

DOUG.  Og på det notatet har vi en leserkommentar for denne uken på denne historien.

Naken Security Reader Bill kommenterer, delvis:

Dette minner meg om "krybbene" som bletchley Park-kodebryterne brukte under andre verdenskrig. Nazistene avsluttet ofte meldinger med den samme avslutningsfrasen, og dermed kunne kodebryterne jobbe tilbake fra dette avsluttende settet med krypterte tegn, vel vitende om hva de sannsynligvis representerte. Det er skuffende at vi 80 år senere ser ut til å gjenta de samme feilene.

---

AND.  80 år!

Ja, det er virkelig skuffende.

Min forståelse er at andre krybber som allierte kodeknekkere kunne bruke, spesielt for nazi-kryptere tekster, også handlet om *begynnelsen* av dokumentet.

Jeg tror dette var en ting for tyske værmeldinger ... det var et religiøst format som de fulgte for å sikre at de ga værmeldingene nøyaktig.

Og værmeldinger, som du kan forestille deg, under en krig som involverer luftbombing om natten, var virkelig viktige ting!

Det ser ut til at de fulgte et veldig, veldig strengt mønster som av og til kunne brukes som det du kan kalle en liten kryptografisk "løsner", eller en kile du kunne bruke til å bryte inn i utgangspunktet.

Og det, som Bill påpeker... det er nettopp derfor AES, eller et hvilket som helst chiffer, i elektronisk kodebokmodus ikke er tilfredsstillende for å kryptere hele dokumenter!

---

DOUG.  Greit, takk for at du sendte det inn, Bill.

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, 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å til neste gang om å...

---

BÅDE.  Hold deg trygg!