S3 Ep112: Datalekken kunnen u meer dan eens achtervolgen! [Audio + tekst]

Klik en sleep op de onderstaande geluidsgolven om naar een willekeurig punt te gaan. Je kan ook luister direct op Soundcloud.

DOUG.  SIM-swapping, zero-days, de [dramatische stem] Ping of DEATH en LastPass… alweer.

Dat alles, en meer, op de Naked Security-podcast.

[MUZIEK MODEM]

Welkom bij de podcast allemaal.

Ik ben Doug Aamoth.

Bij mij, zoals altijd, is Paul Ducklin.

Paulus, hoe gaat het met je?

---

EEND.  Heel goed, Doug.

Je hebt wat hoog dramageluid in die intro gestopt, ik ben blij om te zien!

---

DOUG.  Nou, hoe zeg je "Ping of Death" zonder [doom metal grom] "Ping of DEATH" te zeggen?

Je kunt niet zomaar [zachte stem] "Ping of Death" zeggen.

Je moet er een beetje tegenaan...

---

EEND.  Ik denk het.

Schriftelijk is het anders - wat heb je?

Vet en cursief.

Ik ging gewoon met normale tekst, maar ik gebruikte wel hoofdletters, wat helpt.

---

DOUG.  Ja, ik denk dat ik het woord "dood" vet en cursief zou maken, dus [doom metal weer] "The Ping of DEATH".

---

EEND.  En gebruik meerdere kleuren!

Dat zal ik de volgende keer doen, Doug.

---

DOUG.  Breek het oude uit tag in HTML, een beetje laten knipperen? [LACHT]

---

EEND.  Doug, even was ik bang dat je het woord zou gebruiken [LACHT] .

---

DOUG.  [LACHT] We houden hier van oude dingen!

En dat sluit mooi aan bij onze Deze week in de technische geschiedenis segment - Ik ben enthousiast over deze omdat ik er nog nooit van had gehoord, maar ik kwam hem tegen.

Deze week, op 04 december 2001, plunderde de Goner-worm het internet in een tempo dat het op één na na dat van het Love Bug-virus was.

Goner verspreidde zich via Microsoft Outlook en beloofde nietsvermoedende slachtoffers een leuke screensaver wanneer ze werden uitgevoerd.

---

EEND.  Weg...

Ik denk dat het die naam kreeg omdat er aan het einde een pop-up was, nietwaar, die noemde het Pentagon?

Maar het was bedoeld als woordspeling - het was "Penta/Gone".

Dat was zeker de worm die mensen eraan herinnerde dat Windows-screensavers in feite slechts uitvoerbare programma's zijn.

Dus, als je speciaal op zoek was naar .EXE dossiers, nou ja, ze kunnen erin verpakt zijn .SCR (screensaver) bestanden ook.

Als u alleen op bestandsnamen zou vertrouwen, zou u gemakkelijk kunnen worden misleid.

En veel mensen waren dat helaas.

---

DOUG.  Oké, we gaan van de oude school naar de nieuwe school.

We hebben het over LastPass: er was een inbreuk; de breuk zelf was niet verschrikkelijk; maar die breuk heeft nu geleid tot een nieuwe inbreuk.

Of misschien is dit slechts een voortzetting van de oorspronkelijke inbreuk?

LastPass geeft toe dat klantgegevens zijn geschonden veroorzaakt door eerdere inbreuk

---

EEND.  Ja, LastPass heeft er in wezen over geschreven als een vervolg op de vorige inbreuk, die volgens mij augustus 2022 was, nietwaar?

En zoals we destijds zeiden, was het een erg gênante blik voor LastPass.

Maar naarmate de inbreuken vorderen, was het waarschijnlijk erger voor hun PR-, marketing- en (denk ik) voor hun afdelingen voor intellectueel eigendom, omdat het belangrijkste dat de boeven eruit zagen komen de broncode van hun ontwikkelingssysteem was.

En LastPass was er snel bij om mensen gerust te stellen...

Ten eerste suggereerde hun onderzoek dat, terwijl ze daar waren, de boeven niet in staat waren om ongeoorloofde wijzigingen aan te brengen die later in de echte code zouden kunnen doorsijpelen.

Ten tweede geeft toegang tot het ontwikkelsysteem je geen toegang tot het productiesysteem, waar de daadwerkelijke code wordt gebouwd.

En ten derde konden ze zeggen dat het leek alsof er geen gecodeerde wachtwoordkluizen waren gestolen, dus de cloudopslag van je gecodeerde wachtwoorden was niet toegankelijk.

En zelfs als er toegang toe was, dan zou alleen jij het wachtwoord weten, omdat de decodering (wat je het "zware werk" noemde toen we erover spraken in de podcast) eigenlijk in het geheugen van je apparaten wordt gedaan - LastPass ziet nooit je wachtwoord.

En toen, ten vierde, zeiden ze dat, voor zover we kunnen nagaan, als gevolg van die inbreuk sommige dingen in de ontwikkelomgeving nu ofwel dezelfde... of mogelijk een heel andere lading boeven hebben opgeleverd die de gestolen gegevens van het vorige perceel, wie weet?

Dat stelde hen wel in staat om in een of andere cloudservice te komen waar een tot nu toe schijnbaar onbekende set klantgegevens werd gestolen.

Ik denk dat ze het nog niet helemaal weten, omdat het een tijdje kan duren om erachter te komen wat er daadwerkelijk is geopend nadat er een inbreuk heeft plaatsgevonden.

Dus ik denk dat het redelijk is om te zeggen dat dit een soort B-kant is van de oorspronkelijke breuk.

---

DOUG.  Oké, we raden je aan om, als je een LastPass-klant bent, het beveiligingsincidentrapport van het bedrijf in de gaten te houden.

We houden dit verhaal in de gaten, want het ontwikkelt zich nog steeds.

En als je, zoals Paul en ik, cybercriminaliteit bestrijdt voor de kost, zijn er enkele uitstekende lessen te trekken uit de inbreuk op Uber.

Dus dat is een podcast-aflevering – een “mini-isode” – met Chester Wisniewski die Paul onderaan het LastPass-artikel heeft ingesloten:

S3 Ep100.5: Uber-inbreuk - een expert spreekt [Audio + Text]

Veel te leren op dat vlak!

---

EEND.  Zoals je zegt, dat is goed luisteren, want het is, geloof ik, wat in Amerika bekend staat als "uitvoerbaar advies", of "nieuws dat je kunt gebruiken".

---

DOUG.  [LACHT] Prachtig.

Over nieuws gesproken dat je niet echt kunt gebruiken, Apple houdt over het algemeen de lippen stijf op elkaar over zijn beveiligingsupdates... en er was een beveiligingsupdate:

Apple duwt iOS-beveiligingsupdate uit die meer gesloten is dan ooit

---

EEND.  Oh, Doug, dat is een van je beste... Ik hou van dat deel.

---

DOUG.  [LACHT] Dank je; heel erg bedankt.

---

EEND.  Ja, dit verbaasde mij.

Ik dacht: "Nou, ik pak de update omdat het serieus klinkt."

En ik gaf mezelf de reden: "Laat mij het doen voor lezers van Naked Security."

Want als ik het doe en er zijn geen bijwerkingen, dan kan ik in ieder geval tegen andere mensen zeggen: “Kijk, ik deed het gewoon blindelings en het deed me geen kwaad. Dus misschien kan jij het ook.”

Ik merkte ineens dat er een iOS 16.1.2-update beschikbaar was, hoewel ik geen e-mail met beveiligingsadvies van Apple had gehad.

Geen e-mail?!

Dat is raar.. dus ging ik naar de HT201222 portaalpagina die Apple heeft voor zijn beveiligingsbulletins, en daar was het: iOS 16.1.2.

En wat staat er, Doug, "Details volgen spoedig"?

---

DOUG.  En volgden ze snel?

---

EEND.  Nou, dat was meer dan een week geleden, en ze zijn er nog niet.

Dus hebben we het over 'binnenkort', wat uren, dagen, weken of maanden betekent?

Op dit moment lijken het weken.

En, zoals altijd bij Apple, is er geen indicatie dat er iets met andere besturingssystemen te maken heeft.

Zijn ze vergeten?

Hebben ze de update niet nodig?

Hadden zij de update ook nodig, maar is die gewoon nog niet klaar?

Zijn ze uit de bijstand gevallen?

Maar het leek, zoals ik al zei in de kop, nog meer gesloten lippen dan normaal voor Apple, en niet noodzakelijkerwijs het meest behulpzame ding ter wereld.

---

DOUG.  OK, heel goed... nog enkele vragen, wat ons naar ons volgende verhaal leidt.

Een zeer interessante vraag!

Soms, wanneer u zich aanmeldt voor een service en tweefactorauthenticatie afdwingt, staat er: "Wil je een melding ontvangen via sms of wil je een authenticatie-app gebruiken?"

En dit verhaal is een waarschuwend verhaal om je telefoon niet te gebruiken - gebruik een authenticatie-app, ook al is het wat omslachtiger.

Dit is een heel interessant verhaal:

SIM-swapper naar de gevangenis gestuurd voor 2FA-cryptocurrency-overval van meer dan $ 20 miljoen

---

EEND.  Dat is het, Doug!

Als u ooit een mobiele telefoon bent kwijtgeraakt, of de toegang tot uw simkaart hebt geblokkeerd door de pincode te vaak verkeerd in te voeren, weet u dat u naar de gsm-winkel kunt gaan...

... en meestal vragen ze om een ​​identiteitsbewijs of zoiets, en jij zegt: "Hé, ik heb een nieuwe simkaart nodig."

En ze zullen er een voor je genereren.

Als je hem in je telefoon stopt, bingo!... staat je oude nummer erop.

Dus wat dat betekent is dat als een boef dezelfde oefening kan doen die je zou doen om het mobiele telefoonbedrijf ervan te overtuigen dat ze hun simkaart (dwz * je simkaart *) hebben "verloren" of "gebroken", en ze kunnen krijgen die kaart die op de een of andere manier aan hen is overhandigd of verzonden of aan hen is gegeven ...

...dan, wanneer ze het op hun telefoon aansluiten, beginnen ze je sms-tweefactorauthenticatiecodes te ontvangen, *en* werkt je telefoon niet meer.

Dat is het slechte nieuws.

Het goede nieuws in dit artikel is dat dit een geval was van een kerel die ervoor werd gepakt.

Hij zit in de VS voor 18 maanden in de gevangenis.

Hij, met een stel handlangers – of, in de woorden van het ministerie van Justitie, de Regeling deelnemers… [LACHT]

... ze gingen ervandoor met de cryptocurrency van een bepaald slachtoffer, blijkbaar voor een bedrag van $ 20 miljoen, als je het niet erg vindt.

---

DOUG.  Oef!

---

EEND.  Dus stemde hij ermee in om schuld te bekennen, een gevangenisstraf op te leggen en onmiddellijk verbeurd te verklaren... het bedrag was [goed lezend] $983,010.72... gewoon om dat meteen te verbeuren.

Dus vermoedelijk had hij dat nog liggen.

En hij heeft blijkbaar ook een soort wettelijke verplichting om meer dan $ 20 miljoen terug te betalen.

---

DOUG.  Succes ermee, allemaal! Veel geluk.

Zijn andere [vocal cursivering] Regeling deelnemers kan daar problemen veroorzaken! [LACHT]

---

EEND.  Ja, ik weet niet wat er gebeurt als zij ook weigeren mee te werken.

Als ze hem gewoon ophangen om te drogen, wat gebeurt er dan?

Maar we hebben enkele tips en advies over hoe u de beveiliging kunt verbeteren (op meer manieren dan alleen de 2FA die u gebruikt) in het artikel.

Dus ga dat maar eens lezen… alle kleine beetjes helpen.

---

DOUG.  OK, over "kleine beetjes" gesproken...

... dit was weer een fascinerend verhaal, hoe de nederigen ping kan worden gebruikt om de uitvoering van externe code te activeren:

Pingen van de dood! FreeBSD repareert crashtastic-bug in netwerktool

---

EEND.  [Ik vind het deel weer leuk] Ik denk dat je jezelf hebt verbeterd, Doug!

---

DOUG.  [LACHT] Ik ben goed bezig vandaag...

---

EEND.  Van Apple tot de [zwakke poging tot doomzang] Ping of DEATH!

Ja, dit was een intrigerende bug.

Ik denk niet dat het veel mensen echt veel kwaad zal doen, en het *is* gepatcht, dus het is gemakkelijk te repareren.

Maar er is een geweldige beschrijving in de FreeBSD beveiligingsadvies...

…en het zorgt voor een vermakelijk, en, al zeg ik het zelf, een zeer informatief verhaal voor de huidige generatie programmeurs die misschien hebben vertrouwd op: "bibliotheken van derden zullen het gewoon voor mij doen." Omgaan met netwerkpakketten op laag niveau? Ik hoef er nooit aan te denken..."

Er zijn hier enkele geweldige lessen te leren.

De ping utility, de enige netwerktool die vrijwel iedereen kent, dankt zijn naam aan SONAR.

Jij gaat [maakt filmonderzeeërgeluid] ping, en dan komt de echo terug van de server aan de andere kant.

En dit is een functie die is ingebouwd in het internetprotocol, IP, met behulp van iets dat ICMP wordt genoemd, wat staat voor Internet Control Message Protocol.

Het is een speciaal, low-level protocol, veel lager dan UDP of TCP waar mensen waarschijnlijk aan gewend zijn, dat zo ongeveer is ontworpen voor precies dit soort dingen: "Leef je eigenlijk wel aan de andere kant, voordat ik me zorgen ga maken waarom je webserver werkt niet?”

Er is een speciaal soort pakket dat u kunt verzenden, genaamd "ICMP Echo".

Dus je stuurt dit kleine pakketje met een kort bericht erin (het bericht kan van alles zijn wat je maar wilt), en het stuurt gewoon datzelfde bericht terug naar jou.

Het is gewoon een eenvoudige manier om te zeggen: "Als dat bericht niet terugkomt, is het netwerk of de hele server down", in plaats van dat er een softwareprobleem op de computer is.

Naar analogie met SONAR, heet het programma dat deze echo-verzoeken verstuurt... [pauze] Ik ga het geluidseffect doen, Doug... [opnieuw nep onderzeeër filmgeluid] ping. [GELACH]

En het idee is, jij gaat, zeg maar, ping -c3 (dat betekent drie keer controleren) nakedsecurity.sophos.com.

U kunt dat nu doen en u zou drie antwoorden moeten krijgen, elk met een seconde verschil, van de WordPress-servers die onze site hosten.

En het zegt dat de site leeft.

Het vertelt je niet dat de webserver actief is; het vertelt je niet dat WordPress actief is; het zegt niet dat Naked Security daadwerkelijk beschikbaar is om te lezen.

Maar het bevestigt in ieder geval dat u de server kunt zien en dat de server u kan bereiken.

En wie had gedacht dat dat kleine ping-antwoord de FreeBSD zou kunnen laten struikelen ping zodanig programmeren dat een malafide server een boobytrap-bericht "Ja, ik leef" terug kan sturen dat in theorie (alleen in theorie; ik denk niet dat iemand dit in de praktijk heeft gedaan) de uitvoering van externe code op jouw computer.

---

DOUG.  Ja, dat is geweldig; dat is het verbazingwekkende.

Ook al is het een proof-of-concept, het is zo'n kleinigheidje!

---

EEND.  De ping programma krijgt zelf het hele IP-pakket terug en zou het in twee delen moeten verdelen.

Normaal gesproken zou de kernel dit voor je afhandelen, dus je zou alleen het gegevensgedeelte zien.

Maar als je te maken hebt met wat heet ruwe stopcontacten, wat je terugkrijgt is de Internet Protocol-header, die alleen zegt: "Hé, deze bytes kwamen van die en die server."

En dan krijg je iets dat de "ICMP Echo Reply" wordt genoemd, wat de tweede helft is van het pakket dat je terugkrijgt.

Deze pakketten zijn meestal slechts 100 bytes of zo, en als het IPv4 is, zijn de eerste 20 bytes de IP-header en de rest, wat het ook is, is het echoantwoord.

Dat heeft een paar bytes om te zeggen: "Dit is een echo-antwoord", en dan komt het oorspronkelijke bericht dat uitging terug.

En dus ligt het voor de hand, Doug, als je het krijgt, is het op te splitsen in...

…de IP-header, die 20 bytes lang is, en de rest.

Raad eens waar het probleem ligt?

---

DOUG.  Vertel!

---

EEND.  Het probleem is dat IP-headers *bijna altijd* 20 bytes lang zijn - sterker nog, ik denk niet dat ik er ooit een heb gezien die dat niet was.

En je kunt zien dat ze 20 bytes lang zijn omdat de eerste byte hexadecimaal is 0x45.

De "4" betekent IPv4, en de "5"... "Oh, dat gebruiken we om aan te geven hoe lang de header is."

Je neemt dat getal 5 en je vermenigvuldigt het met 4 (voor 32-bits waarden), en je krijgt 20 bytes..

...en dat is de grootte van waarschijnlijk zes sigma's aan IP-headers die je ooit in de hele wereld zult zien, Doug. [GELACH]

Maar ze *kunnen* oplopen tot 60 bytes.

Als je 0x4F in plaats van 0x45, dat zegt dat er 0xF (of 15 in decimalen) × 4 = 60 bytes in de kop staan.

En de FreeBSD-code nam gewoon die header en kopieerde die naar een buffer op de stack die 20 bytes groot was.

Een eenvoudige, ouderwetse stackbufferoverloop.

Het is een geval van een eerbiedwaardige tool voor het oplossen van netwerkproblemen met een eerbiedwaardig soort bug erin. (Nou, niet meer.)

Dus als je aan het programmeren bent en je hebt te maken met dingen op een laag niveau waar niemand echt lang over heeft nagedacht, ga dan niet alleen maar mee met de algemeen aanvaarde wijsheid die zegt: “Oh, het zal altijd 20 bytes zijn; je zult nooit iets groters zien.

Want op een dag misschien.

En als die dag komt, kan het daar met opzet zijn omdat een boef het met opzet zo heeft gemaakt.

Dus de duivel zit, zoals altijd, in de programmeringsdetails, Doug.

---

DOUG.  Oké, erg interessant; goed verhaal.

En we blijven bij het onderwerp code met dit laatste verhaal over Chrome.

Nog een zero-day, wat het totaal van 2022 op negen keer brengt:

Nummer negen! Chrome repareert nog een zero-day uit 2022, ook Edge gepatcht

---

EEND.  [Formele stem, klinkt als een opname] "Nummer 9. Nummer 9. Nummer 9, nummer 9," Douglas.

---

DOUG.  [LACHT] Is dit Yoko Ono?

---

EEND.  Dat is Revolutie 9 van het Beatles "White Album".

Je kunt Yoko horen riffen in dat nummer - dat geluidslandschap, ik geloof dat ze het zo noemen – maar blijkbaar was het stuk aan het begin waar iemand steeds weer "Nummer 9, nummer 9" zegt, in feite een testbandje dat ze ergens vonden liggen.

---

DOUG.  Ach, heel gaaf.

---

EEND.  Een EMI-technicus die zoiets zegt als: "Dit is EMI-testband nummer 9" [GELACH], en blijkbaar denk ik niet eens dat iemand weet wiens stem het was.

Dat heeft *niets* te maken met Chrome, Doug.

Maar aangezien iemand onlangs op Facebook opmerkte: "Die Paul-man begint op een Beatle te lijken" ... [vragend] wat ik een beetje vreemd vond.

---

DOUG.  [LACHT] Ja, hoe moet je dat opvatten?

---

EEND.  …Ik dacht dat ik uit eten kon gaan op "Nummer 9".

Het is tot nu toe de negende nuldag van het jaar, zo lijkt het, Doug.

En het is een one-bug fix, met de bug geïdentificeerd als CVE 2022-4282.

Omdat Microsoft Edge de open-source kern van Chromium gebruikt, was ook deze kwetsbaar en een paar dagen later volgde Microsoft met een update voor Edge.

Dit is dus zowel een Chrome- als een Edge-probleem.

Hoewel die browsers zichzelf zouden moeten updaten, raad ik aan om het toch te controleren – we laten je in het artikel zien hoe je dat moet doen – voor het geval dat.

Ik zal de versienummers hier niet voorlezen omdat ze anders zijn voor Mac, Linux en Windows op Chrome, en ze zijn weer anders voor Edge.

Net als Apple houdt Google hier een beetje de lippen stijf op.

Het is gevonden door een van hun dreigingsteams, geloof ik.

Dus ik stel me voor dat ze het hebben gevonden tijdens het onderzoeken van een incident dat in het wild is gebeurd, en daarom willen ze het waarschijnlijk onder hun hoede houden, ook al heeft Google meestal veel te zeggen over "openheid" als het gaat om het oplossen van bugs.

Je begrijpt waarom je in een geval als dit misschien wat tijd nodig hebt om wat dieper te graven voordat je iedereen precies vertelt hoe het werkt.

---

DOUG.  Uitstekend ... en we hebben een lezersvraag die waarschijnlijk veel mensen denken.

Cassandra vraagt: “Hebben de bugvinders gewoon geluk met het vinden van bugs? Of hebben ze een 'naad' vol bugs geraakt? Of geeft Chromium nieuwe code uit die meer fouten bevat dan normaal? Of is er iets anders aan de hand?”

---

EEND.  Ja, dat is eigenlijk een geweldige vraag, en ik ben bang dat ik die alleen op een ietwat grappige manier kan beantwoorden, Doug.

Omdat Cassandra keuzes A), B) en C) had gegeven, zei ik: “Nou, misschien wel D) Al het bovenstaande."

We weten wel dat wanneer een bug van een bepaalde soort in code verschijnt, het redelijk is om aan te nemen dat dezelfde programmeur soortgelijke bugs elders in de software heeft gemaakt.

Of andere programmeurs bij hetzelfde bedrijf hebben mogelijk gebruik gemaakt van wat destijds als algemeen aanvaarde wijsheid of standaardpraktijk werd beschouwd, en hebben mogelijk dit voorbeeld gevolgd.

En een goed voorbeeld is, als je terugkijkt naar Log4J... er was een oplossing om het probleem op te lossen.

En toen ze gingen kijken: "Oh, eigenlijk zijn er andere plaatsen waar soortgelijke fouten zijn gemaakt."

Dus er was een oplossing voor de oplossing, en toen was er een oplossing voor de oplossing voor de oplossing, als ik het me goed herinner.

Er is natuurlijk ook het probleem dat wanneer u nieuwe code toevoegt, u bugs kunt krijgen die uniek zijn voor die nieuwe code en ontstaan ​​door het toevoegen van functies.

En dat is de reden waarom veel browsers, inclusief Chrome, een "iets oudere" versie hebben waar je je aan kunt houden.

En het idee is dat die "oudere" releases ... ze hebben geen van de nieuwe functies, maar alle relevante beveiligingsoplossingen.

Dus als u conservatief wilt zijn over nieuwe functies, dan kan dat.

Maar we weten zeker dat, wanneer u nieuwe functies in een product schept, er soms nieuwe bugs met de nieuwe functies komen.

En dat merk je bijvoorbeeld als er een update is, bijvoorbeeld voor je iPhone, en je krijgt updates voor bijvoorbeeld iOS 15 en iOS 16.

Als je dan naar de buglijsten kijkt, zijn er weinig bugs die alleen van toepassing zijn op iOS 16.

En je denkt: "Hallo, dat moeten bugs in de code zijn die er eerder niet waren."

Dus ja, dat is een mogelijkheid.

En ik denk dat de andere dingen die gaande zijn als goed kunnen worden beschouwd.

De eerste is dat ik denk dat, met name voor zaken als browsers, de browsermakers veel beter worden in het heel, heel snel volledig opnieuw opbouwen.

---

DOUG.  Interessant.

---

EEND.  En ik denk dat het andere dat is veranderd, is dat je in het verleden zou kunnen stellen dat het voor veel leveranciers vrij moeilijk was om mensen überhaupt patches te laten toepassen, zelfs als ze slechts maandelijks uitkwamen, en zelfs als ze hadden meerdere zero-day fixes in zich.

Ik denk dat het misschien ook een reactie is op het feit dat steeds meer van ons meer en meer geneigd zijn niet alleen te accepteren, maar zelfs *verwachten* automatische updates die echt snel zijn.

Dus ik denk dat je hier wat goeds in kunt lezen.

Niet alleen het feit dat Google vrijwel onmiddellijk een enkele zero-day fix kan uitbrengen, maar ook dat mensen bereid zijn dat te accepteren en zelfs te eisen.

Dus ik zie graag dat nummer van: "Wauw, negen nuldagen in het jaar individueel vastgesteld!"...

...Ik zie dat liever als "glas half vullen en vullen" dan "glas half leeg en leeglopen door een klein gaatje in de bodem". [GELACH]

Dat is mijn mening.

---

DOUG.  Oké, heel goed.

Bedankt voor de vraag, Cassandra.

Als je een interessant verhaal, opmerking of vraag hebt die je wilt indienen, lezen we die graag in de podcast.

U kunt een e-mail sturen naar tips@sophos.com, reageren op een van onze artikelen of u kunt ons bereiken op social: @NakedSecurity.

Dat is onze show voor vandaag; heel erg bedankt voor het luisteren.

Voor Paul Ducklin, ik ben Doug Aamoth, ik herinner je eraan: tot de volgende keer...

---

BEIDE.  Blijf veilig!

[MUZIEK MODEM]