Geen audiospeler hieronder? Luisteren direct op Soundcloud.

DOUG.  Cracks voor wachtwoordbeheer, login-bugs en Queen Elizabeth I versus Mary Queen of Scots... natuurlijk!

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

[MUZIEK MODEM]

Welkom bij de podcast, allemaal.

Ik ben Doug Aamoth; hij is Paul Ducklin.

Paulus, hoe gaat het met je?

EEND.  Wow!

16e-eeuwse informatietechnologie-bedrog ontmoet de Naked Security-podcast, Douglas.

Ik kan niet wachten!

DOUG.  Natuurlijk, ja… daar komen we zo op terug.

Maar eerst, zoals altijd, deze week in de technische geschiedenis, op 28 mei 1987, bracht onlineserviceprovider CompuServe iets uit dat het Graphics Interchange Format of GIF [HARD G] wordt genoemd.

Het werd ontwikkeld door wijlen Steve Wilhite, een ingenieur bij CompuServe (die trouwens op en neer zwoer dat het werd uitgesproken als "jif") als een middel om kleurenafbeeldingen te ondersteunen op de beperkte bandbreedte en opslagcapaciteit van vroege computernetwerken.

De eerste versie, GIF 87a, ondersteunde maximaal 256 kleuren; het werd snel populair vanwege het vermogen om eenvoudige animaties weer te geven en de brede ondersteuning op verschillende computersystemen.

Dank u, meneer Wilhite.

EEND.  En wat heeft het ons nagelaten, Douglas?

Webanimaties en controverse over de vraag of het woord wordt uitgesproken als "graphics" [HARD G] of "giraffics" [SOFT G].

DOUG.  Precies. [LACHT]

EEND.  Ik kan het gewoon niet "giff" [HARD G] noemen.

DOUG.  Dezelfde!

Laten we dat afstempelen en verder gaan met ons spannende verhaal...

… over koningin Elizabeth I, Mary Queen of Scots en een man beide kanten spelen tussen ransomware-boeven en zijn werkgever, Paul.

Verhalen over ransomware: de MitM-aanval die echt een man in het midden had

EEND.  [LACHT] Laten we beginnen bij het einde van het verhaal.

In feite was het een ransomware-aanval op een technologiebedrijf in Oxfordshire, Engeland.

(Deze niet... het was een bedrijf in Oxford, 15 km stroomopwaarts van Abingdon-on-Thames, waar Sophos is gevestigd.)

Nadat ze waren getroffen door ransomware, kregen ze, zoals je je kunt voorstellen, een eis om Bitcoin te betalen om hun gegevens terug te krijgen.

En, zoals dat verhaal hadden we een paar weken geleden, een van hun eigen verdedigingsteam, die verondersteld werd te helpen hiermee om te gaan, bedacht: "Ik ga een MiTM uitvoeren", een man-in-the-middle-aanval.

Ik weet dat, om gendergerelateerde taal te vermijden en om te laten zien dat het tegenwoordig niet altijd een persoon is (het is vaak een computer in het midden)...

…over Naked Security schrijf ik nu “Manipulator-in-the-Middle”.

Maar dit was letterlijk een man in het midden.

Simpel gezegd, Doug, hij slaagde erin om zijn werkgever vanuit huis te e-mailen, met behulp van een soort typosquat-e-mailaccount dat leek op het e-mailadres van de boef.

Hij kaapte de thread en veranderde het Bitcoin-adres in de historische e-mailsporen, omdat hij toegang had tot de e-mailaccounts van senior executives...

... en hij begon in feite te onderhandelen als een man-in-the-middle.

Dus stel je voor dat hij nu individueel onderhandelt met de boef, en dan geeft hij die onderhandelingen door aan zijn werkgever.

We weten niet of hij hoopte er met alle premie vandoor te gaan en dan gewoon tegen zijn werkgever te zeggen: "Hé, raad eens, de boeven hebben ons bedrogen", of dat hij wilde onderhandelen over de boeven aan zijn kant, en zijn werkgever aan de andere kant.

Omdat hij alle goede en foute dingen wist om te zeggen om de angst en terreur binnen het bedrijf te vergroten.

Zijn doel was dus eigenlijk om de ransomware-betaling te kapen.

Nou, Doug, het liep allemaal een beetje in de soep omdat, helaas voor hem en gelukkig voor zijn werkgever en voor de politie, het bedrijf besloot niet te betalen.

DOUG.  [LACHT] Hmmmm!

EEND.  Er was dus geen Bitcoin voor hem om te stelen en vervolgens uit te voeren.

Het lijkt er ook op dat hij zijn sporen niet goed heeft verborgen, en zijn onwettige toegang tot de e-maillogboeken kwam toen in de was.

Hij wist duidelijk dat de politie hem naderde, want hij probeerde de malafide gegevens thuis van zijn eigen computers en telefoons te wissen.

Maar ze werden in beslag genomen en de gegevens werden teruggevonden.

Op de een of andere manier sleepte de zaak zich vijf jaar voort, en uiteindelijk, net toen hij op het punt stond voor de rechter te verschijnen, besloot hij duidelijk dat hij niet echt een poot had om op te staan ​​en pleitte hij schuldig.

Dus daar heb je het, Doug.

Een letterlijke man-in-the-middle-aanval!

DOUG.  OK, dus dat is allemaal goed en wel in 2023…

…maar neem ons terug naar de jaren 1580, Paulus.

Hoe zit het met Mary, Queen of Scots en Queen Elizabeth I?

EEND.  Om eerlijk te zijn, dacht ik dat dat een goede manier was om een ​​man-in-the-middle-aanval uit te leggen door al die jaren terug te gaan.

Omdat koningin Elizabeth en haar nicht Mary, Queen of Scots, zoals bekend, religieuze en politieke vijanden waren.

Elizabeth was de koningin van Engeland; Mary was troonpretendent.

Mary werd dus effectief vastgehouden onder huisarrest.

Mary leefde in een of andere luxe, maar was opgesloten in een kasteel, en smeedde eigenlijk een complot tegen haar neef, maar ze konden het niet bewijzen.

En Mary stuurde en ontving berichten die in de stoppen van biervaten waren gestopt die bij het kasteel waren afgeleverd.

Blijkbaar was de man-in-the-middle in dit geval een volgzame bierleverancier die de berichten zou verwijderen voordat Mary ze kreeg, zodat ze konden worden gekopieerd.

En hij zou vervangende berichten invoegen, versleuteld met Mary's cijfer, met subtiele veranderingen die, losjes gesproken, Mary uiteindelijk overhaalden om meer op te schrijven dan ze waarschijnlijk had moeten doen.

Zo gaf ze niet alleen de namen van andere samenzweerders prijs, ze gaf ook te kennen het complot om koningin Elizabeth te vermoorden goed te keuren.

Het waren toen zwaardere tijden... en Engeland had in die tijd zeker de doodstraf, en Mary werd berecht en geëxecuteerd.

De top 10 gekraakte cijferteksten uit de geschiedenis

DOUG.  OK, dus voor iedereen die luistert, de elevator pitch voor deze podcast is: "Cybersecurity-nieuws en -advies, en een beetje geschiedenis".

Terug naar onze man-in-the-middle in de huidige tijd.

We spraken over nog een bedreiging van binnenuit net als dit nog niet zo lang geleden.

Dus het zou interessant zijn om te zien of dit een patroon is, of dat dit gewoon toeval is.

Maar we hebben het gehad over enkele dingen die u kunt doen om uzelf tegen dit soort aanvallen te beschermen, dus laten we die nog eens snel doornemen.

Beginnend met: Verdeel en heers, wat in feite betekent: "Geef niet één persoon in het bedrijf onbeperkte toegang tot alles", Paul.

EEND.  Ja.

DOUG.  En dan hebben we: Houd onveranderlijke logboeken bij, wat in dit geval leek te zijn gebeurd, toch?

EEND.  Ja.

Het lijkt erop dat een belangrijk bewijselement in deze zaak het feit was dat hij in de e-mails van senior executives had zitten graven en ze had gewijzigd, en hij kon dat niet verbergen.

Dus stel je voor, zelfs zonder het andere bewijs, dat het extra verdacht zou zijn dat hij aan het knoeien was met e-mails die specifiek betrekking hadden op ransomware-onderhandelingen en Bitcoin-adressen.

DOUG.  Oké, eindelijk: Altijd meten, nooit aannemen.

EEND.  Inderdaad!

DOUG.  De goeden wonnen uiteindelijk... het duurde vijf jaar, maar het is ons gelukt.

Laten we verder gaan met ons volgende verhaal.

Webbeveiligingsbedrijf vindt een inlogfout in een toolkit voor het bouwen van apps.

De bug is snel en transparant opgelost, dus dat is fijn... maar er is een beetje meer naar het verhaal, natuurlijk, Paulus.

Serieuze beveiliging: Verificatie is van vitaal belang - het onderzoeken van een OAUTH-inlogfout

EEND.  Ja.

Dit is een bedrijf voor webcoderingsbeveiligingsanalyse (ik hoop dat ik daar de juiste terminologie heb gekozen) genaamd SALT, en ze vonden een authenticatie-kwetsbaarheid in een toolkit voor het bouwen van apps genaamd Expo.

En, zegen hun harten, Expo ondersteunt iets dat OAUTH heet, de Autorisatie openen systeem.

Dat is het soort systeem dat wordt gebruikt als je naar een website gaat die heeft besloten: “Weet je wat, we willen niet het gedoe om te leren hoe we wachtwoordbeveiliging voor onszelf kunnen doen. Wat we gaan doen is zeggen: 'Log in met Google, log in met Facebook',' zoiets.

En het idee is dat je, losjes gesproken, contact opneemt met Facebook, of Google, of wat de reguliere service ook is en je zegt: "Hé, ik wil example.com toestemming om X te doen.”

Dus Facebook, of Google, of wat dan ook, authenticeert je en zegt dan: “OK, hier is een magische code die je aan de andere kant van de lijn kunt geven die zegt: 'We hebben je uitgecheckt; je hebt je bij ons geauthenticeerd en dit is je authenticatietoken.”

Vervolgens kan het andere uiteinde onafhankelijk controleren bij Facebook of Google of wat dan ook om er zeker van te zijn dat dat token namens u is uitgegeven.

Dus wat dat betekent is dat je nooit een wachtwoord aan de site hoeft te overhandigen... je bent, als je wilt, co-opteert Facebook of Google om het daadwerkelijke authenticatiegedeelte voor je te doen.

Het is een geweldig idee als je een boetiekwebsite bent en je denkt: "Ik ga mijn eigen cryptografie niet breien."

Dit is dus geen bug in OAUTH.

Het is gewoon een vergissing; iets dat vergeten was bij de implementatie van het OAUTH-proces door Expo.

En losjes gesproken, Doug, gaat het zo.

De Expo-code creëert een gigantische URL die alle parameters bevat die nodig zijn voor authenticatie met Facebook en vervolgens beslissen waar dat laatste magische toegangstoken naartoe moet worden gestuurd.

Daarom, in theorie, als je je eigen URL hebt gemaakt of als je de URL zou kunnen wijzigen, zou je de plaats kunnen veranderen waar dit magische authenticatietoken uiteindelijk naartoe is gestuurd.

Maar je zou de gebruiker niet kunnen misleiden, omdat er een dialoogvenster verschijnt dat zegt: “De app op URL-here vraagt ​​je om in te loggen op je Facebook-account. Vertrouw je dit volledig en wil je het zo laten? Ja of nee?"

Als het er echter op aan kwam om de autorisatiecode van Facebook, of Google, of wat dan ook, te ontvangen en door te geven aan deze "retour-URL", zou de Expo-code niet controleren of u daadwerkelijk had geklikt Yes in het goedkeuringsvenster.

Als je het dialoogvenster actief hebt gezien en hebt geklikt No, dan zou je voorkomen dat de aanval plaatsvindt.

Maar in wezen is dit "mislukt open".

Als je de dialoog nooit hebt gezien, dus je zou niet eens weten dat er iets was om op te klikken en je deed gewoon niets, en dan activeerden de aanvallers zelf het volgende URL-bezoek met meer JavaScript...

…dan zou het systeem werken.

En de reden dat het werkte, is dat de magische "retour-URL", de plaats waar de supergeheime autorisatiecode naartoe moest worden gestuurd, was ingesteld in een webcookie die Expo later zou gebruiken * voordat u klikte Yes op het dialoogvenster*.

Later werd het bestaan ​​van die "retour-URL"-cookie in wezen genomen, zo u wilt, als bewijs dat u de dialoog moet hebben gezien en dat u moet hebben besloten om door te gaan.

Terwijl dat in feite niet het geval was.

Dus het was een enorme slip tussen cup en lip, Douglas.

DOUG.  OK, we hebben enkele tips, te beginnen met: Als het ging om het rapporteren en onthullen van deze bug, was dit een schoolvoorbeeld.

Dit is bijna precies hoe je het zou moeten doen, Paul.

Alles werkte gewoon zoals het hoort, dus dit is een goed voorbeeld van hoe je dit op de best mogelijke manier kunt doen.

EEND.  En dat is een van de belangrijkste redenen waarom ik het over Naked Security wilde schrijven.

SALT, de mensen die de bug hebben gevonden...

..ze hebben het gevonden; ze hebben het op verantwoorde wijze bekendgemaakt; ze werkten samen met Expo, die het letterlijk binnen enkele uren repareerde.

Dus ook al was het een bug, ook al was het een codeerfout, het leidde ertoe dat SALT zei: "Weet je wat, de Expo-mensen waren een absoluut genot om mee te werken."

Vervolgens ging SALT op zoek naar een CVE, en in plaats van te zeggen: "Hé, de bug is nu verholpen, dus twee dagen later kunnen we er een grote PR-spetter van maken", stelden ze niettemin een datum vast van drie maanden vooruit waarop ze daadwerkelijk zouden schrijven hun bevindingen op en schrijven hun zeer leerzame rapport.

In plaats van het naar buiten te brengen voor onmiddellijke PR-doeleinden, voor het geval ze op het laatste moment werden gepikt, rapporteerden ze dit niet alleen op verantwoorde wijze zodat het kon worden verholpen voordat boeven het vonden (en er is geen bewijs dat iemand deze kwetsbaarheid had misbruikt), ze gaf Expo wat speelruimte om eropuit te gaan en met hun klanten te communiceren.

DOUG.  En dan hebben we het natuurlijk even hierover gehad: Zorg ervoor dat uw authenticatiecontroles niet worden afgesloten.

Zorg ervoor dat het niet gewoon blijft werken als iemand het negeert of annuleert.

Maar het grotere probleem hier is: Ga er nooit vanuit dat uw eigen client-side code het verificatieproces zal beheersen.

EEND.  Als je het exacte proces van de JavaScript-code van Expo hebt gevolgd om je door dit OAUTH-proces te leiden, zou het goed zijn gegaan.

Maar als je hun code hebt vermeden en eigenlijk gewoon de links met je eigen JavaScript hebt geactiveerd, inclusief het omzeilen of annuleren van de pop-up, dan heb je gewonnen.

Het omzeilen van uw clientcode is het eerste waar een aanvaller aan gaat denken.

DOUG.  Oké, last but not least: Meld u af bij webaccounts wanneer u deze niet actief gebruikt.

Dat is overal een goed advies.

EEND.  We zeggen het de hele tijd op de Naked Security-podcast, en dat hebben we gedaan vele jaren.

3 eenvoudige stappen naar online veiligheid

Het is een impopulair advies, omdat het nogal onhandig is, op dezelfde manier als tegen mensen zeggen: "Hé, waarom zou je je browser niet instellen om alle cookies te wissen bij het afsluiten?"

Als je erover nadenkt, in dit specifieke geval... laten we zeggen dat het inloggen gebeurde via je Facebook-account; OAUTH via Facebook.

Als je was uitgelogd bij Facebook, dan zou het authenticatieproces met Facebook niet slagen, ongeacht welk JavaScript-verraad een aanvaller probeerde (het doden van de Expo-pop-up en al dat soort dingen), omdat Facebook zou zeggen: "Hé, deze persoon is mij vragen om ze te authenticeren. Ze zijn momenteel niet ingelogd.”

Dus je zou op dat moment altijd en onvermijdelijk de Facebook-login zien verschijnen: "Je moet nu inloggen."

En dat zou de uitvlucht meteen verraden.

DOUG.  Oke, heel goed.

En ons laatste verhaal van de dag: geen paniek, maar er is blijkbaar een manier om het hoofdwachtwoord voor open-source wachtwoordbeheerder KeePass te kraken.

Maar nogmaals, geen paniek, want het is een stuk ingewikkelder dan het lijkt, Paul.

Je moet echt controle hebben over iemands machine.

Serieuze beveiliging: dat KeePass "hoofdwachtwoord kraken", en wat we ervan kunnen leren

EEND.  Je doet.

Als je dit wilt opsporen, is het CVE-2023-32784.

Het is een fascinerende bug, en ik schreef een soort van magnum opus stijlartikel op Naked Security erover, getiteld: Die KeePass 'master password crack' en wat we ervan kunnen leren.

Dus ik zal dat artikel niet bederven, dat gaat over geheugentoewijzing van het C-type, geheugentoewijzing van het scripttaaltype en ten slotte door C # of .NET beheerde tekenreeksen ... beheerde geheugentoewijzing door het systeem.

Ik zal alleen beschrijven wat de onderzoeker in dit geval ontdekte.

Wat ze deden is... ze gingen op zoek in de KeePass-code en in KeePass-geheugendumps, naar bewijs van hoe gemakkelijk het zou kunnen zijn om het hoofdwachtwoord in het geheugen te vinden, zij het tijdelijk.

Wat als het er minuten, uren of dagen later is?

Wat als het hoofdwachtwoord nog steeds rondslingert, misschien in uw wisselbestand op schijf, zelfs nadat u uw computer opnieuw hebt opgestart?

Dus ik heb KeePass ingesteld en mezelf een wachtwoord van 16 tekens gegeven, volledig in hoofdletters, zodat het gemakkelijk te herkennen zou zijn als ik het in het geheugen zou vinden.

En zie, op geen enkel moment heb ik ooit mijn hoofdwachtwoord in het geheugen gevonden: niet als een ASCII-reeks; niet als een Windows widechar (UTF-16) tekenreeks.

Geweldig!

Maar wat deze onderzoeker opmerkte, is dat wanneer je je wachtwoord in KeePass typt, het verschijnt... Ik zal het "het Unicode-blobkarakter" noemen, gewoon om je te laten zien dat je inderdaad op een toets hebt gedrukt, en daarom om je te laten zien hoeveel tekens je hebt ingevoerd.

Dus terwijl u uw wachtwoord typt, ziet u de tekenreeks blob [●], blob-blob [●●], blob-blob-blob [●●●] en in mijn geval alles tot 16 blobs.

Welnu, die blob-strings lijken geen veiligheidsrisico te vormen, dus misschien werden ze gewoon aan de .NET-runtime overgelaten om te beheren als "beheerde strings", waar ze daarna in het geheugen zouden kunnen rondslingeren...

...en niet worden opgeruimd omdat: "Hé, het zijn maar klodders."

Het blijkt dat als je een geheugendump van KeePass doet, wat je maar liefst 250 MB aan dingen geeft, en je gaat op zoek naar strings zoals blob-blob, blob-blob-blob, enzovoort (een willekeurig aantal blobs), er is een stuk geheugendump waar je twee blobs ziet, dan drie blobs, dan vier blobs, dan vijf blobs... en in mijn geval helemaal tot 16 blobs.

En dan krijg je gewoon deze willekeurige verzameling "blobkarakters die per ongeluk gebeuren", als je wilt.

Met andere woorden, alleen al het zoeken naar die blob-strings, ook al geven ze je werkelijke wachtwoord niet prijs, lekt de lengte van je wachtwoord.

Het wordt echter nog interessanter, want wat deze onderzoeker zich afvroeg is: "Wat als de gegevens in de buurt van die blobstrings in het geheugen op de een of andere manier kunnen worden gekoppeld aan de individuele tekens die u in het wachtwoord typt?"

Dus, wat als je door het geheugendumpbestand gaat en in plaats van alleen maar te zoeken naar twee blobs, drie blobs/vier blobs, meer...

…je zoekt naar een reeks blobs gevolgd door een teken waarvan je denkt dat het in het wachtwoord staat?

Dus in mijn geval was ik gewoon op zoek naar de karakters A tot Z, omdat ik wist dat dat in het wachtwoord stond.

Ik zoek naar een reeks blobs, gevolgd door één ASCII-teken.

Raad eens wat er is gebeurd, Doug?

Ik krijg twee blobs gevolgd door het derde teken van mijn wachtwoord; drie blobs gevolgd door het vierde teken van mijn wachtwoord; helemaal tot 15 blobs onmiddellijk gevolgd door het 16e teken in mijn wachtwoord.

DOUG.  Ja, het is een wild beeld in dit artikel!

Ik volgde mee ... het werd een beetje technisch, en ineens zie ik gewoon: "Ho! Dat lijkt op een wachtwoord!”

EEND.  Het is eigenlijk alsof de individuele tekens van uw wachtwoord royaal door het geheugen zijn verspreid, maar degenen die de ASCII-tekens vertegenwoordigen die eigenlijk deel uitmaakten van uw wachtwoord terwijl u het typte...

... het is alsof er een lichtgevende dobbelsteen aan vast zit.

Deze reeksen blobs fungeren dus onbedoeld als een tagmechanisme om de tekens in uw wachtwoord te markeren.

En, echt, de moraal van het verhaal is dat dingen uit het geheugen kunnen lekken op manieren die je gewoon nooit had verwacht, en die zelfs een goed geïnformeerde code-recensent misschien niet opmerkt.

Het is dus fascinerend om te lezen en het herinnert ons er goed aan dat het schrijven van veilige code veel moeilijker kan zijn dan u denkt.

En wat nog belangrijker is, het beoordelen, kwaliteitsborgen en testen van veilige code kan nog moeilijker zijn...

...omdat je ogen aan de voorkant, de achterkant en de zijkanten van je hoofd moet hebben, en je moet echt denken als een aanvaller en absoluut overal proberen te zoeken naar lekkende geheimen.

DOUG.  alright, check it out, het staat op makedsecurity.sophos.com.

En terwijl de zon ondergaat in onze show, is het tijd om iets van een van onze lezers te horen.

Op de vorige podcast (dit is een van mijn favoriete opmerkingen tot nu toe, Paul), zegt Naked Security-luisteraar Chang:

Daar. Ik heb het gedaan. Na bijna twee jaar binge-luisteren, luisterde ik naar alle afleveringen van de Naked Security-podcast. Ik ben helemaal ingehaald.

Ik heb er vanaf het begin van genoten, te beginnen met de langlopende Chet Chat; vervolgens naar de Britse bemanning; "Oh nee! Het is Kim” was de volgende; toen bereikte ik eindelijk "This Week in Tech History" van vandaag.

Wat een lach!

Bedankt, Chang!

Ik kan niet geloven dat je alle afleveringen hebt gebinged, maar we waarderen het allemaal (ik hoop dat ik niet voor onze beurt spreek).

EEND.  Heel erg inderdaad, Doug!

Het is leuk om niet alleen te weten dat mensen luisteren, maar ook dat ze de podcasts nuttig vinden, en dat het hen helpt meer te leren over cyberbeveiliging en hun spel te verbeteren, ook al is het maar een klein beetje.

Omdat ik denk, zoals ik al zo vaak heb gezegd, als we allemaal een heel klein beetje meer doen aan cyberbeveiliging, we veel meer doen om de boeven op afstand te houden dan wanneer een of twee bedrijven, een of twee organisaties, een of twee individuen hebben enorm veel moeite gedaan, maar de rest van ons blijft achter.

DOUG.  Precies!

Nou, nogmaals heel erg bedankt, Chang, voor het insturen.

We stellen het zeer op prijs.

En als je een interessant verhaal, opmerking of vraag hebt die je wilt insturen, lezen we die graag in de podcast.

Je kunt een e-mail sturen naar tips@sophos.com, 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, ik herinner je eraan, tot de volgende keer, om...

BEIDE.  Blijf veilig!

[MUZIEK MODEM]