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

DOUG.   Bustes, shutdowns, Samba en GitHub.

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

[MUZIEK MODEM]

Welkom bij de podcast, allemaal.

Ik ben Doug Aamoth; hij is Paul Ducklin.

Paul, hoe gaat het vandaag, meneer?

EEND.   Het gaat heel goed met me, Douglas.

DOUG.   Laten we de show beginnen met onze Technische geschiedenis segment - dit is een interessante.

Deze week, op 01 februari 1982, werd de Intel 80286 16-bits microprocessor geïntroduceerd, die jarenlang een steunpilaar werd in IBM PC/AT-computers.

Interessant is dat Intel niet verwachtte dat de 286 zou worden gebruikt voor personal computers, en een chip ontwierp met multitasking en systemen voor meerdere gebruikers in gedachten.

EEND.   Het primaire gebruik, zoals u zegt, was de PC/AT, de "Advanced Technology"-computer van IBM, die in wezen was ontworpen om DOS uit te voeren.

Hoewel DOS beperkt is tot 1 MB RAM (of 640 KB RAM en de rest ROM), zou je extra geheugen kunnen hebben, en je zou het kunnen gebruiken voor zaken als...

…herinneren HIMEM.SYS, en RAM-caches, al dat soort dingen?

Behalve dat omdat Intel veiligheid in gedachten had, zegen hun harten, toen ze de 286 ontwierpen...

...als je eenmaal was overgeschakeld van de modus waarin het als een 8086 liep naar de superkrachtige zogenaamde "beschermde modus", *kon je niet meer terugschakelen*.

Zodra je naar de modus bent gegaan waarmee je toegang hebt tot je HIMEM of uw RAMDISK, je zat vast.

Je kon niet teruggaan en DOS blijven draaien!

En IBM heeft hun pc eigenlijk door een jury opgetuigd - je stuurde dit speciale commando naar (geloof het of niet) de toetsenbordcontroller, en de toetsenbordcontroller startte in feite de CPU opnieuw op.

Toen de CPU weer opstartte, zei het BIOS: "Oh, dat is geen echte herstart, dat is een stiekeme 'illegaal terugschakelen naar echte modus'-herstart," [GELACH] en het ging terug naar waar je was in DOS.

Het probleem is dus dat het superinefficiënt was.

Het andere met de 286, ook al had hij in totaal toegang tot 16 MB RAM, is dat hij, net als de 8086, maar met maximaal 64 KB tegelijk kon werken.

Dus de limiet van 64 kilobyte was nog steeds in wezen verankerd in het DNA van die 286 microprocessor.

Het was majestueus en nodeloos ingewikkeld, zo bleek.

Het is een soort product dat supercool was, maar op dat moment helaas niet echt voldeed aan een behoefte in de markt.

DOUG.   Nou, laten we beginnen met onze eerste verhalen.

We hebben een two-pack – het is tijd voor misdaad.

Laten we het hebben over shutdowns en lock-ups, te beginnen met de sluiting van de FBI Hive ransomware-servers eindelijk.

Dat is goed nieuws!

Hive ransomware-servers zijn eindelijk afgesloten, zegt de FBI

EEND.   Het lijkt er wel op, nietwaar, Doug?

Hoewel we, zoals we altijd doen, in wezen moeten zeggen dat "cybercriminaliteit een vacuüm verafschuwt".

Helaas komen andere operators binnen als er een lot wordt gepakt ...

…of als het enige dat gebeurt, is dat hun servers worden uitgeschakeld, en de feitelijke mensen die ze bedienen niet worden geïdentificeerd en gearresteerd, wat er meestal gebeurt, is dat ze hun hoofd een tijdje onder de borstwering houden, en dan duiken ze gewoon op ergens anders.

Soms vinden ze het oude merk opnieuw uit, gewoon om hun neus op de wereld te drukken.

Soms kwamen ze terug met een nieuwe naam.

Dus het probleem met Hive: het blijkt dat de FBI de Hive-ransomwarebende had geïnfiltreerd, vermoedelijk door het account van een systeembeheerder over te nemen, en dat gebeurde blijkbaar halverwege 2022.

Maar, zoals we al eerder op de podcast hebben gezegd, met het dark web, het feit dat je iemands account hebt en je kunt inloggen als diegene...

… je kunt nog steeds niet zomaar het IP-nummer opzoeken van de server waarmee je verbinding maakt, omdat het dark web dat verbergt.

Het lijkt er dus op dat de FBI tijdens het eerste deel van deze operatie niet echt kon identificeren waar de servers waren, hoewel ze blijkbaar in staat waren om gratis decoderingssleutels te krijgen voor een behoorlijk aantal mensen – ik denk enkele honderden slachtoffers.

Dat was dus best goed nieuws!

En dan, of het een blunder van de operationele inlichtingen was, of ze gewoon geluk hadden, of... we weten het niet, maar het lijkt erop dat ze er uiteindelijk achter kwamen waar de servers waren, en bingo!

Stilgelegd!

DOUG.   Oke, heel goed.

En dan ons tweede van deze misdaadverhalen.

We hebben een Nederlander verdachte in voorarrest, beschuldigd van niet alleen diefstal van persoonlijke gegevens, maar [DOOM-LADEN STEM] "megadiefstal", zoals u het uitdrukte. Paulus:

Nederlandse verdachte opgesloten voor vermeende megadiefstallen van persoonsgegevens

EEND.   Ja!

Het lijkt erop dat zijn "taak" was ... hij vindt gegevens, of koopt gegevens van andere mensen, of breekt in op sites en steelt zelf enorme hoeveelheden gegevens.

Vervolgens snijdt en dobbelt hij het op verschillende manieren en biedt het te koop aan op het dark web.

Hij werd betrapt omdat het bedrijf dat tv-licenties regelt in Oostenrijk (veel Europese landen vereisen dat je een vergunning hebt om een ​​tv-toestel te bezitten en te exploiteren, waarmee in wezen de nationale televisie wordt gefinancierd)... die databases hebben vrijwel elk huishouden, minus een weinig.

De Oostenrijkse autoriteiten kwamen erachter dat er een database te koop was op het dark web die erg leek op het soort gegevens dat je zou krijgen - de velden en de manier waarop alles was opgemaakt... "Dat lijkt op de onze, dat lijkt op Oostenrijkse tv-licenties. Mijn God!"

Dus ze deden iets heel cools, Doug.

Ze deden een undercover terugkoop, en terwijl ze dat deden, kregen ze een goed beeld van waar de persoon was: "Het lijkt erop dat deze persoon zich waarschijnlijk in Amsterdam bevindt, in Nederland."

En dus kwamen ze in contact met hun kameraden bij de Nederlandse politie, en de Nederlanders waren in staat om huiszoekingsbevelen te krijgen en meer te weten te komen, en wat invallen te doen, en iemand te arresteren voor deze misdaad.

Misschien ongebruikelijk, ze kregen in wezen het recht van de rechtbank om de man incommunicado te houden - het was allemaal geheim.

Hij zat gewoon opgesloten, kreeg geen borgtocht – sterker nog, ze hebben nog een paar maanden, denk ik, om hem vast te houden.

Hij komt er dus niet uit.

Ik neem aan dat ze bang zijn dat [A] hij heel veel cryptocurrency heeft liggen, dus hij zou waarschijnlijk een hardloper doen, en [B] hij zou waarschijnlijk al zijn kameraden in de cyberonderwereld een fooi geven.

Het leek er ook op dat hij er veel geld mee verdiende, want hij wordt ook beschuldigd van het witwassen van geld – de Nederlandse politie beweert bewijs te hebben dat hij vorig jaar persoonlijk ergens in de buurt van een half miljoen euro aan cryptocoins heeft uitbetaald .

Dus daar ben je!

Weer een hoop gekkigheid in een onderzoek.

DOUG.   Ja inderdaad.

OK, dit is een klassieker “Dat houden we in de gaten!” soort verhaal.

In de tussentijd hebben we een Samba-aanmeldingsbug die ons eraan herinnert waarom cryptografische behendigheid is zo belangrijk:

Serieuze beveiliging: de Samba-aanmeldingsbug veroorzaakt door verouderde cryptovaluta

EEND.   Het is een herinnering dat wanneer de cryptografische goeroes van de wereld zeggen: "XYZ-algoritme is niet langer geschikt voor het doel, stop er alsjeblieft mee", en het jaar is - laten we zeggen - het midden van de jaren 2000 ...

…het is de moeite waard om te luisteren!

Zorg ervoor dat er geen verouderde code is die aansleept, omdat je denkt: "Niemand zal het gebruiken."

Dit is een aanmeldingsproces in Microsoft Windows-netwerken dat afhankelijk is van het MD5-hashing-algoritme.

En het probleem met het MD5-hash-algoritme is dat het veel te gemakkelijk is om twee bestanden te maken die exact dezelfde hash hebben.

Dat mag niet gebeuren!

Voor mij om twee afzonderlijke ingangen te krijgen die precies dezelfde hash hebben, zou me, op mijn laptop, ongeveer 10,000 jaar moeten kosten ...

DOUG.   Ongeveer! [LACHT]

EEND.   Min of meer.

Alleen al voor dat artikel heb ik met behulp van tools die door een Nederlandse cryptograaf zijn ontwikkeld voor zijn masterscriptie in 2007 *tien* botsende MD5-hash-paarbestanden gemaakt...

…in maximaal 14 seconden (voor een van hen) en minimaal minder dan een halve seconde.

Dus miljarden keren sneller dan mogelijk zou moeten zijn.

U kunt er dus absoluut zeker van zijn dat het MD5-hash-algoritme *gewoon zijn belofte niet waarmaakt*.

Dat is de kern van deze bug.

Kortom, midden in het authenticatieproces is er een onderdeel dat zegt: “Weet je wat, we gaan dit superveilige authenticatietoken maken op basis van gegevens die door de gebruiker zijn aangeleverd en met behulp van een geheime sleutel die door de gebruiker is verstrekt. Dus wat we gaan doen, is dat we eerst een MD5-hash van de gegevens maken om het lekker kort te houden, en dan maken we de authenticatiecode * op basis van die 128-bits hash.

In theorie kun je, als je een aanvaller bent, alternatieve invoergegevens maken *die dezelfde authenticatie-hash* opleveren.

En dat betekent dat u de andere kant kunt overtuigen: "Ja, ik *moet* de geheime sleutel weten, hoe zou ik anders de juiste authenticatiecode kunnen maken?"

Het antwoord is: je speelt vals in het midden van het proces, door gegevens in te voeren die toevallig dezelfde hash opleveren, waarop de authenticatiecode is gebaseerd.

Het MD5-algoritme is jaren geleden gestorven, maar het leeft voort – en dat zou niet moeten!

Dus de oplossing is eenvoudig.

Samba zei zojuist: “Wat we gaan doen, is dat als je dit oude algoritme wilt gebruiken, je vanaf nu door hoepels moet springen om het aan te zetten. En als dat dingen kapot maakt, en als je plotseling niet kunt inloggen op je eigen netwerk omdat je een zwakke beveiliging gebruikte zonder het te beseffen... dat is de prijs die we allemaal willen betalen.'

En daar ben ik het mee eens.

DOUG.   OK, het is versie 4.17.5 die deze twee opties nu afdwingt, dus ga erop uit en pak dat op als je dat nog niet hebt gedaan.

En als laatste, maar zeker niet als minste, hebben we certificaten voor codeondertekening gestolen van GitHub.

Maar er is hier gelukkig een zilveren voering:

GitHub-codeondertekeningscertificaten gestolen (maar worden deze week ingetrokken)

EEND.   Het zijn nogal wat maanden geweest voor cloudinbreuken en mogelijke aanvallen op de toeleveringsketen.

DOUG.   Serieus!

EEND.   "Oh jee, gestolen ondertekeningssleutels" ... GitHub realiseerde zich dat dit was gebeurd op 07 december 2022.

Petje af voor hen, beseften ze precies de dag nadat de boeven binnen waren gekomen.

Het probleem is dat ze niet waren begonnen met ronddwalen - het lijkt erop dat hun vermogen om binnen te komen gebaseerd was op het feit dat ze privé GitHub-repository's konden downloaden.

Dit is geen inbreuk op de GitHub-systemen, of de GitHub-infrastructuur, of hoe GitHub bestanden opslaat - het is gewoon dat GitHub's code op GitHub... sommige dingen die privé zouden moeten zijn, zijn gedownload.

En zoals we al eerder hebben besproken, het probleem wanneer broncode-opslagplaatsen die privé zouden moeten zijn, worden gedownload...

…het probleem is dat, verrassend vaak, die repositories dingen bevatten die je niet openbaar wilt maken.

Bijvoorbeeld wachtwoorden voor andere services.

En, belangrijker nog, de code-ondertekeningssleutels - je zegelring, die je gebruikt om je kleine zegel in de was te zetten van het programma dat je daadwerkelijk bouwt.

Zelfs als u een open source-project bent, gaat u uw code-ondertekeningssleutels niet in de openbare versie van de broncode plaatsen!

Dus dat was de angst van GitHub: “Oh jee. We vonden de boeven vrijwel onmiddellijk, maar ze kwamen binnen, ze grepen de code, ze gingen... dus de schade was al aangericht.'

Het kostte hen vrij veel tijd, bijna twee maanden, om erachter te komen wat ze hierover konden zeggen.

Of het duurde in ieder geval twee maanden voordat ze er iets van zeiden.

En het klinkt alsof de enige dingen die een effect kunnen hebben op klanten die wel zijn gestolen, inderdaad code-ondertekeningssleutels zijn.

Slechts twee projecten werden getroffen.

Een daarvan is de broncode-editor die bekend staat als "Atom", GitHub-atoom.

Dat werd in het leven van de meeste ontwikkelaars in feite vervangen door Visual Studio Code [LAUGHS], dus het hele project werd halverwege 2022 stopgezet en de laatste beveiligingsupdate was december 2022.

Dus je zou Atom waarschijnlijk toch niet moeten gebruiken.

En het goede nieuws is dat, omdat ze het niet meer zouden bouwen, de betrokken certificaten...

…de meeste zijn al verlopen.

En uiteindelijk ontdekte GitHub, denk ik, dat er slechts drie gestolen certificaten waren die nog geldig waren, met andere woorden, die boeven daadwerkelijk konden gebruiken om iets te ondertekenen.

En die drie certificaten waren allemaal versleuteld.

Een ervan verliep op 04 januari 2023 en het lijkt er niet op dat de boeven dat wachtwoord hebben gekraakt, omdat ik geen malware weet die met dat certificaat is ondertekend in de opening tussen de boeven die binnenkomen en het verlopen van het certificaat een maand later.

Er is een tweede certificaat dat verloopt op de dag dat we de podcast opnemen, woensdag 01 februari 2022; Ik weet ook niet dat die misbruikt is.

De enige uitbijter in dit alles is een code-ondertekeningscertificaat dat helaas pas in 2027 vervalt, en dat is voor het ondertekenen van Apple-programma's.

Dus GitHub heeft tegen Apple gezegd: "Pas op voor alles wat daarmee is ondertekend."

En vanaf 02 februari 2022 worden alle gestolen code-ondertekeningscertificaten (zelfs degenen die al zijn verlopen) ingetrokken.

Het lijkt er dus op dat dit een gevalletje is van 'eind goed al goed'.

Natuurlijk is er hier een klein neveneffect, en dat is dat als je de GitHub-bureaublad product, of als u het nog steeds gebruikt Atoom editor, dan trekt GitHub in wezen ondertekeningssleutels *voor hun eigen apps* in.

In het geval van de GitHub Desktop moet je absoluut upgraden, wat je sowieso zou moeten doen.

Ironisch genoeg, omdat Atom wordt stopgezet ... als je het dringend moet blijven gebruiken, moet je eigenlijk een beetje downgraden naar de meest recente versie van de app die is ondertekend met een certificaat dat niet zal worden ingetrokken.

Misschien heb ik dat ingewikkelder laten klinken dan het in werkelijkheid is...

... maar het ziet er slecht uit voor GitHub, omdat ze zijn geschonden.

Het is weer een slecht uiterlijk voor GitHub dat bij de inbreuk codeondertekeningscertificaten waren inbegrepen.

Maar het is een goede blik voor GitHub dat, door de manier waarop ze die certificaten beheerden. de meeste hadden geen nut meer.

Twee van de drie die gevaarlijk kunnen zijn, zijn verlopen tegen de tijd dat je naar deze podcast luistert, en de laatste, in jouw woorden, Doug, "ze houden echt een oogje in het zeil."

Ook hebben ze alle certificaten ingetrokken, ondanks het feit dat er een domino-effect is op hun eigen code.

Dus verloochenen ze in wezen hun eigen certificaten en sommige van hun eigen ondertekende programma's, voor het algemeen belang.

En dat vind ik goed!

DOUG.   Oké, goed gedaan door GitHub.

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

Nou, als je het je herinnert van vorige week, hebben we geprobeerd lezer Steven te helpen zijn eigen op USB-sleutel gebaseerde wachtwoordbeheerder te rollen.

Op basis van zijn dilemma vraagt ​​lezer Paul:

Waarom bewaart u uw wachtwoorden niet gewoon op een USB-stick met hardwarecodering en een toetsenbord… in een draagbare wachtwoordbeheerder zoals KeePass? Het is niet nodig om er zelf een uit te vinden, geef gewoon een paar dollar uit en bewaar ergens een back-up, bijvoorbeeld in een kluis.

EEND.   Helemaal geen slecht idee. Doug!

Ik was van plan om een ​​van die speciale USB-drives te kopen en uit te proberen... je krijgt die van een harde schijf (hoewel ze tegenwoordig over het algemeen SSD's hebben), waar er voldoende ruimte is voor een toetsenbord aan de bovenkant van de drive .

Maar je hebt zelfs USB-sticks, en die hebben meestal twee rijen van vijf sleutels of twee rijen van zes sleutels naast elkaar.

Het is niet zoals die gewone USB-drives die bijvoorbeeld "gratis coderingssoftware bevatten", die op de stick staat en die u vervolgens op uw computer kunt installeren.

Het idee is dat het lijkt op BitLocker of FileVault of LUKS, waar we het vorige week over hadden.

Er is een coderingslaag voor de volledige schijf *in de schijfbehuizing zelf*, en zodra je hem loskoppelt, zelfs als je hem niet correct ontkoppelt, als je hem gewoon uit de computer trekt...

... als de stroom uitvalt, wordt de sleutel uit het geheugen gewist en wordt het ding weer vergrendeld.

Ik denk dat de brandende vraag is: "Waarom gebruikt niet iedereen die gewoon als USB-sleutels, in plaats van gewone USB-apparaten?"

En er zijn twee redenen: de eerste is dat het een gedoe is, en het andere probleem is dat ze veel, veel duurder zijn dan gewone USB-sleutels.

Dus ik denk: "Ja, dat is een geweldig idee."

Het probleem is dat, omdat het geen reguliere producten zijn, ik er geen heb die ik kan aanbevelen - ik heb er nog nooit een geprobeerd.

En je kunt niet zomaar naar de gemiddelde pc-winkel gaan en er een kopen.

Dus als luisteraars een merk, of een type, of een bepaalde klasse van een dergelijk product hebben dat ze gebruiken en leuk vinden...

… we horen het graag, dus laat het ons weten!

DOUG.   OK, geweldig.. Ik hou van een beetje crowdsourcing, mensen die mensen helpen.

Heel erg bedankt, Paul, voor het insturen.

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, commentaar geven op een van onze artikelen of contact met ons opnemen op social media: @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]