LUISTER NU
Klik en sleep op de onderstaande geluidsgolven om naar een willekeurig punt te gaan. Je kan ook luister direct op Soundcloud.
Met Doug Aamoth en Paul Ducklin. Intro en outro muziek door Edith Mudge.
Je kunt naar ons luisteren op Soundcloud, Apple Podcasts, Google Podcasts, Spotify, stikster en overal waar goede podcasts te vinden zijn. Of laat de URL van onze RSS-feed in je favoriete podcatcher.
LEES DE TRANSCRIPT
DOUG AAMOT. JavaScript, NetUSB, Log4Shell, FTC...
Dat alles en meer: het is de podcast Naked Security.
[MUZIEK MODEM]
Welkom bij de podcast, allemaal.
Ik ben Paul; hij is Doug...
PAUL EENDJE. [LACHEND] Ik denk dat je daar een echte fout hebt gemaakt, nietwaar?
DOUG. Ik deed.
EEND. Het was eigenlijk geen grap.
DOUG. *Ik ben* Doug... Ik sta, zoals altijd, de eerste minuut van de show op de automatische piloot.
EEND. Welnu, we gaan het hebben over tal van softwarefouten ... het is gemakkelijk om dat soort fouten te maken.
DOUG. We hebben veel om over te praten, dus we gaan ermee aan de slag.
We hebben vandaag iets van een bliksemronde; veel verhalen om te dekken.
En zoals je weet beginnen we de show graag met een Leuk weetje: als je bijgelovig bent over vrijdag de dertiende, ben je niet de enige, tenzij je in Griekenland, Spanje of Italië woont.
Griekenland en Spanje beschouwen dinsdag de dertiende als de ongelukkigste dag; Italianen zijn op hun hoede voor Friday the Seventeeth; en Paul, zoals je weet, zullen we dit terugkoppelen in de Deze week in de technische geschiedenis segment later in de show.
EEND. Triskaidekafobie!
DOUG. Ik heb dat op een paar plaatsen geschreven zien staan, en ik ben blij dat je het hardop zegt, want het is bijna onmogelijk om te lezen als je het nog niet eerder hebt gehoord...
EEND. Τρισκαίδεκα… het is gewoon het Oudgriekse woord voor dertien, met het woord voor angst.
Dus eigenlijk is dat angst voor dertien, in plaats van per se alleen vrijdag de dertiende, maar ze gaan een beetje samen.
DOUG. Een dag waarop griezelige en vreemde dingen gebeuren.
En over spookachtig en vreemd gesproken, het verhaal van deze "JavaScript-ontwikkelaar" is wild!
EEND. Ik weet niet of het griezelig is, maar ja, het is vreemd. Misschien een beetje verdrietig.
DOUG. Dus wat is hier gebeurd?
EEND. Nou, het was wat je zou kunnen noemen een supply chain-aanval, waarbij mensen code die in JavaScript is geschreven in hun projecten zuigen - van NPM of GitHub, of waar ze het ook vandaan halen, van een open source-module die wordt gebruikt door heel veel verschillende projecten, uitgegeven onder de MIT Open Source-licentie.
U bent dus vrij om het te gebruiken, op voorwaarde dat u niet beweert dat het van u is - u kunt het zelfs in commerciële code gebruiken.
En de ontwikkelaar van twee van dergelijke projecten, faker.js en colors.js, besloot plotseling dat hij er genoeg van had.
Hij had een paar jaar geleden een indicatie gegeven dat hij het een beetje zat was om al dit werk te doen en niet betaald te krijgen...
...zoals de beroemde XKCD-cartoon, Doug.
DOUG. [LACH]
EEND. "Alles wordt ondersteund door dit dunne, kleine programmapilaartje, sinds 2003 onvermoeibaar onderhouden door een willekeurig persoon in Nebraska" - *die* XKCD-cartoon.
DOUG. Ja.
EEND. Deze man besloot duidelijk: "Nou, ik heb er genoeg van."
Dus voor faker.js trok hij eigenlijk gewoon de stekker uit het hele ding - hij verwijderde alle broncode.
Hij heeft, als je wilt, een definitieve versie van het project gemaakt zonder broncode; het heeft de opmerking "Eindspel"; en er staat gewoon in de README: "Wat is er met Aaron Schwartz gebeurd?"
Hij was de beroemde hacktivist die zeer droevig zelfmoord pleegde nadat hij was gearresteerd omdat hij een hele lading dossiers had meegenomen - academische papers die volgens hem niet achter een firewall mochten staan, maar de wet dacht daar anders over.
Dus dat deed hij met deze faker.js
En hoewel het een rare naam is voor een programma, was het eigenlijk heel handig om te hebben omdat het nepgegevens voor je creëert.
Je sprak daarover in een recente podcast, nietwaar, Doug?
Over het belang van het niet gebruiken van echte data zodat je niet in privacy problemen komt.
Nou, hij trok de stekker eruit, dus als je update naar de laatste versie, is het allemaal weg.
Je hoeft niet te updaten – het is wettelijk toegestaan om de oudere te blijven gebruiken – maar hij heeft duidelijk besloten dat het tijd is om uit Dodge City te vertrekken.
Maar met colors.js... helaas koos hij een minder begrijpelijke benadering, in die zin dat hij een nieuwe versie uitbracht die een oneindige lus bevatte, die er in feite voor zorgde dat er raar uitziende rommel werd afgedrukt wanneer je het uitvoerde, in plaats van je alleen maar kleuren toe te laten voegen aan uw console-uitgang.
Je weet hoe mensen van kleuren houden om woorden als FOUT, WAARSCHUWING, wat dan ook te markeren.
Maar als u deze update automatisch zou accepteren, als onderdeel van wat u uw toeleveringsketen zou kunnen noemen, dan zou uw programma plotseling een Denial of Service krijgen omdat het in deze lus terecht zou komen die liep vanaf een startwaarde van 666...
DOUG. [LACH]
EEND. ... tot, maar niet inclusief, de JavaScript-waarde Infinity.
Deze lus drukt "testen, testen, testen, testen, testen" af met een hele lading rommel toegevoegd.
Je zou kunnen zeggen dat dat niet erg aardig was om te doen, maar je hoefde de nieuwe versie niet te accepteren, en de code was daar voor jou om te zien: het was op geen enkele manier verborgen.
Het is open source, je zou het kunnen bekijken.
Hoe dan ook, sommige mensen werden geraakt en moesten terugkeren naar de oude versie, en dit veroorzaakte een hele reeks opmerkingen op zijn GitHub-account.
Ik geloof dat hij geen toegang heeft tot zijn GitHub-account, misschien begrijpelijk, maar er zijn honderden reacties.
Sommige mensen zeggen: 'Ja, ik ben bij je, bro'; Ik snap waar je vandaan komt', en andere mensen zeggen: 'Weet je wat? Waarschijnlijk een stap te ver.”
DOUG. Bedenk eens hoeveel commerciële softwarepakketten afhankelijk zijn van dit soort dingen...
EEND. Je zei bijna Log4j daar, Doug.
DOUG. [LACHT] Laten we het daar later over hebben.
EEND. Nou, ik vraag me af of de timing hiervan misschien niet werd versneld door de ophef over Log4j>
Misschien is dat wat deze kerel heeft uitgelokt?
Omdat ik begrijp dat hij heeft geprobeerd de toolkit faker.js te commercialiseren, wat erg handig is; een behoorlijk omvangrijke hoeveelheid code die realistische gegevens van alle soorten zou kunnen creëren.
Hij probeerde het wel te commercialiseren en online diensten te creëren die mensen die wilden hem konden betalen, maar dat leek hem niet te lukken, en dus was het niet echt duurzaam.
Dus trok hij daar de stekker uit.
Maar helaas vergiftigde hij de put van het andere project, en dat is waar we staan.
DOUG. Ik veronderstel dat dit de vraag naar het idee van een Software stuklijst, of een ingrediëntenlijst, zo u wilt, voor consumenten of mensen die uw software gaan kopen...
...zodat ze kunnen zien hoeveel open source-componenten het heeft, of waar alles vandaan komt.
EEND. Ja, misschien is dat de zilveren voering in deze.
Log4j loste het onderliggende probleem niet op: die functie werd toegevoegd aan Log4j, wat, in 2013?
En niemand merkte het tot nu toe, en toen ze dat deden, "Oh golly, hoe durf je?"
Nou, je nam de code jaren en jaren geleden in je software zonder te merken dat het dit probleem had, en je betaalde er niet voor; misschien is het een beetje overdreven om te suggereren dat het iemands schuld was, behalve die van jou, omdat je betrapt werd.
Dus misschien is de zilveren voering dat, hoewel je zou kunnen zeggen dat het een beetje kinderachtig was om te doen, het ons misschien zal helpen om, zoals je zegt, een Software stuklijst – “vermelde ingrediënten”.
Misschien is dat een goed idee.
DOUG. Oké, veel goede discussies daar.
Dat verhaal heet JavaScript-ontwikkelaar vernietigt eigen projecten in supply chain "les" op nakedsecurity.sophos.com
Dus je kunt daarheen gaan om te lezen en te denken.
En nu gaan we het hebben over NetUSB.
Ik herinner me de sensatie van het rechtstreeks aansluiten van mijn printer op mijn thuisrouter via USB, hoeveel jaar geleden en zeggen: "Wauw, we hebben het gehaald! De technologie heeft eindelijk haar top bereikt!”
EEND. NetUSB is een product dat u kunt licentiëren van een bedrijf in Taiwan genaamd Kcodes.
Ze beweren in hun marketingmateriaal dat meer dan 20% van de wereldwijde netwerkapparaten nu Kcodes-code in zich hebben, dus het klinkt alsof ze behoorlijk succesvol zijn geweest.
En NetUSB is, zo je wilt, een generieke USB-virtualisatie.
U kunt dus niet alleen een gecentraliseerde harde schijf of NAS aansluiten, of een printer, zoals u deed.
NetUSB kan andere zaken, zoals tv-tuners, audioapparaten, allerlei zaken centraal afhandelen.
Er loopt dus een soort virtuele USB-kabel over je netwerk, tussen je computer en (helaas) een speciale kerneldriver op je router...
... een stuurprogramma dat een bug bleek te bevatten waardoor, in theorie, bijna iedereen uw router had kunnen overnemen.
Oh jee.
DOUG. Oh schat, inderdaad.
EEND. Dus die bug is gevonden door een onderzoeker genaamd Max van Amerongen van Sentinel One.
Blijkbaar was hij op zoek naar deelname aan de Pwn2Own IoT-hackwedstrijd voor 2021.
Hij zag dat Netgear een apparaat op de lijst had staan, dus hij dacht: 'O, ik heb al eerder naar die apparaten gekeken; laat me eens kijken."
Hij ontdekte dat er een kernelstuurprogramma was dat luisterde op TCP-poort 20005... dat aantal lijkt willekeurig, dus dat is geen betrouwbare indicatie dat je dit probleem hebt, maar het kan een beginpunt zijn als je weet hoe je poortscans moet uitvoeren .
En Max bedacht: "Hé, lijst met kernelstuurprogramma's op alle netwerkinterfaces - localhost, LAN en WAN? Als er een kwetsbaarheid in zit, kan deze op afstand misbruikt worden. Daar ga ik me op focussen.”
En dus dook hij daar in de code.
Zoals je je kunt voorstellen, zoiets als NetUSB - het zal veel verschillende functies hebben die het ondersteunt.
Als je aan HTTP denkt, wel, dat heeft tientallen commando's: GET, POST, HEAD, OPTION... maar zoiets als NetUSB, met tientallen verschillende soorten apparaten, met tientallen verschillende functies, ondersteunt waarschijnlijk honderden verschillende commando's.
En hij ontdekte dat het commando 0x805F - ik denk dat dat gewoon willekeurig is, 32863 ...
Dat commando, toen het de gegevens verwerkte die ervoor moesten worden verzonden, had een vervelende kleine fout, Douglas, met het nummer 17.
In principe gaat de bug als volgt.
Als u deze opdracht wilt uitvoeren, heeft de opdracht iets te maken met een bericht; Ik weet niet wat de opdracht doet, want het is eigenlijk de voorbewerking die het probleem veroorzaakt, niet de opdracht zelf...
…het eerste dat de kerneldriver doet, is zeggen: “OK, ik heb wat gegevens van je nodig. Vertel me hoeveel gegevens u gaat verzenden', en het accepteert een waarde van vier bytes. (Je kunt zien waar dit naartoe gaat...)
Dan wijst het zoveel geheugen toe.
Dat klinkt slecht omdat het geen lengtecontrole doet.
Wat als de persoon zegt: "Oh, ik wil drie gig RAM toewijzen?" [GELACH]
Nou, stel je voor, op de gemiddelde thuisrouter gaat het gewoon niet werken, en het zal gracieus falen.
Het probleem is, als je zegt: "Ik wil 4 GB minus één byte", met andere woorden FFFFFFFF in hexadecimaal.
Dan, in plaats van te proberen zoveel bytes toe te wijzen, wat duidelijk niet zal werken omdat een 32-bits router geen 4 GB RAM tot zijn beschikking heeft om je bij de hand te hebben...
... wat de code zou doen, zou zeggen: "Nou, ik ga zoveel geheugen toewijzen als je wilt voor het geval je zoveel nodig hebt, zelfs als je het niet gebruikt. En ik heb 17 extra bytes nodig voor mijn eigen tijdelijke gebruik.”
Het zou dus een heel, heel groot positief, niet-ondertekend geheel getal *plus 17 bytes* geheugen toewijzen.
Dit zou rondlopen, millenniumbug of auto-kilometertellerstijl.
En dus zou een aanvaller kunnen zeggen: "Ik wil dat je me 4 GB-1 bytes RAM toewijst, en dat betekent dat ik je in de toekomst berichten van elke grootte tot dat bedrag kan sturen."
Maar de kernel zou dan een buffer van slechts 16 bytes toewijzen, vanwege de integer-overflow.
Dan zou de kernel zeggen: "Ok, stuur me je gegevens", en je stuurt het zoveel als je wilt ...
Natuurlijk, als je het dan meer dan 16 bytes verstuurt, wat per ongeluk al het toegewezen is, heb je een bufferoverloop in de kernel!
Bedankt voor het komen; spel is over.
DOUG. OK, het klinkt alsof we moeten wachten op een firmware-update!
EEND. Het goede nieuws is dat dit op verantwoorde wijze is bekendgemaakt.
De reden dat er pas dit jaar over is geschreven, hoewel het werk medio 2021 is gedaan, is dat dit op verantwoorde wijze is bekendgemaakt aan het bedrijf dat het NetUSB-product maakt, en vervolgens aan alle leveranciers die mogelijk licenties voor hun producten.
Ze wisten dus allemaal dat er een bug was en dat ze deze moesten repareren.
Het is dus op verantwoorde wijze bekendgemaakt en er zijn patches beschikbaar.
Het enige probleem is: hoe kom je erachter of je kwetsbaar bent?
Zoals ik eerder al zei, zou je kunnen proberen een programma zoals Nmap of zoiets te gebruiken, een poortscanner, en kijken of je poort 20005 open hebt staan op je router, wat een goede hint zou zijn dat je dit ding zou kunnen hebben, want dat is hoe de onderzoeker vond het in de eerste plaats.
Maar dat is natuurlijk slechts een symptoom: of je die poort open of gesloten hebt, betekent niet dat je de bug wel of niet hebt.
Dus als je een router hebt die deze NetUSB-functie ondersteunt, waarmee je niet alleen printers maar bijna elk USB-apparaat centraal kunt aansluiten, ga dan naar de website van je routerleverancier en controleer of er een update is.
DOUG. Oké, en we hebben nog wat ander advies dat ons kan helpen om een dergelijk misdrijf in de toekomst te verminderen.
EEND. Ja, het andere advies dat we in het artikel gaven, was niet aan gebruikers van thuisrouters die mogelijk risico lopen, waar we eigenlijk alleen maar kunnen zeggen: "Patch vroeg, patch vaak; controleer of er een patch beschikbaar is.”
We hebben wat advies gegeven voor programmeurs: drie snelle dingen.
Luister ten eerste niet standaard op alle netwerkinterfaces, tenzij het echt nodig is.
Ten tweede, controleer altijd de resultaten van het rekenen met gehele getallen, vooral als het gaat om geheugentoewijzing.
En de derde tip is om te controleren op integer-underflow, evenals op integer-overflow.
Als je je voorstelt een old-school auto-kilometerteller achteruit te laten lopen, is het getal vóór 000000 999999, niet -1, omdat auto-kilometers geen negatieve getallen kunnen geven.
Denk niet: "Er zijn zeker 17 bytes vrij", want er zijn misschien geen...
... u bent het aan uw gebruikers verplicht om dit te controleren.
DOUG. OK.
Het artikel is: Thuisrouters met NetUSB-ondersteuning kunnen een kritiek kernelgat hebben, op nakedsecurity.sophos.com
Nu is het tijd voor Deze week in de technische geschiedenis!
We hadden het eerder in de show over vrijdag de dertiende….
EEND. Ik heb een idee waar dit heen gaat, en ik denk dat het te maken zal hebben met computervirussen, Doug. [GELACH]
Dat is mijn vermoeden...
DOUG. Hoe wist je dat? [GELACH]
Deze week, op vrijdag 13 januari 1989, een vrijdag het dertiende virus besmette computers in heel Groot-Brittannië.
Dit was niet de eerste vrijdag het Dertiende virus, en het kan al dan niet een variant zijn geweest van het zogenaamde Jeruzalem-virus ervoor, een tijdbomvirus dat vanaf vrijdag de dertiende mei zou afgaan. 1988, de meest recente vrijdag de dertiende vóór januari 1989.
Beide virussen vertraagden de machines, maar lieten COMMAND.COM met rust.
En Paul, je hebt een geweldige kleur over al deze dingen omdat je het hebt meegemaakt. "Je was erbij, man."
EEND. Hoe de geschiedenis zich herhaalt!
Veel lessen uit die tijd kunnen we tegenwoordig oppikken, maar die over COMMAND.COM is best interessant.
Uit het geheugen, een van de allereerste bestanden die virussen in de DOS-wereld infecteerde – ik denk dat het misschien het Lehigh-virus uit de VS was – was heel duidelijk, want toen het het COMMAND.COM-bestand infecteerde, waren er slechts een paar varianten van COMMAND.COM, en sommige mensen hadden de grootte van dat bestand onthouden.
Dus het nieuws deed snel de ronde: "Hé, deze virusbusiness is triviaal om mee om te gaan. Het enige wat je hoeft te doen is kijken naar de grootte van COMMAND.COM, en als het verandert, heb je een virus!”
En de conclusie die mensen moesten trekken was daarom: als het *niet* verandert, heb je *geen* virus.
Dus, wat begonnen de virusschrijvers bijna onmiddellijk te doen?
DOUG. [LACH]
EEND. Ze infecteerden elk bestand *behalve* voor COMMAND.COM, omdat iedereen zich daarop concentreerde.
Maar het laat wel zien dat dit een ander tijdperk was... toen je een virus naar een hele *stad* kon noemen, in de veronderstelling dat er zo weinig virussen waren dat hoe groot de kans is dat het ooit nog een virus uit dezelfde plaats zou zijn?
DOUG. Ja, tijden veranderen, en niet altijd ten goede.
Over tijden die veranderen gesproken, het lijkt erop dat Honda ofwel zijn eigen kleine Y2K-moment heeft, of dat het per ongeluk iets heeft gebouwd dat werkt als een tijdmachine.
EEND. Ik hou van je werk daar, Doug – dat is een heel goed vervolg.
DOUG. Dank je!
EEND.Ik wist wat er zou komen, en dat had ik niet voorspeld.
Ja, de Honda-tijdmachine.
Het is zeker Terug naar het verleden, is het niet? Niet Terug naar de toekomst.
Blijkbaar, eigenaren van Honda-auto's van een bepaalde leeftijd - geen gloednieuwe, en ook geen merk-oude; de auto's moeten blijkbaar ergens rond een decennium oud zijn ...
…op nieuwjaarsdag 2022, als mensen hun auto zouden starten, zou de klok na een tijdje teruggaan naar ergens rond middernacht op 01 januari 2002.
En ik zou dit niet moeten zeggen, want het is wreed om te doen, maar ik ga zeggen dat als je 2002 niet meer kunt herinneren...
DOUG. Oh, nee, nee, neeeeeeeeeeee….
EEND. Mag ik het doen?
DOUG. Nee!
EEND. Laten we zeggen dat er een nummer in de hitparade stond met de tekst "La la la, la la la la-la, la la la la-la la la la la", van de kleine Australische popster Kylie Minogue - dat is hoe ver terug zijn we gegaan.
En niemand wist precies waarom.
De beste gok tot nu toe lijkt te zijn dat het betrekking heeft op wat bekend staat als GPS-rollover, op dezelfde manier als de Millennium-bug werd veroorzaakt door mensen die zeiden: "Weet je wat? We gaan gewoon 19 afleiden en gebruiken twee cijfers voor het jaar.”
Natuurlijk, GPS is uitgevonden in de jaren '1970, en de bandbreedte van deze verre satellieten is zeer, zeer beperkt.
En ze dachten, nou ja, wat we zullen doen is dat we zullen werken met intervallen van 1024 weken in plaats van jaren.
Er is dus een “weeknummer” en er zijn slechts 10 bits beschikbaar voor het weeknummer.
Dus elke 1024 weken gaan ouderwetse GPS-apparaten terug naar wat je Day Zero zou kunnen noemen.
Ik noem ze 'kiloweekaries', en die kilowwekaries gaan van 1980 tot 1999; 1999 tot 2019; en 2019 tot 2039.
Nu was er een beruchte kiloweekse reset op 06 april 2019, waarbij mensen met oude GPS-ontvangers zich afvroegen: "Gaan ze terug naar 1999?"
Sommigen deden het, sommigen niet.
Maar natuurlijk, net als de Millennium Bug, hoef je hier niet *alleen tijdens de exacte rollover-periode* door te worden getroffen.
Zoals je je herinnert, met de Millennium-bug, was wat veel software deed om aan te nemen dat iets vóór 50 daadwerkelijk naar het volgende millennium verwees.
Dus 50 betekent 1950, maar 49 betekent 2049 - dus je hebt nog steeds een millenniumbug, maar je verschuift het een beetje.
DOUG. Laat de toekomstige generaties het maar oplossen!
EEND. Absoluut.
Dat kan natuurlijk met GPS rollover, en dat is wat veel software doet.
Hoe weet je welke startdatum je moet gebruiken? Nou, de voor de hand liggende manier om dit te doen is om de tijd, of de datum, of het jaar te gebruiken waarin je de software compileert die momenteel op het GPS-apparaat draait - want dat kan nooit achteruit gaan.
En dus kun je een vergelijking maken die zegt: "Ik verwacht niet dat deze software voor, zeg, 2003 in het spel zal komen. Dus als ik ooit een jaar zie dat vóór 2003 is, ga ik er gewoon van uit dat ik geen bereik."
En wat u doet, is dat u enkele dagen, weken, maanden, jaren overstag gaat vanaf het begin van een GPS-periode van 1024 weken - ongeveer 20 jaar; 19 jaar, zeven en een halve maand….
... je neemt in feite een paar dagen en je verschuift ze naar het einde van de huidige kiloweekperiode.
En de suggestie is dat dat Honda hier misschien is opgevallen.
De reden dat ik vermoed dat dit het geval is, is dat een lezer van The Register, een populaire IT-publicatie in het VK, daar opmerkte dat hij een Honda CR-V had die hierdoor werd getroffen, en elke keer dat hij zijn auto start , springt de tijd terug naar 01 januari 2002, alsof de klok gewoon niet weet wat hij moet doen.
Het is dus standaard het begin van het jaar kiezen. (Maar omdat de klok wordt gevoed door GPS, kun je deze natuurlijk niet handmatig instellen.)
In dit geval lijkt het alsof het weet wat de juiste tijd is, maar niet welk jaar het is, dus het rekent uit: "Ik zal gewoon beginnen om middernacht, min of meer, plus of min in welke tijdzone ik denk dat je je bevindt.”
Blijkbaar ontdekte deze man dat zijn GPS dacht dat het mei 2002 was, bijna precies 1024 weken geleden, waardoor hij dacht dat dit naar GPS rollover ruikt.
DOUG. Interessant.
EEND. En dat is de beste gok die ik kon bedenken over hoe dit gebeurde: dat het wordt veroorzaakt door zoiets als de millenniumbug, maar gerelateerd is aan een beperking die begrijpelijkerwijs in de jaren zeventig in GPS is ingebouwd, omdat elk beetje telt wanneer je moet het betrouwbaar door de ruimte krijgen.
Dus, wie weet wat er is gebeurd, Doug?
Maar het is een aanwijzing voor elke programmeur dat, wanneer je vandaag code schrijft, en je denkt: "Hoe groot is de kans dat de code die ik vandaag uitwerk, nog steeds in gebruik zal zijn in 2042?"...
…het antwoord is *waarschijnlijk* niet, maar zeer *mogelijk* zou kunnen zijn.
DOUG. Je weet maar nooit!
EEND. En daarom kunnen de beslissingen die u vandaag neemt, echt invloed hebben op mensen die zo ver vooruit zijn.
DOUG. 'Denk alsjeblieft aan de kinderen,' snap je wat ik bedoel?
EEND. Precies!
Zoals de millenniumbug bewees; zoals bugs als deze bewijzen: 20 jaar is zowel een zeer lange tijd, maar ook een vrij korte tijd als het gaat om de levensduur van computersoftware.
DOUG. Absoluut.
Oké, dat is een fascinerend verhaal - we hebben een aantal goede reacties, dus kom en lees er alles over: Honda-auto's in flashback naar 2002 - "Kan je niet uit mijn hoofd krijgen".
En nu heb ik die oorwurm….
EEND. Jij zei het! Volgens mij heb ik die woorden niet echt gebruikt.
Ik zei net, [ZINGT, GELEIDELIJK UIT] "La la la, la la la la-la/La la la, la la..."
DOUG. We stellen hier niet graag teleur, maar helaas hebben we geen Apple bug...
EEND. [ANXIOUS] Ik heb mezelf oorwormen gegeven!
DOUG. Heb je jezelf oorwormen gegeven?
We hebben deze week geen Apple bug-verhaal, maar we kunnen geen Log4Shell-verhaal aanbieden.
Dus misschien is dat ons nieuwe Apple-bubbelverhaal - we hebben er een paar.
EEND. Ik hoop dat Log4j dat nummer uit mijn hoofd zal schrikken, want ik heb mezelf echt oorwormen gegeven, Doug, en ik mag niet echt klagen, toch?
DOUG. Nee meneer!
EEND. Aaaargh.
Oké, dus het is niet helemaal opnieuw Log4j, maar het is een belangrijke herinnering.
Zoals je weet uit de podcast van vorige week, spraken we over hoe de Amerikaanse publieke sector decreteerde: 'The Night Before Christmas: je zult dit tegen die tijd voor elkaar krijgen. Laat het niet achter. Doe het vandaag. Het gaat niet vanzelf over."
Nou, kom het nieuwe jaar; kom de Federal Trade Commission - de FTC is in feite de Amerikaanse organisatie voor consumentenrechten, en het is naar buiten gekomen met een nogal pittige, kleine herinnering aan bedrijven die actief zijn in Amerikaanse rechtsgebieden.
Zelfs als u het slachtoffer bent van cybercriminaliteit, kunt u zelf aansprakelijk worden gesteld als u dit had kunnen voorkomen door te patchen en het redelijkerwijs te verwachten was dat u dit zou hebben gedaan.
Ze waren behoorlijk pittig in wat ze zeiden, en de waarschuwing bevat deze woorden, Doug: "De FTC is van plan om haar volledige wettelijke bevoegdheid te gebruiken om bedrijven te vervolgen die in de toekomst geen redelijke stappen ondernemen om consumentengegevens te beschermen tegen blootstelling als gevolg van Log4j of soortgelijke bekende kwetsbaarheden."
DOUG. Whoa!
EEND. Het is niet alleen dat Naked Security zegt: "Patch vroeg, patch vaak"!
Het is de FTC die je eraan herinnert dat sympathie maar zo ver gaat, en dat je zowel slachtoffer als dader van cybercriminaliteit kunt zijn om dezelfde reden – namelijk dat je niet hebt gepatcht.
Het laat de boeven binnen, en daar hebben we medelijden mee.
Maar als het boeven binnenlaat waar je redelijkerwijs verwacht had dat je ze buiten hield, door de voorzorgsmaatregelen te nemen die eerlijk gezegd iedereen was, dan moet je misschien het blikje voor een deel daarvan dragen.
DOUG. Oké, dus als ze zeggen "Log4j of vergelijkbare bekende kwetsbaarheden in de toekomst", hadden we niet al te lang daarna een vergelijkbare kwetsbaarheid met deze H2-bug.
EEND. Ja, verrassend vergelijkbaar met Log4Shell.
En in feite gevonden door onderzoekers die Java-code doorzochten voor vergelijkbare soorten programmering die in de eerste plaats tot de Log4Shell-kwetsbaarheid leidden.
Deze bug, CVE-2021-42392, is ontdekt door een supply chain management-bedrijf genaamd JFrog.
Ze besloten: "Hé, laten we eens kijken naar alle Java-code die een soortgelijk gebruik van dit JNDI-ding zou kunnen bevatten" - dit Java-naamgeving en directory-interface dat bleek misbruikbaar te zijn in de Log4j-bug.
En als je je JNDI herinnert, is dat het ding waar je eigenlijk zegt: "Hé, ik wil dat je deze gegevens opzoekt. Oh, ik heb de gegevens niet, maar ik zal je een URL sturen voor wat gegevens; in feite stuur ik je een URL voor een programma: voer het programma uit en kijk wat dat je vertelt.'
Ik denk dat JFrog zich afvroeg hoeveel andere programma's delen van hun code hebben waar deze JNDI-naamzoekfunctie kan worden gebruikt en misschien te veel wordt gebruikt.
Helaas vonden ze er heel snel een in een populaire Java SQL-database-engine genaamd H2.
Ik moet eerlijk zijn, Doug, ik had nog nooit van H2 gehoord.
DOUG. Nee ik ook niet.
EEND. Ik heb gehoord van MySQL, PostgreSQL, SQLite, alle no-SQL database-dingen.
Maar ik had nog nooit van H2 gehoord om dezelfde reden dat ik nog nooit echt van Log4j had gehoord: de hele claim op roem was dat het iets compact genoeg was dat – in tegenstelling tot bijvoorbeeld MySQL of Microsoft SQL, waar je tegenaan loopt een server en maak er verbinding mee - hey, je kunt het gewoon in je applicatie zuigen, H2 als onderdeel van je applicatie hebben.
DOUG. O, gaaf!
EEND. Het is weer zo'n ding waar applicaties die je misschien hebt geïnstalleerd - ze hadden dit kunnen binnenhalen, net zoals Java-apps Log4j hadden kunnen binnenhalen.
Het slechte nieuws is dat de bug op bijna precies dezelfde manier werkt als de Log4Shell-kwetsbaarheid: je krijgt dit JNDI-ding en in plaats van alleen een lokale zoekopdracht uit te voeren, zeg je: "Hé, weet je wat? Voor het opzoeken is hier een URL; ga en haal dit Java-klassebestand en voer het uit."
Het is dus dezelfde opeenvolging van gebeurtenissen die leidt tot de exploiteerbaarheid.
Dat is het slechte nieuws.
Het goede nieuws is dat, voor zover ik weet, de enige realistische manier waarop een aanvaller hier misbruik van kan maken, is als ze binnen kunnen komen en het configuratiebestand voor deze H2-component op een van de computers in je netwerk kunnen wijzigen.
Met andere woorden, het is meer een verhoging van bevoegdheden of een truc voor laterale verplaatsing dan het uitvoeren van code op afstand.
Want hoewel je het zou kunnen gebruiken voor het uitvoeren van externe code als het gat open was, zou je lokale toegang moeten krijgen om het geheel te openen voor toegang op afstand, als je begrijpt wat ik bedoel.
DOUG. Ja.
EEND. Met andere woorden, u moet inbreken in het netwerk om in te kunnen breken op het netwerk.
Maar het is toch iets dat je wilt patchen, omdat het een functie is die er per ongeluk was, net als het Log4Shell-probleem.
Het is dus nog steeds een bug met patchen; het is gewoon niet helemaal de potentiële ramp voor het uitvoeren van externe code die we zagen met Log4Shell.
DOUG. Oké, we hebben wat advies.
Als je weet dat je een app hebt die de H2-database-engine draait, kun je upgraden naar versie 2.0.206; of als u het niet zeker weet, kunt u zoeken naar exemplaren van de H2-code op uw netwerk.
EEND. Ja, dat lijkt een beetje op het Log4j-probleem, nietwaar?
Toen mensen stopten om erover na te denken, realiseerden ze zich dat ze eigenlijk niet wisten hoeveel apps ze in Java hadden om mee te beginnen; en toen wisten ze niet hoeveel daarvan Log4j bevatten.
Toen ze gingen zoeken, ontdekten ze: "Golly, er zijn veel meer Java-apps dan we dachten, en veel daarvan hadden toevallig Log4j."
Hetzelfde geldt voor deze H2: het kan in een app-act zijn zonder dat je het zelfs maar door hebt.
DOUG. Daar is die stuklijst weer - we hebben die stuklijst nodig!
EEND. Precies!
Dus, zoals je deed met Log4j, waar je op zoek was naar log4j DASH, wat dan ook ...
... hier kun je zoeken naar bestanden met de naam h2 DASH STAR DOT jar - dat is Java Archive.
Als die bestanden verschijnen, als je die hebt, zullen ze waarschijnlijk iets bedenken als h2 DASH two DOT zero DOT een of ander nummer of een andere DOT-jar.
En zoals je al zei, Doug, wat je zoekt is 2.0.206 of later.
DOUG. Oké, ga ervoor, iedereen!
Dat is genoemd Log4Shell-achtig beveiligingslek gevonden in populaire Java SQL-database-engine H2, op nakedsecurity.sophos.com.
EEND. En neem het niet van ons aan dat je er naar toe moet. Neem het van de FTC!
DOUG. Ja serieus! [LACHT]
EEND. Ik wil niet zeggen dat ze mensen bedreigen, maar ze zeggen: "Het doet ertoe."
DOUG. Ze dringen er "sterk op aan".
En daar kun je meer over lezen op nakedsecurity.sophos.com: FTC dreigt met juridische stappen over ongepatchte Log4j en andere kwetsbaarheden.
En terwijl we de show afronden, is het tijd voor de Oh! Nee! van de week.
Reddit-gebruiker LordDragon24Aug965, schrijft ...
EEND. Is dat de hele naam?
DOUG. Dat is de hele naam, ja.
EEND. Doe het nog een keer, ik heb niet alles opgevangen...
DOUG. LordDragon24 augustus 1965…
EEND. [SARCASTISCH] Dat zou toch niet zijn verjaardag zijn?
DOUG. Het kan zijn, want hij begint met te zeggen: "Vroeger..." [GELACH]
Ik was de enige telefonische ondersteuningstechnicus voor een van de alomtegenwoordige pc-kloonhuizen die adverteerde in de computertijdschriften.
We hadden 200 computers verkocht aan een softwarebedrijf en de eerste ging rechtstreeks naar een VP van het bedrijf om te testen terwijl we de rest van de bestelling bouwden.
De verkoper kwam in volledige paniek naar me toe en vertelde me dat de machine, die ik had getest voordat hij de winkel verliet, niet wilde inschakelen.
Ik belde de VP die zei dat er helemaal geen lampjes op de machine waren.
Ik vroeg ze om naar de achterkant te kijken en te zien of de ventilator van de voeding – de enige ventilator in die tijd – draaide.
Hij zei dat ik moest volhouden - hij moest het licht aandoen.
Zou je het niet weten?
Hij had de stekker in een geschakeld stopcontact gestoken.
En Paul, ik ben geïnteresseerd om te weten of dit zelfs maar logisch voor je is ....
Het eindigt met te zeggen: "De verkoper heeft een lunch voor me gekocht om zijn commissie te sparen."
Heeft u zelfs een concept van het "geschakelde stopcontact" in uw nek van het bos?
EEND. Sterker nog, ik denk dat in elk rechtsgebied waar ik ooit in mijn leven heb gewoond...
…Ik ben het fenomeen van een *ongeschakeld* stopcontact nog niet tegengekomen.
DOUG. O, dat klopt, ja!
EEND. Waarom zou u om veiligheidsredenen geen schakelaar hebben, zodat u deze kunt uitschakelen?
Het is met name relevant in het VK, waar we ringleidingen gebruiken - als één stopcontact live is, zijn ze allemaal live.
We hebben dus verkooppunten die, zoals ik het begrijp, wettelijk zijn omgeschakeld.
Het rare dat we hebben – in twee van de landen waar ik heb gewoond, hebben de regelgeving – ik denk niet dat je die in de VS hebt – dat je geen lichtschakelaars in de badkamer mag hebben.
DOUG. Interessant.
EEND. Je moet ofwel een gewone lichtschakelaar buiten de badkamer hebben, of - meestal in het VK - je hebt een trekschakelaar waarbij de schakelaar in het plafond zit en deze wordt bediend door een touwtje dat geen elektriciteit geleidt.
Maar je mag geen schakelaar – of stopcontact – in een badkamer.
DOUG. Interessant!
Nou, ik heb zoveel geleerd vandaag, dus bedankt dat je me opheldering geeft over deze en alle andere dingen waar we het over hadden.
En als je een hebt Oh! Nee! je wilt indienen, lezen we het graag in de podcast.
U kunt tips@sophos.com e-mailen; u 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]
