S3 Ep105: WONTFIX! MS Office cryptofail, der "ikke er en sikkerhedsfejl" [Lyd + Tekst]

Klik og træk på lydbølgerne nedenfor for at springe til ethvert punkt. Du kan også lytte direkte på Soundcloud.

DOUG.  Betagende brud, dekrypterbar kryptering og patches i massevis.

Alt det mere på Naked Security-podcasten.

[MUSIK 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 ved det, for du fortalte mig på forhånd, hvad der kommer ind Denne uge i teknisk historie, og det er FANTASTISK!

---

DOUG.  OK!

I denne uge, den 18. oktober 1958, blev et oscilloskop og en computer bygget til at simulere vindmodstand parret med tilpassede aluminiumscontrollere, og spillet Tennis til to blev født.

Tennis for to, der blev vist frem på en tre-dages udstilling på Brookhaven National Laboratory, viste sig at være ekstremt populær, især blandt gymnasieelever.

Hvis du lytter til dette, skal du gå til Wikipedia og slå "Tennis for to" op.

Der er en video der til noget, der blev bygget i 1958...

…Jeg tror, ​​du vil være enig med mig, Paul, det var ret utroligt.

---

AND.  Jeg ville *elske* at spille det i dag!

Og ligesom Asteroids og Battle Zone og de særligt huskede spil fra 1980'erne...

…fordi det er et oscilloskop: vektorgrafik!

Ingen pixelering, ingen forskelle afhængigt af, om en linje er på 90 grader, 30 grader eller 45 grader.

Og lydfeedbacken fra relæerne i controllerne... den er fantastisk!

Det er utroligt, at det var 1958.

Går tilbage til en tidligere Denne uge i teknisk historie, det var på spidsen af ​​transistorrevolutionen.

Tilsyneladende var den beregningsmæssige halvdel en blanding af termionventiler (vakuumrør) og relæer.

Og skærmkredsløbet var alle transistor-baserede, Doug

Så det var lige ved blandingen af ​​alle teknologier: relæer, ventiler og transistorer, alt sammen i ét banebrydende videospil.

---

DOUG.  Meget cool.

Tjek det ud på Wikipedia: Tennis til to.

Lad os nu gå videre til vores første historie.

Paul, jeg ved, at du er meget dygtig til at skrive et godt digt...

…Jeg har skrevet et meget kort digt for at introducere denne første historie, hvis du vil forkæle mig.

---

AND.  Så det bliver to linjer, vil det? [griner]

---

DOUG.  Det går lidt sådan her.

Zoom til Mac/Får ikke kapret.

[MEGET LANG stilhed]

Slut digt.

---

AND.  Åh, undskyld!

Jeg troede, det var titlen, og at du nu skulle lave digtet.

---

DOUG.  Så det er digtet.

---

AND.  OK.

[UDDEN FØLELSER] Dejligt, Doug.

---

DOUG.  [IRONISK] Tak.

---

AND.  Rimet var spektakulært!

Men ikke alle digte skal rime...

---

DOUG.  Det er rigtigt.

---

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

---

DOUG.  Okay, tak.

---

AND.  Desværre var dette en gratis bagdør til Zoom til Mac.

Undskyld, det var ikke en særlig god sag, Doug.

[griner] Du træder på en andens græstæppe, du kommer ofte til kort...

---

DOUG.  Nej, det er godt!

Jeg prøvede digte i denne uge; du prøver segues.

Vi er nødt til at komme ud af vores komfortzoner en gang imellem.

---

AND.  Jeg antager, at dette var kode, der var beregnet til at blive kompileret, da den endelige build var færdig, men ved et uheld blev efterladt.

Det er kun til Zoom til Mac-versionen, og det er blevet lappet, så sørg for, at du er opdateret.

Dybest set, under nogle omstændigheder, når en videostream ville starte, eller kameraet blev aktiveret af selve appen, ville det uforvarende tro, at du måske vil fejlsøge programmet.

Fordi, hey, måske var du en udvikler! [griner]

Det er åbenbart ikke meningen at det skal ske i release builds.

Og det betød, at der var en TCP-debugging-port åben på den lokale netværksgrænseflade.

Det betød, at enhver, der kunne sende pakker ind i den port, hvilket formentlig kunne være enhver anden lokalt forbundet bruger, så det behøvede ikke at være en administrator eller endda dig... selv en gæstebruger, det ville være nok.

Så en angriber, der havde en eller anden form for proxy-malware på din computer, der kunne modtage pakker udefra og injicere dem i den lokale grænseflade, kunne grundlæggende udsende kommandoer til programmets indvolde.

Og de typiske ting, som fejlfindingsgrænseflader tillader inkluderer: dump noget hukommelse; udtrække hemmeligheder; ændre programmets adfærd; juster konfigurationsindstillinger uden at gå gennem den sædvanlige grænseflade, så brugeren ikke kan se den; optag al lyden uden at fortælle det til nogen, uden at dukke op advarslen om optagelse; alle den slags ting.

Den gode nyhed er, at Zoom fandt det af sig selv, og de fiksede det ret hurtigt.

Men det er en stor påmindelse om, at som vi siger så ofte, [GRNER] "Der er mange en smutvej 'twixt koppen og læben."

---

DOUG.  Okay, meget godt.

Lad os blive ombord på patch-toget og køre ind på næste station.

Og denne historie... måske den mest interessante del af denne historie om den seneste Patch Tuesday var hvad Microsoft *ikke* inkluderede?

---

AND.  Desværre, de patches, som alle sandsynligvis havde forventet - og vi spekulerede i en nylig podcast, "Nå, det ser ud til, at Microsoft vil få os til at vente endnu en uge til Patch Tuesday og ikke lave en tidlig udgivelse uden for bandet ” er de to Exchange nul-dage med nyere hukommelse.

Hvad der blev kendt som E00F, eller Byt dobbelt nul-dag fejl i min terminologi, eller ProxyNotShell som det måske er lidt forvirrende kendt i Twittersfæren.

Så det var den store historie i denne måneds Patch Tuesday: disse to fejl blev spektakulært ikke rettet.

Og så ved vi ikke, hvornår det kommer til at ske.

Du skal sikre dig, at du har anvendt eventuelle begrænsninger.

Som jeg tror, ​​vi har sagt før, blev Microsoft ved med at finde ud af, at de tidligere begrænsninger, de foreslog… ja, måske var de ikke helt gode nok, og de blev ved med at ændre deres melodi og tilpasse historien.

Så hvis du er i tvivl, kan du gå tilbage til nakedsecurity.sophos.com, søge efter sætningen ProxyNotShell (alt ét ord), og så gå og læs op på, hvad vi har at sige.

Og du kan også linke til den seneste version af Microsofts afhjælpning...

…fordi, af alle tingene i Patch Tuesday, var det det mest interessante, som du siger: fordi det ikke var der.

---

DOUG.  OK, lad os nu skifte gear til a meget frustrerende historie.

Dette er et slag på hånden for en stor virksomhed, hvis cybersikkerhed er så dårlig, at de ikke engang bemærkede, at de var blevet brudt!

---

AND.  Ja, dette er et mærke, som de fleste nok vil kende som SHEIN ("she-in"), skrevet som ét ord, alt med store bogstaver. (På tidspunktet for bruddet var virksomheden kendt som Zoetop.)

Og de er det, der kaldes "fast fashion".

Du ved, de stabler det højt og sælger det billigt, og ikke uden kontroverser om, hvor de får deres design fra.

Og som en online-forhandler ville du måske forvente, at de havde cybersikkerhedsdetaljerne på nettet nede.

Men som du siger, det gjorde de ikke!

Og kontoret for statsadvokaten i staten New York i USA besluttede, at det ikke var tilfreds med den måde, New York-beboere var blevet behandlet på, som var blandt ofrene for dette brud.

Så de tog retslige skridt mod dette firma ... og det var en absolut litani af bommert, fejltagelser og i sidste ende tilsløringer - kort sagt Douglas, uærlighed.

De havde dette brud, som de ikke lagde mærke til.

Dette, i det mindste tidligere, plejede at være skuffende almindeligt: ​​virksomheder ville ikke indse, at de var blevet misligholdt, før en kreditkortbehandler eller en bank ville kontakte dem og sige: "Ved du hvad, vi har haft en frygtelig masse af klager over svindel fra kunder i denne måned."

"Og da vi så tilbage på det, de kalder CPP, den fælles indkøbssted, den eneste købmand, som hvert enkelt offer ser ud til at have købt noget af, er dig. Vi regner med, at lækagen kom fra dig."

Og i dette tilfælde var det endnu værre.

Tilsyneladende kom en anden betalingsbehandler og sagde: "Åh, forresten, vi fandt en hel tranche af kreditkortnumre til salg, tilbudt som stjålet fra jer."

Så de havde klare beviser for, at der enten havde været et brud i bulk eller et brud bit-for-bit.

---

DOUG.  Så da dette firma blev gjort opmærksom på dette, bevægede de sig hurtigt for at rette op på situationen, ikke?

---

AND.  Nå, det afhænger af, hvordan du... [GRNER] Jeg burde ikke grine, Doug, som altid.

Det afhænger af, hvad du mener med "rette".

---

DOUG.  Åh, gud!

---

AND.  Så det ser ud til, at de *har* håndteret problemet... ja, der var dele af det, som de dækkede rigtig godt over.

Tilsyneladende.

Det ser ud til, at de pludselig besluttede, "Ups, vi må hellere blive PCI DSS-kompatible".

Det var de tydeligvis ikke, fordi de tilsyneladende havde ført fejlretningslogfiler, der havde kreditkortoplysninger om mislykkede transaktioner... alt, hvad du ikke skulle skrive til disken, skrev de.

Og så indså de, at det var sket, men de kunne ikke finde, hvor de efterlod de data i deres eget netværk!

Så de vidste åbenbart, at de ikke var PCI DSS-kompatible.

De gik i gang med at gøre sig selv PCI DSS-kompatibel, tilsyneladende, noget som de opnåede i 2019. (Brykket skete i 2018.)

Men da de fik at vide, at de skulle underkaste sig en revision, en retsmedicinsk undersøgelse...

…ifølge New York Attorney General kom de helt bevidst i vejen for efterforskeren.

De tillod dybest set efterforskerne at se systemet, som det var *efter* de fik repareret det, og svejset det og poleret det, og de sagde: "Åh nej, du kan ikke se sikkerhedskopierne," hvilket lyder ret frækt for mig .

---

DOUG.  Uh huh.

---

AND.  Og også den måde, de afslørede bruddet på til deres kunder, vakte betydelig vrede fra staten New York.

Især ser det ud til, at det var ret indlysende, at 39,000,000 brugeres detaljer på en eller anden måde var blevet gjort af med, inklusive meget svagt hash-kodede kodeord: et tocifret salt og en omgang MD5.

Ikke godt nok i 1998, endsige 2018!

Så de vidste, at der var et problem for dette store antal brugere, men tilsyneladende gik de kun i gang med at kontakte de 6,000,000 af de brugere, som faktisk havde brugt deres konti og afgivet ordrer.

Og så sagde de: "Nå, vi har i det mindste kontaktet alle de mennesker."

Og *så* viste det sig, at de faktisk ikke rigtig havde kontaktet alle 6,000,000 millioner brugere!

De havde netop kontaktet dem af de seks millioner, der tilfældigvis boede i Canada, USA eller Europa.

Så hvis du kommer fra et andet sted i verden, uheld!

Som du kan forestille dig, faldt det ikke i god jord hos myndighederne, hos regulatoren.

Og jeg må indrømme... til min overraskelse, Doug, fik de en bøde på 1.9 millioner dollars.

Hvilket for et så stort firma...

---

DOUG.  Ja!

---

AND.  …og begå så voldsomme fejl og så ikke være helt anstændig og ærlig omkring, hvad der var sket, og blive bebrejdet for at lyve om bruddet, med disse ord, af justitsministeren i New York?

Jeg forestillede mig lidt, at de måske havde lidt en mere alvorlig skæbne.

Måske endda inkludere noget, der ikke bare kunne betales ved at komme med nogle penge.

Åh, og den anden ting, de gjorde, er, at da det var tydeligt, at der var brugere, hvis adgangskoder var i fare... fordi de var dybt knækkelige på grund af det faktum, at det var et tocifret salt, hvilket betyder, at du kunne bygge 100 forudberegnet ordbøger …

---

DOUG.  Er det almindeligt?

Bare et tocifret salt virker virkelig lavt!

---

AND.  Nej, du vil typisk have 128 bits (16 bytes) eller endda 32 bytes.

Løst sagt gør det alligevel ikke en væsentlig forskel for krakningshastigheden, fordi (afhængigt af blokstørrelsen på hashen) tilføjer du kun to ekstra cifre i blandingen.

Så det er ikke engang, som om selve beregningen af ​​hasherne tager længere tid.

Så langt tilbage som i 2016, tror jeg, at folk, der bruger computere med otte GPU'er, der kører "hashcat"-programmet, kunne lave 200 milliarder MD5'er i sekundet.

Dengang! (Det beløb er noget i retning af fem eller ti gange højere nu.)

Så meget, meget eminent knækkelig.

Men i stedet for rent faktisk at kontakte folk og sige: "Din adgangskode er i fare, fordi vi lækkede hashen, og den var ikke særlig god, så burde du ændre den", [LATER] sagde de bare...

… det var meget tøse ord, var de ikke?

---

DOUG.  "Din adgangskode har et lavt sikkerhedsniveau og er måske i fare. Venligst skift dit login-adgangskode."

Og så ændrede de det til, "Din adgangskode er ikke blevet opdateret i mere end 365 dage. For din beskyttelse skal du opdatere det nu."

---

AND.  Ja, "Din adgangskode har et lavt sikkerhedsniveau..."

---

DOUG.  "På grund af os!"

---

AND.  Det er ikke bare nedladende, vel?

Det er ved eller over grænsen til offerbebrejdelse, i mine øjne.

I hvert fald forekom det mig ikke at være et særligt stærkt incitament til virksomheder, der ikke ønsker at gøre det rigtige.

---

DOUG.  Okay, lyd af i kommentarerne, vi vil gerne høre, hvad du synes!

Den artikel hedder: Modemærket SHEIN idømte en bøde på 1.9 millioner dollars for at lyve om databrud.

Og videre til en anden frustrerende historie...

.., en anden dag, endnu en advarselshistorie om behandling af upålidelige input!

---

AND.  Aaargh, jeg ved hvad det bliver, Doug.

Det er den Apache Commons-tekst fejl, er det ikke?

---

DOUG.  Det er!

---

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

Apache er et softwarefundament, der har en hel række af produkter og gratis værktøjer... og de er virkelig meget nyttige, og de er open source, og de er fantastiske.

Men vi har haft, i Java-delen af ​​deres økosystem (Apache Web Server httpd er ikke skrevet i Java, så lad os ignorere det for nu – bland ikke Apache med Apache Web Server)...

…i det sidste år har vi haft tre lignende problemer i Apaches Java-biblioteker.

Vi havde den berygtede Log4Shell bug i det såkaldte Log4J (Logging for Java) bibliotek.

Så havde vi en lignende fejl i, hvad var det?... Apache Commons-konfiguration, som er et værktøjssæt til at administrere alle mulige konfigurationsfiler, f.eks. INI-filer og XML-filer, alt sammen på en standardiseret måde.

Og nu i et bibliotek på endnu lavere niveau kaldet Apache Commons-tekst.

Fejlen i den ting, der i Java generelt er kendt som "strenginterpolation".

Programmører på andre sprog ... hvis du bruger ting som PowerShell eller Bash, kender du det som "strengsubstitution".

Det er her, du på magisk vis kan få en sætning fuld af karakterer til at blive til en slags miniprogram.

Hvis du nogensinde har brugt Bash-skallen, vil du vide det, hvis du skriver kommandoen echo USER, vil den ekko eller udskrive strengen USER og du vil se, på skærmen USER.

Men hvis du kører kommandoen echo $USER, så betyder det ikke ekko et dollartegn efterfulgt af USER.

Hvad det betyder er, "Erstat den magiske streng med navnet på den aktuelt loggede bruger, og udskriv den i stedet."

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

Og nogle af Java-strengerstatningerne går meget, meget, meget længere end det … som enhver, der led glæden ved fikser Log4Shell over julen 2021 vil huske!

Der er alle mulige smarte små miniprogrammer, som du kan integrere i strenge, som du derefter behandler med dette strengbehandlingsbibliotek.

Så der er den indlysende: at læse brugernavnet, sætter du ${env: (for "læs miljøet") user}… du bruger snoede beslag.

Det er et dollartegn; snoede beslag; en eller anden magisk kommando; snoet beslag, der er den magiske del.

Og desværre var der i dette bibliotek ukontrolleret standardtilgængelighed af magiske kommandoer som: ${url:...}, som giver dig mulighed for at narre strengbehandlingsbiblioteket til at nå ud på internettet, downloade noget og udskrive, hvad det får tilbage fra den webserver i stedet for strengen ${url:...}.

Så selvom det ikke er helt kodeindsprøjtning, fordi det bare er rå HTML, betyder det stadig, at du kan lægge alverdens affald og underlige og vidunderlige upålidelige ting i folks logfiler eller deres websider.

Der er ${dns:...}, hvilket betyder, at du kan narre nogens server, som måske er en forretningslogikserver inde i netværket...

…du kan narre den til at lave et DNS-opslag for en navngivet server.

Og hvis du ejer det domæne, som en skurk, så ejer og driver du også den DNS-server, der er relateret til det pågældende domæne.

Så når DNS-opslag sker, gæt hvad?

Det opslag afsluttes *på din server* og kan måske hjælpe dig med at kortlægge det indre af en persons forretningsnetværk ... ikke kun deres webserver, men ting dybere i netværket.

Og til sidst, og mest bekymrende, i det mindste med ældre versioner af Java, var der... [GRIN] du ved, hvad der kommer her, Doug!

Kommandoen ${script:...}.

"Hej, lad mig give dig noget JavaScript, og kør det venligst for mig."

Og du tænker sikkert: "Hvad?! Vent, dette er en fejl i Java. Hvad har JavaScript med det at gøre?"

Nå, indtil forholdsvis for nylig ... og husk, at mange virksomheder stadig bruger ældre, stadig understøttede versioner af Java Development Kit.

Indtil for nylig indeholdt Java... [GRINER] (igen, jeg burde ikke grine)... Java Development Kit indeholdt i sig selv en fuld, fungerende JavaScript-motor, skrevet i Java.

Nu er der intet forhold mellem Java og JavaScript undtagen de fire bogstaver "Java", men du kunne sætte ${script:javascript:...}og kør kode efter eget valg.

Og, irriterende nok, er en af ​​de ting, du kan gøre i JavaScript-motoren inde i Java-runtime, at fortælle JavaScript-motoren: "Hej, jeg vil gerne køre denne ting via Java."

Så du kan få Java til at kalde *ind i* JavaScript, og JavaScript i det væsentlige til at kalde *ud* ind i Java.

Og så, fra Java, kan du gå, "Hey, kør denne systemkommando."

Og hvis du går til Naked Security-artiklen, vil du se, at jeg bruger en mistænkt kommando til at [HOSTER UNDSKYLDENDE] smutte, Doug!

En HP RPN-beregner, selvfølgelig, fordi det er mig, der laver lommeregneren...

---

DOUG.  Det skal være, ja!

---

AND.  …denne er en HP-10.

Så selvom risikoen ikke er som fantastisk som Log4Shell, du kan ikke rigtig udelukke det, hvis du bruger dette bibliotek.

Vi har nogle instruktioner i Naked Security-artiklen om, hvordan du finder ud af, om du har Commons Text-biblioteket ... og du kan have det, som mange mennesker gjorde med Log4J, uden at være klar over det, fordi det kan være fulgt med en app.

Og vi har også en prøvekode der, som du kan bruge til at teste, om eventuelle afhjælpninger, du har indført, har virket.

---

DOUG.  Okay, gå over til Naked Security.

Den artikel hedder: Farligt hul i Apache Commons-tekst – som Log4Shell igen.

Og vi slutter af med et spørgsmål: "Hvad sker der, når krypterede meddelelser kun er lidt krypterede?"

---

AND.  Ah, du refererer til, hvad der var en officiel fejlrapport indsendt af cybersikkerhedsforskere hos det finske firma WithSecure for nylig...

…om den indbyggede kryptering, der tilbydes i Microsoft Office, eller mere præcist, en funktion kaldet Office 365 Message Encryption eller OME.

Det er ret praktisk at have sådan en lille funktion indbygget i appen.

---

DOUG.  Ja, det lyder enkelt og praktisk!

---

AND.  Ja, undtagen... åh, kære!

Det lader til, at årsagen til dette er bagudkompatibilitet, Doug...

...at Microsoft ønsker, at denne funktion skal fungere helt tilbage til folk, der stadig bruger Office 2010, som har ret gammeldags dekrypteringsevner indbygget.

Dybest set ser det ud til, at denne OME-proces med at kryptere filen bruger AES, som er den nyeste og bedste NIST-standardiserede krypteringsalgoritme.

Men den bruger AES i den forkerte såkaldte krypteringstilstand.

Den bruger det, der er kendt som ECB, eller elektronisk kodebog mode.

Og det er simpelthen den måde, du refererer til rå AES.

AES krypterer 16 bytes ad gangen... i øvrigt krypterer den 16 bytes, uanset om du bruger AES-128, AES-192 eller AES-256.

Bland ikke blokstørrelsen og nøglestørrelsen – blokstørrelsen, antallet af bytes, der bliver churnet op og krypteret, hver gang du drejer håndsvinget på den kryptografiske motor, er altid 128 bis eller 16 bytes.

Uanset hvad, i elektronisk kodebogstilstand tager du blot 16 bytes input, drejer håndsvinget én gang under en given krypteringsnøgle og tager outputtet, råt og ubearbejdet.

Og problemet med det er, at hver gang du får det samme input i et dokument justeret på den samme 16-byte grænse...

…du får nøjagtig de samme data i outputtet.

Så mønstre i input afsløres i output, ligesom de er i en Caesar ciffer eller en Vigenère chiffer:

Nu betyder det ikke, at du kan knække chifferen, for du har stadig at gøre med bidder, der er 128 bit brede ad gangen.

Problemet med elektronisk kodebogstilstand opstår netop, fordi det lækker mønstre fra klarteksten ind i chifferteksten.

Kendte almindeligtekstangreb er mulige, når du ved, at en bestemt inputstreng krypterer på en bestemt måde, og for gentagen tekst i et dokument (som en header eller et firmanavn), afspejles disse mønstre.

Og selvom dette blev rapporteret som en fejl til Microsoft, har firmaet tilsyneladende besluttet, at det ikke vil rette det, fordi det "ikke opfylder baren" for en sikkerhedsrettelse.

Og det lader til, at årsagen er, "Nå, vi ville gøre en bjørnetjeneste for folk, der stadig bruger Office 2010."

---

DOUG.  Uff!

---

AND.  Ja!

---

DOUG.  Og på den note har vi en læserkommentar for denne uge til denne historie.

Nøgen sikkerhedslæser Bill kommenterer til dels:

Dette minder mig om 'krybberne', som Bletchley Park-kodebryderne brugte under Anden Verdenskrig. Nazisterne afsluttede ofte beskeder med den samme afsluttende sætning, og dermed kunne kodebryderne arbejde tilbage fra dette afsluttende sæt af krypterede tegn, velvidende hvad de sandsynligvis repræsenterede. Det er skuffende, at vi 80 år senere ser ud til at gentage de samme fejl.

---

AND.  80 år!

Ja, det er virkelig skuffende.

Min forståelse er, at andre krybber, som allierede kodebrydere kunne bruge, især til nazi-krypterede tekster, også beskæftigede sig med *begyndelsen* af dokumentet.

Jeg tror, ​​det var noget for tyske vejrmeldinger... der var et religiøst format, som de fulgte for at sikre, at de gav vejrrapporterne nøjagtigt.

Og vejrudsigter, som du kan forestille dig, under en krig, der involverer luftbombning om natten, var virkelig vigtige ting!

Det ser ud til, at de fulgte et meget, meget strengt mønster, der til tider kunne bruges som det, man kunne kalde lidt af en kryptografisk "løsner", eller en kile, som man kunne bruge til at bryde ind i første omgang.

Og det, som Bill påpeger... det er netop derfor, AES, eller en hvilken som helst cipher, i elektronisk kodebogstilstand ikke er tilfredsstillende til at kryptere hele dokumenter!

---

DOUG.  Okay, tak fordi du sendte det ind, Bill.

Hvis du har en interessant historie, kommentar eller spørgsmål, du gerne vil indsende, vil vi meget gerne læse den på podcasten.

Du kan sende en e-mail til tips@sophos.com, du kan kommentere på en af ​​vores artikler, eller du kan kontakte os på socialt: @nakedsecurity.

Det er vores show for i dag; mange tak fordi du lyttede.

For Paul Ducklin er jeg Doug Aamoth, og minder dig om, indtil næste gang...

---

BEGGE.  Hold dig sikker!