S3 Ep95: Slack-lek, Github-aanval en post-kwantumcrypto [Audio + Tekst]

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

DOUG.  Slappe lekken, ondeugende GitHub-code en post-kwantumcryptografie.

Dat alles en nog veel meer in de podcast Naked Security.

[MUZIEK MODEM]

Welkom bij de podcast, allemaal.

Ik ben Doug Aamoth.

Bij mij, zoals altijd, is Paul Ducklin.

Paul, hoe gaat het vandaag?

---

EEND.  Super-duper, zoals gewoonlijk, Doug!

---

DOUG.  Ik ben super-duper opgewonden om naar deze week te gaan Technische geschiedenis segmenteren, omdat...

... je was erbij, man!

Deze week, op 11 augustus…

---

EEND.  Oh nee!

Ik denk dat het kwartje net is gevallen...

---

DOUG.  Ik hoef niet eens het jaartal te noemen!

11 augustus 2003 – de wereld nam kennis van de Blaster-worm, die Windows 2000- en Windows XP-systemen aantast.

Blaster, ook bekend als Lovesan en MsBlast, maakte gebruik van een bufferoverloop en is misschien het best bekend om de boodschap: 'Billy Gates, waarom maak je dit mogelijk? Stop met geld verdienen en repareer uw software.”

Wat is er gebeurd, Paulus?

---

EEND.  Nou, het was het tijdperk ervoor, misschien namen we beveiliging zo serieus.

En gelukkig zou dat soort bug tegenwoordig veel, veel moeilijker te exploiteren zijn: het was een op stapels gebaseerde bufferoverloop.

En als ik het me goed herinner, werden de serverversies van Windows al gebouwd met wat heet stapel bescherming.

Met andere woorden, als u de stapel binnen een functie overloopt, zal deze, voordat de functie terugkeert en de schade aanricht met de beschadigde stapel, detecteren dat er iets ergs is gebeurd.

Het moet dus het aanstootgevende programma afsluiten, maar de malware kan niet worden uitgevoerd.

Maar die bescherming zat op dat moment niet in de clientversies van Windows.

En zoals ik me herinner, was het een van die vroege malwares die moesten raden welke versie van het besturingssysteem je had.

Zit je op 2000? Zit je op NT? Zit je op XP?

En als het fout zou gaan, zou een belangrijk deel van het systeem crashen en zou je de waarschuwing "Je systeem gaat afsluiten" krijgen.

---

DOUG.  Haha, die herken ik nog!

---

EEND.  Dus er was die bijkomende schade die voor veel mensen het teken was dat je werd gehamerd door infecties ...

…wat van buitenaf kan zijn, alsof je gewoon een thuisgebruiker bent en je thuis geen router of firewall hebt.

Maar als je binnen een bedrijf zat, zou de meest waarschijnlijke aanval komen van iemand anders binnen het bedrijf, die pakketten op je netwerk spuwde.

Dus, net als de CodeRed-aanval waar we het over hadden, die een paar jaar daarvoor was, in een recente podcast, was het echt de enorme schaal, het volume en de snelheid van dit ding dat het probleem was.

---

DOUG.  Goed, dat was ongeveer 20 jaar geleden.

En als we de klok terugdraaien naar vijf jaar geleden, dan is dat wanneer Slack begon te lekken gehashte wachtwoorden. [GELACH]

---

EEND.  Ja, Slack, de populaire samenwerkingstool...

... het heeft een functie waarmee u een uitnodigingslink naar andere mensen kunt sturen om lid te worden van uw werkruimte.

En je stelt je voor: je klikt op een knop met de tekst "Genereer een link", en het zal een soort netwerkpakket maken dat waarschijnlijk wat JSON bevat.

Als je ooit een uitnodiging voor een Zoom-vergadering hebt gehad, weet je dat deze een datum en een tijd heeft, en de persoon die je uitnodigt, en een URL die je voor de vergadering kunt gebruiken, en een toegangscode, en dat alles dingen - het heeft behoorlijk veel gegevens daar.

Normaal gesproken graaf je niet in de onbewerkte gegevens om te zien wat er in zit - de klant zegt gewoon: "Hé, hier is een vergadering, hier zijn de details. Wilt u Accepteren / Misschien / Weigeren?”

Het bleek dat toen je dit met Slack deed, zoals je zegt, gedurende meer dan vijf jaar, verpakt in die uitnodiging externe gegevens waren die niet strikt relevant waren voor de uitnodiging zelf.

Dus geen URL, geen naam, geen datum, geen tijd...

…maar de *uitnodigende wachtwoordhash* [GELACHT]

---

DOUG.  Hmmmmm.

---

EEND.  Ik hou niet van je!

---

DOUG.  Dat klinkt slecht...

---

EEND.  Ja, dat is echt zo, nietwaar?

Het slechte nieuws is, hoe is dat in hemelsnaam binnengekomen?

En, toen het daar eenmaal was, hoe kon het in vredesnaam vijf jaar en drie maanden de kennisgeving ontwijken?

Sterker nog, als je het artikel over Naked Security bezoekt en kijkt naar de volledige URL van het artikel, zult u merken dat er aan het einde staat, blahblahblah-for-three-months.

Want toen ik het rapport voor het eerst las, wilde mijn hoofd het niet als 2017 zien! [GELACH]

Het was 17 april t/m 17 juli, en er zaten dus heel veel "17"s in.

En mijn geest wist 2017 uit als het beginjaar - ik las het verkeerd als "april tot juli *van dit jaar*" [2022].

Ik dacht: "Wauw, * drie maanden * en ze merkten het niet."

En toen was de eerste reactie op het artikel: “Ahem [HOEST]. Het was eigenlijk 17 april *2017*.”

Wow!

Maar iemand bedacht het op 17 juli [2022], en Slack, tot hun verdienste, repareerde het dezelfde dag.

Zoals: "Oh, golly, wat dachten we ?!"

Dus dat is het slechte nieuws.

Het goede nieuws is dat het in ieder geval *gehashte* wachtwoorden waren.

En ze waren niet alleen gehasht, ze waren *gezouten*, dat is waar je uniek gekozen, willekeurige gegevens per gebruiker mengt met het wachtwoord.

Het idee hiervan is tweeledig.

Ten eerste, als twee mensen hetzelfde wachtwoord kiezen, krijgen ze niet dezelfde hash, dus je kunt geen conclusies trekken door de hash-database te doorzoeken.

En twee, je kunt geen woordenboek van bekende hashes voor bekende invoer berekenen, omdat je voor elk wachtwoord *voor elk zout* een apart woordenboek moet maken.

Het is dus geen triviale oefening om gehashte wachtwoorden te kraken.

Dat gezegd hebbende, het hele idee is dat ze niet bedoeld zijn om openbaar te worden gemaakt.

Ze zijn gehasht en gezouten *voor het geval* ze lekken, niet *zodat ze kunnen* lekken.

Dus ei op Slack's gezicht!

Slack zegt dat ongeveer één op de 200 gebruikers, of 0.5%, werd getroffen.

Maar als je een Slack-gebruiker bent, zou ik aannemen dat als ze zich niet realiseerden dat ze vijf jaar lang gehashte wachtwoorden lekten, ze de lijst met getroffen personen misschien ook niet helemaal opsommen.

Dus, ga en verander toch je wachtwoord ... dat kan je net zo goed.

---

DOUG.  OK, we zeggen ook: als je geen wachtwoordmanager gebruikt, overweeg er dan een aan te schaffen; en zet 2FA aan als je kunt.

---

EEND.  Ik dacht dat je dat wel leuk zou vinden, Doug.

---

DOUG.  Ja, ik wil!

En dan, als je Slack bent of een bedrijf zoals het, kies dan een gerenommeerd salt-hash-and-stretch-algoritme wanneer u zelf met wachtwoorden omgaat.

---

EEND.  Ja.

Het grote probleem in de reactie van Slack, en wat ik dacht dat ontbrak, is dat ze gewoon zeiden: "Maak je geen zorgen, we hebben niet alleen de wachtwoorden gehasht, we hebben ze ook gezouten."

Mijn advies is dat als je op een dergelijke inbreuk wordt betrapt, je bereid moet zijn om het algoritme of het proces dat je hebt gebruikt voor het zouten en hashen te declareren, en idealiter ook wat wordt genoemd stretching, waarbij je het gezouten wachtwoord niet één keer hasht, maar misschien wel 100,000 keer hasht om elke vorm van woordenboek of brute force-aanval te vertragen.

En als je aangeeft welk algoritme je gebruikt en met welke parameters.. bijvoorbeeld PBKDF2, bcrypt, scrypt, Argon2 - dat zijn de bekendste wachtwoord "salt-hash-stretch" algoritmen die er zijn.

Als je daadwerkelijk aangeeft welk algoritme je gebruikt, dan: [A] ben je opener, en [B] geef je potentiële slachtoffers van het probleem de kans om zelf in te schatten hoe gevaarlijk ze denken dat dit zou kunnen zijn geweest .

En dat soort openheid kan echt veel helpen.

Dat deed Slack niet.

Ze zeiden gewoon: "O, ze waren gezouten en gepureerd."

Maar wat we niet weten, is of ze er twee bytes zout in hebben gedaan en ze vervolgens een keer hebben gehasht met SHA-1...

...of hadden ze iets dat beter bestand was tegen scheuren?

---

DOUG.  Als we ons beperken tot het onderwerp slechte dingen, zien we een trend ontstaan ​​waarin mensen slechte dingen in GitHub injecteren, gewoon om te zien wat er gebeurt, risico's blootstellen ...

...we hebben nog zo'n verhaal.

---

EEND.  Ja, iemand die nu naar verluidt naar buiten is gekomen op Twitter en zei: "Maak je geen zorgen jongens, geen kwaad gedaan. Het was alleen voor onderzoek. Ik ga een verslag schrijven, me onderscheiden van Blue Alert.”

Ze creëerden letterlijk duizenden nep GitHub-projecten, gebaseerd op het kopiëren van bestaande legitieme code, waarbij ze opzettelijk enkele malware-commando's invoegden, zoals "bel naar huis voor verdere instructies", en "interpreteer de hoofdtekst van het antwoord als achterdeurcode om uit te voeren", en spoedig.

Dus dingen die echt kwaad zouden kunnen doen als je een van deze pakketten zou installeren.

Geef ze legitieme namen...

... blijkbaar de commit-geschiedenis van een echt project lenen, zodat het ding er veel legitiemer uitzag dan je anders zou verwachten als het gewoon zou verschijnen met: "Hé, download dit bestand. Je weet dat je het wilt!"

Werkelijk?! Onderzoek?? Dit wisten we nog niet?!?

Nu kun je stellen: "Wel, Microsoft, wie bezit GitHub, wat doen ze om het zo gemakkelijk te maken voor mensen om dit soort dingen te uploaden?"

En daar zit een kern van waarheid in.

Misschien kunnen ze er beter aan doen om malware buiten de deur te houden.

Maar het gaat een beetje overdreven om te zeggen: "Oh, het is allemaal de schuld van Microsoft."

Het is naar mijn mening nog erger om te zeggen: “Ja, dit is echt onderzoek; dit is echt belangrijk; we moeten mensen eraan herinneren dat dit kan gebeuren.”

Nou, [A] dat weten we al, heel erg bedankt, want heel veel mensen hebben dit eerder gedaan; we kregen de boodschap luid en duidelijk.

En [B] dit *is geen* onderzoek.

Dit is opzettelijk proberen mensen te misleiden om code te downloaden die een potentiële aanvaller afstandsbediening geeft, in ruil voor de mogelijkheid om een ​​rapport te schrijven.

Dat klinkt voor mij meer als een "dikke smoes" dan als een legitieme motivator voor onderzoek.

En dus is mijn aanbeveling, als je denkt dat dit *onderzoek* is, en als je vastbesloten bent om zoiets helemaal opnieuw te doen, *verwacht dan niet heel veel sympathie* als je gepakt wordt.

---

DOUG.  Oké - we komen hierop terug en de lezer geeft commentaar aan het einde van de show, dus blijf in de buurt.

Maar laten we het eerst hebben over verkeerslichten, en wat ze te maken hebben met cybersecurity.

---

EEND.  Aaah, ja! [LACHEN]

Nou, er is iets dat TLP heet, de Verkeerslichtprotocol.

En de TLP is wat je zou kunnen noemen een "onderzoeksprotocol voor menselijke cyberbeveiliging" waarmee je documenten die je naar andere mensen verzendt, kunt labelen, om ze een hint te geven van wat je hoopt dat ze zullen doen (en, belangrijker nog, wat je hoopt dat ze zullen doen * niet*) doen met de gegevens.

In het bijzonder, hoe breed moeten ze het herverdelen?

Is dit iets zo belangrijk dat je het aan de wereld zou kunnen verklaren?

Of is dit potentieel gevaarlijk, of bevat het mogelijk dingen die we nog niet openbaar willen maken... dus houd het voor jezelf?

En het begon met: TLP:RED, wat betekende: "Hou het voor jezelf"; TLP:AMBER, wat betekende: "U kunt het verspreiden binnen uw eigen bedrijf of onder klanten van u waarvan u denkt dat ze dit dringend moeten weten"; TLP:GREEN, wat betekende: "OK, u kunt dit breed laten circuleren binnen de cyberbeveiligingsgemeenschap."

En TLP:WHITE, wat betekende: "Je kunt het aan iedereen vertellen."

Heel handig, heel eenvoudig: ROOD, AMBER, GROEN... een metafoor die wereldwijd werkt, zonder je zorgen te maken over wat het verschil is tussen "geheim" en "vertrouwelijk" en wat het verschil is tussen "vertrouwelijk" en "geclassificeerd", al die ingewikkelde dingen die heeft een heleboel wetten eromheen nodig.

Nou, de TLP heeft net wat wijzigingen ondergaan.

Dus als u zich bezighoudt met onderzoek naar cyberbeveiliging, zorg er dan voor dat u hiervan op de hoogte bent.

TLP:WHITE is veranderd in wat ik eigenlijk een veel betere term vind, omdat wit heeft al deze onnodige culturele boventonen waar we in de moderne tijd zonder kunnen.

Dus, TLP:WHITE is net geworden TLP:CLEAR, wat naar mijn mening een veel beter woord is omdat het zegt: "Je bent duidelijk om deze gegevens te gebruiken", en die bedoeling wordt vermeld, ahem, heel duidelijk. (Sorry, ik kon de woordspeling niet weerstaan.)

En er is een extra laag (dus het heeft de metafoor een beetje verpest - het is nu een *vijf*-kleuren kleurenverkeerslicht!).

Er is een speciaal niveau genaamd TLP:AMBER+STRICT, en wat dat betekent is: "Je kunt dit binnen je bedrijf delen."

Dus je wordt misschien uitgenodigd voor een vergadering, misschien werk je voor een cyberbeveiligingsbedrijf, en het is vrij duidelijk dat je dit aan programmeurs moet laten zien, misschien aan je IT-team, misschien aan je kwaliteitsborgingsmensen, zodat je onderzoek kunt doen naar het probleem of het oplossen ervan.

Maar TLP:AMBER+STRICT betekent dat hoewel u het binnen uw organisatie kunt verspreiden, *vertel het niet aan uw klanten of uw klanten*, of zelfs niet aan mensen buiten het bedrijf waarvan u denkt dat ze het moeten weten.

Houd het om te beginnen binnen de hechtere gemeenschap.

TLP:AMBER, zoals eerder, betekent: "OK, als u denkt dat u het uw klanten moet vertellen, dan kan dat."

En dat kan belangrijk zijn, want soms wil je je klanten misschien zeggen: 'Hé, er komt een oplossing. U moet enkele voorzorgsmaatregelen nemen voordat de oplossing arriveert. Maar omdat het nogal gevoelig ligt, mogen we vragen dat je het de wereld nog niet vertelt?”

Soms speelt het te vroeg vertellen van de wereld de boeven meer in de kaart dan de verdedigers.

Dus, als je een cybersecurity-responder bent, raad ik je aan het volgende te doen: https://www.first.org/tlp

---

DOUG.  En dat kan lees daar meer over op onze site, Nakedsecurity.sophos.com.

En als u op zoek bent naar een andere lichte lezing, vergeet dan kwantumcryptografie... we gaan verder met post-kwantumcryptografie, Paulus!

---

EEND.  Ja, we hebben het hier al een paar keer eerder over gehad in de podcast, nietwaar?

Het idee van een kwantumcomputer, ervan uitgaande dat er een krachtig en betrouwbaar genoeg zou kunnen worden gebouwd, is dat bepaalde soorten algoritmen kunnen worden versneld over de stand van de techniek van vandaag, ofwel op de melodie van de vierkantswortel ... of erger nog, de *logaritme* van de omvang van het probleem vandaag.

Met andere woorden, in plaats van 2 . te nemen²⁵⁶ probeert een bestand met een bepaalde hash te vinden, kunt u dit misschien in slechts ("slechts"!) 2 . doen¹²⁸ probeert, wat de vierkantswortel is.

Duidelijk een stuk sneller.

Maar er is een hele reeks problemen met het ontbinden van producten van priemgetallen waarvan de theorie zegt dat ze kunnen worden gekraakt in de *logaritme* van de tijd die ze tegenwoordig, losjes gesproken, in beslag nemen.

Dus, in plaats van, laten we zeggen, 2¹²⁸ dagen om te kraken [VEEL LANGER DAN DE HUIDIGE LEEFTIJD VAN HET HEELAL], kan het slechts 128 dagen duren om te kraken.

Of u kunt "dagen" vervangen door "minuten", of wat dan ook.

En helaas, dat logaritmische tijdalgoritme (genaamd Shor's kwantumfactorisatie-algoritme)… dat zou in theorie kunnen worden toegepast op sommige van de huidige cryptografische technieken, met name die welke worden gebruikt voor cryptografie met openbare sleutels.

En voor het geval deze kwantumcomputerapparatuur de komende jaren haalbaar wordt, moeten we ons misschien nu gaan voorbereiden op versleutelingsalgoritmen die niet kwetsbaar zijn voor deze twee specifieke soorten aanvallen?

Vooral de logaritme, omdat het potentiële aanvallen zo sterk versnelt dat cryptografische sleutels waarvan we momenteel denken: "Nou, daar komt niemand ooit achter", in een later stadium misschien openbaar worden.

Hoe dan ook, NIST, de Nationaal instituut voor normen en technologie in de VS, heeft al enkele jaren een wedstrijd gehouden om te proberen een aantal openbare, niet-gepatenteerde, goed onderzochte algoritmen te standaardiseren die bestand zullen zijn tegen deze magische kwantumcomputers, als ze ooit verschijnen.

En onlangs kozen ze vier algoritmen die ze nu willen standaardiseren.

Ze hebben coole namen, Doug, dus ik moet ze voorlezen: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON en SPHINCS+. [GELACH]

Dus ze hebben coole namen, als niets anders.

Maar tegelijkertijd bedacht NIST: “Nou, dat zijn maar vier algoritmen. Wat we zullen doen, is dat we er nog vier zullen kiezen als potentiële secundaire kandidaten, en we zullen zien of een van die ook door moet gaan."

Er zijn nu dus vier gestandaardiseerde algoritmen en vier algoritmen die in de toekomst gestandaardiseerd kunnen worden.

Of er *waren* vier op 5 juli 2022, en een daarvan was SIKE, kort voor supersingular isogeny key inkapseling.

(We hebben verschillende podcasts nodig om supersinguliere isogenieën uit te leggen, dus we zullen niet de moeite nemen. [GELACH])

Maar helaas, deze, die daar bleef hangen met een vechtkans om gestandaardiseerd te worden, het lijkt alsof hij onherstelbaar is gebroken, ondanks dat hij al minstens vijf jaar open is geweest voor publieke controle.

Dus, gelukkig, net voordat het gestandaardiseerd werd of kon worden, bedachten twee Belgische cryptografen: “Weet je wat? We denken dat we dit kunnen omzeilen door berekeningen te gebruiken die ongeveer een uur duren, op een redelijk gemiddelde CPU en met slechts één core.”

---

DOUG.  Ik denk dat het beter is om daar nu achter te komen dan nadat je het hebt gestandaardiseerd en het in het wild hebt uitgezet?

---

EEND.  Inderdaad!

Ik denk dat als het een van de al gestandaardiseerde algoritmen was geweest, ze de standaard hadden moeten intrekken en met een nieuwe zouden moeten komen?

Het lijkt raar dat dit vijf jaar lang niet is opgemerkt.

Maar ik denk dat dat het hele idee is van publieke controle: je weet nooit wanneer iemand de spleet kan raken die nodig is, of de kleine wig die ze kunnen gebruiken om in te breken en te bewijzen dat het algoritme niet zo sterk is als oorspronkelijk werd gedacht.

Een goede herinnering dat als je *ooit* erover denkt om je eigen cryptografie te breien...

---

DOUG.  [LACHT] Dat heb ik niet!

---

EEND.  ..ondanks dat we je N keer op de Naked Security-podcast hebben gezegd: "Doe dat niet!"

Dit zou de ultieme herinnering moeten zijn dat, zelfs wanneer echte experts een algoritme publiceren dat gedurende vijf jaar in een wereldwijde competitie aan openbare controle wordt onderworpen, dit nog steeds niet noodzakelijkerwijs voldoende tijd biedt om fouten aan het licht te brengen die behoorlijk slecht blijken te zijn.

Het ziet er hier dus zeker niet goed uit SIKE algoritme.

En wie weet, misschien wordt het ingetrokken?

---

DOUG.  Wij zullen dat in de gaten houden.

En terwijl de zon langzaam ondergaat in onze show voor deze week, is het tijd om van een van onze lezers te horen over het GitHub-verhaal dat we eerder hebben besproken.

Beroven schrijft:

"Er staat wat krijt en kaas in de commentaren, en ik haat het om het te zeggen, maar ik kan echt beide kanten van het argument zien. Is het gevaarlijk, lastig, tijdverspillend en verbruikend? Ja, natuurlijk is dat zo. Is het wat crimineel ingestelde types zouden doen? Ja ja het is. Is het een herinnering voor iedereen die GitHub of een ander coderepositorysysteem gebruikt, dat veilig reizen op internet een gezonde mate van cynisme en paranoia vereist? Ja. Als systeembeheerder wil een deel van mij de blootstelling van het aanwezige risico toejuichen. Als systeembeheerder van een aantal ontwikkelaars moet ik er nu voor zorgen dat iedereen de laatste tijd alle mogelijke pulls heeft doorzocht op dubieuze inzendingen.”

---

EEND.  Ja, bedankt, RobB, voor die opmerking, want ik denk dat het belangrijk is om beide kanten van het argument te zien.

Er waren commentatoren die alleen maar zeiden: "Wat is hier in godsnaam het probleem mee? Dit is geweldig!"

Een persoon zei, “Nee, eigenlijk is deze pentest goed en nuttig. Wees blij dat deze nu worden ontmaskerd in plaats van hun lelijke kop op te steken van een echte aanvaller.”

En mijn antwoord daarop is: "Nou, dit * is * eigenlijk een aanval."

Het is alleen dat er nu iemand naar buiten is gekomen die zegt: "Oh nee, nee. Geen kwaad gedaan! Eerlijk gezegd was ik niet ondeugend."

Ik denk niet dat je verplicht bent om dat excuus te kopen!

Maar goed, dit is geen penetratietest.

Mijn antwoord was om heel eenvoudig te zeggen: “Verantwoorde penetratietesters handelen [A] alleen na uitdrukkelijke toestemming, en [B] binnen gedragsgrenzen die vooraf expliciet zijn overeengekomen.”

Regels verzin je niet zomaar, dat hebben we al eerder besproken.

Dus, zoals een andere commentator zei, wat, denk ik, mijn favoriete opmerking is... Ecurb zei:, "Ik denk dat iemand van huis tot huis moet lopen en ramen moet inslaan om te laten zien hoe ineffectief deursloten werkelijk zijn. Dit is achterstallig. Spring hier alsjeblieft op.'

En dan, voor het geval je niet besefte dat dat satire was, mensen, zegt hij, "Niet!"

---

EEND.  Ik krijg het idee dat het een goede herinnering is, en ik krijg het idee dat als je een GitHub-gebruiker bent, zowel als producent als als consument, er dingen zijn die je kunt doen.

We vermelden ze in de opmerkingen en in het artikel.

Zet bijvoorbeeld een digitale handtekening op al je commits, zodat het duidelijk is dat de wijzigingen van jou afkomstig zijn, en er is een soort van traceerbaarheid.

En consumeer niet blindelings dingen omdat je hebt gezocht en het "leek alsof" het misschien het juiste project zou zijn.

Ja, we kunnen hier allemaal van leren, maar telt dit eigenlijk als lesgeven, of is dat gewoon iets dat we toch zouden moeten leren?

Ik denk dat dit *geen* onderwijs is.

Het is gewoon *niet van een hoog genoeg niveau* om als onderzoek te tellen.

---

DOUG.  Geweldige discussie rond dit artikel, en bedankt voor het insturen, Rob.

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

U kunt ons mailen op tips@sophos.com; je kunt reageren op een van onze artikelen; of je 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 die je eraan herinnert, tot de volgende keer, om...

---

BEIDE.  Blijf veilig!

[MUZIEK MODEM]