D-Link blundert met vrijgeven privésleutels van certificaten

D-Link had per ongeluk privésleutels voor certificaten waarmee software ondertekend wordt vrijgegeven. De sleutels waren te destilleren uit opensource-firmwarepakketten van de fabrikant. Criminelen hadden de certificaten daarmee kunnen misbruiken.

Malwareschrijvers kunnen de certificaten gebruiken om hun schadelijke code te signeren, waarmee het er voor bijvoorbeeld Windows als legitieme software uitziet. Het certificaat is de garantie dat de programma's ook daadwerkelijk afkomstig zijn van het desbetreffende bedrijf.

De blunder is ontdekt door bartvbl, die de redactie op het probleem wees. Hij had de DCS-5020L-beveiligingscamera van D-Link aangeschaft en wilde de firmware downloaden. D-Link maakt de broncode van veel firmware opensource onder een gpl-licentie beschikbaar. "Het bleek na wat door de bestanden te kijken dat er private keys in zaten om code mee te signeren", meldt bartvbl, "Sterker nog, in wat batchfiles stonden de commando's en passphrases die er voor nodig waren."

De user wist te verifiëren dat de sleutel gebruikt kon worden om met een certificaat een bestand dat niet van D-Link was te ondertekenen. Begin september verliepen de certificaten, waardoor de truc nu niet meer werkt. Ook na het verstrekken van de verloopdatum blijft software die ondertekend is als valide gezien worden. Pas na het intrekken van de certificaten en het schrappen van de Certificate Trust List krijgt Windows bij een certificaatcheck de melding dat ze niet valide zijn. Dat intrekken is inmiddels gebeurd.

Beveiligingsbedrijf Fox-IT bevestigt desgevraagd de bevindingen van de user. Yonathan Klijnsma, onderzoeker bij het bedrijf: "Het codesigning-certificaat zit inderdaad in een van de firmwarepakketen, firmwareversie 1.00b03, waarvan de source 27 februari dit jaar was vrijgegeven. Dit certificaat was dus uitgegeven voor het verliep, een grote fout." Hij vond zelfs nog vier andere certificaten in dezelfde map.

D-Link heeft inmiddels nieuwe versies van de firmware uitgebracht, waar de certificaten niet meer inzitten. Het bedrijf laat in een verklaring weten regelmatig de firmware bij te werken om 'aan de laatste veiligheids- en kwaliteitsstandaarden' te voldoen. Het bedrijf benadrukt dat er geen sprake was van opzet. "D-Link voorkomt te allen tijde het ontwikkelen van producteigenschappen die met opzet ongeoorloofde toegang tot het apparaat of netwerk bieden, waaronder bijvoorbeeld backdoors." Verder belooft het bedrijf aan Tweakers dat begin volgende week nieuwe firmware uitkomt waarin de beveiligingsproblemen verder zijn opgelost.

Reacties (25)

[CAPSLOCK2000]

Fox-IT
Dit certificaat was dus uitgegeven voor het verliep, een grote fout.

Die opmerking snap ik niet, dat is dubbel fout. Natuurlijk geef je certificaten niet uit nadat ze zijn verlopen. Je gaat ook niet naar de sportschool nadat je abonnement is verlopen. Je gebruikt ze voordat ze zijn verlopen.
Ten tweede geef je nooit de private key uit. Helemaal nooit, of het certificaat dat er bij hoort nu is verlopen of niet. Het is nergens voor nodig en het heet niet voor niets een private key.

Ook na het verstrekken van de verloopdatum blijft software die ondertekend is als valide gezien worden.

Dat snap ik ook niet. Wordt hier nu beweerd dat Windows niet controleert of een certificaat verlopen is? Dat zal toch niet?

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 19:17]

[bartvbl]

De private key was geldig tot begin september. Daarna kan hij niet meer gebruikt worden om nieuwe code mee te signeren. De andere 3 certificaten waren al langer geleden verlopen.

Hij blijft wel als geldig gezien worden, omdat gesigneerde files nog steeds indirect een handtekening van de root CA bij zich dragen. Windows blijft dus het certificaat als geldig zien na de verloopdatum (net getest met de executable die ik had gesigneerd met het certificaat).

[CAPSLOCK2000]

Een private key heeft geen geldigheidsduur. Het certificaat dat er voor wordt gemaakt wel, maar de key zelf niet.

Dat van die indirecte handtekening snap ik niet. Er is toch geen geldige keten meer te maken tot de root?

[bartvbl]

Ik heb even wat door de handtekening van de exe file gebladerd, en ik denk dat het zo zit:

Een signatuur wordt gemaakt door met de private key bijvoorbeeld de hash van de file en andere informatie te decrypteren. Je kan die dan encrypteren met de public key om zo de orginele informatie terug te krijgen. Als je weet van wie de public key is, weet je ook dat die partij de private key heeft.

Als een CA een file signeert, neemt ie een private key die door die CA is gesigneerd, en een naam die bij de private key zit. De public key, de naam van de public key en de hash van de file worden dan bij elkaar gesigneerd door de CA, wat een digitale handtekening geeft.

Om dan de file te verifiëren moet je met de public key van de CA de handtekening encrypteren. Het certificaat van de CA is geldig tot 2020, wat betekend dat windows de handtekening nog voor de komende 5 jaar als geldig zal beschouwen.

[CAPSLOCK2000]

Bedankt voor de research! Interessant, maar volgens mij klopt het niet

Het signeren van files is namelijk niet het werk van CA's. Dat doen de developers zelf met hun eigen certificaat. Op dat certificaat staat de handtekening van de CA om het geldig te maken. Maar de files zelf (of hun hashes) komen nooit bij de CA.

CA's signeren alleen certificaten (technisch gezien zijn dat ook files, maar ik probeer een onderscheid te maken tussen "certificaten" en "data die je wil beveiligen").

[bartvbl]

https://msdn.microsoft.co...a388170%28v=vs.85%29.aspx

Klopt, het lijkt inderdaad lokaal te zijn. In dat geval wordt de lokale private key gebruikt om de file te signeren, en windows kijkt voor geldigheid alleen naar de verloopdatum van het certificaat onderaan de ketting; de CA.

Wat ook logisch is: als je een executable naar servers gaat sturen heb je kans op een man in the middle attack. Dat moet natuurlijk niet.

[Reactie gewijzigd door bartvbl op 22 juli 2024 19:17]

[Blokker_1999]

En maar goed dat Windows de getekende binary als geldig ondertekend blijft aanzien. Dit komt door de timestamp die je hebt opgegeven (het deel van het commando dat naar een externe server verwijsd). Hiermee kan Windows na gaan dat het certificaat op moment van ondertekening nog geldig was. Je kan die timestamp trouwens bekijken als je de eigenschappen van het bestand bekijkt in de Windows verkenner en dan naar het tab van de handtekening gaat. De laatste kolom geeft weer wanneer het bestand ondertekend is. Klik je op details kan je ook zien welke service gebruikt werd.

Je kan een bestand ook ondertekenen zonder die timestamp te doen, maar dan zal het bestand niet meer vertrouwd worden op het moment dat het certificaat niet meer geldig is. (een fout die ik bij mijn eerste ondertekeningen gemaakt heb)

[nlsp]

[...]
Wordt hier nu beweerd dat Windows niet controleert of een certificaat verlopen is?

Hangt ervan af of je ook een timestamp service gebruikt bij het genereren van de binary. Als een binary een geldige handtekening heeft én een ondertekende timestamp daaroverheen dan blijft windows die binary vertrouwen nadat het gebruikte certificaat is verlopen, omdat de ondertekende timestamp aantoont dat de handtekening geldig was op dat moment.

@Blokker_1999 oh dat zei jij ook al ;-)

[Reactie gewijzigd door nlsp op 22 juli 2024 19:17]

[Maistah]

Het scheelt dat ze snel nieuwe firmware hebben uitgebracht. Er zijn genoeg bedrijven die hier dagen, zo niet, weken overheen laten gaan.

Zolang er mensen werken worden er altijd wel fouten gemaakt. Shit happens. Leren we/ze van en wordt in de toekomst beter op gelet.

Mooi gevonden trouwens

[Reactie gewijzigd door Maistah op 22 juli 2024 19:17]

[bartvbl]

Het was geheel per toeval. Er zat een flyer bij de camera die ik in mei ergens heb gekocht die wees op het bestaan van de GPL broncode. Ik was benieuwd wat daar in te vinden zou zijn, en kwam na wat bladeren terecht in de folder met de genoemde certificaten.

Heb natuurlijk meteen D-Link ingelicht en de autoriteit die het certificaat had uitgegeven, maar nooit meer wat gehoord.

Ik heb ook een reeks installers gedownload voor willekeurige drivers van D-Link's site, en heb dit certificaat redelijk vaak aangetroffen (d.m.v het serienummer te verglijken).

[Maistah]

Geen bedankje, niks? Dat vind ik namelijk ook veel te vaak gebeuren. Vooral in zo een situatie waarin je het netjes meldt en zij op deze manier imagoschade ontlopen.

Dit stukje nalatigheid van hun eigen medewerkers wordt verholpen door een onbetaalde derde (dit gewoon klant is). Dan is een bedankje toch het minste wat je kunt doen, toch?

[Anoniem: 387522]

maar nooit meer wat gehoord.

Dat vind ik echt bizar en slecht. Ze zouden je toch op zijn minst op de hoogte moeten houden van de afwikkeling en zoals Maistah zegt zou een bedankmail ook op zijn plaats zijn. Ik baal ervan dat ik ook D-Link apparatuur heb. Als ze jou op de hoogte zouden houden, zie ik alleen maar pluspunten tov hun concurrentie: open source delen, snel reageren op beveiligingsfouten cq lekken. Hun concurrentie doet het geen haar beter, maar D-Link had hier echt kunnen uitblinken en mij als klant behouden.

[Tweekzor]

Leren we/ze van en wordt in de toekomst beter op gelet.

Denk je dat? D-link heeft in het verleden meerdere malen laten zien dat ze niet heel erg streng omgaan met security:
http://www.devttys0.com/2...e-ridiculous-fuck-d-link/

their patch to prevent an unauthenticated sprintf stack overflow includes a new unauthenticated sprintf stack overflow.

[Jeldert]

Netjes dat er gewacht is met het tippen van de redactie/publiceren tot nadat het certificaat ongeldig is gemaakt.

Je kan alles nog zo beveiligen, maar een foutje van de mens kan zomaar alle beveiliging weer ongedaan maken.

[CAPSLOCK2000]

Dat vind ik helemaal niet netjes. De klanten waren kwetsbaar. Ze hebben het probleem niet opgelost maar verzwegen!

Als ze direct een nieuwe firmware hadden uitgebracht dan had ik ook gezegd "vergissen is menselijk" maar dat vind ik nu niet van toepassing. Ik roep namelijk ook altijd dat er nu eenmaal fouten worden gemaakt maar ik zeg er achter aan: "wat telt is hoe ze met hun fouten omgaan."
Zo lang mogelijk verzwijgen is geen goede oplossing.

[bartvbl]

Nog een leuk feitje: ik heb net versie 1.10 van de firmware gedownload, en daar zaten de certificaten nog steeds in. Het zou me ook niets verbazen als er ook andere firmware versies zijn waar ze bij zijn gekomen.

[kimborntobewild]

Pas na het intrekken van de certificaten krijgt Windows bij een certificaatcheck de melding dat ze niet valide zijn. Dat intrekken is inmiddels ook gebeurd. Daarmee is het probleem niet meer te misbruiken.

Tja... Standaard / default staat de instelling in Windows of er moet worden gecheckt op intrekking van certificaten op uit.

[Anoniem: 503755]

Zolang er geen enkele repercussie is naar een fabrikant (lees: boetes) is het een straat zonder eind.

De eindgebruiker is alweer de pineut en rotbedrijven zoals Hacking Team krijgen gratis tools om alweer een nieuwe exploit in mekaar te schroeven, netjes gesigned, met dank aan D-Link.

"D-Link voorkomt te allen tijde het ontwikkelen van producteigenschappen die met opzet ongeoorloofde toegang tot het apparaat of netwerk bieden, waaronder bijvoorbeeld backdoors."

Right.

Vandaar dat er op de D-link website een schimmig formulier te vinden is waar je kwetsbaarheden kan melden die dan nergens op diezelfde site te vinden zijn.

Ontelbaar veel uren aan aan reverse engineering, fuzzing, whatever ... allemaal gratis! Komt dat zien!

[hokitoki]

Er is nu vast ook een medewerker die een week lang niet meer op zijn billen kan zitten

[kdekker]

Dat is onzin. Als je voor fouten mensen gaat ontslaan, ontstaat er alleen maar een cultuur van complete risicomijding. Elke codewijziging is een risico, en niets doen betekent dat er geen toename (maar ook geen afname) van risico is, maar ook geen fixes gemaakt worden.

Die denktrant van: straf degene die een fout gemaakt heeft is werkelijk contraproductief. Uiteraard ga je wel kijken of de fout in het vervolg voorkomen kan worden, maar fouten uitsluiten is onmogelijk (ook met code generatoren :-)).

Hopelijk gebruiken ze wel andere private/public key pairs...

[MadEgg]

Bugs introduceren is wel wat anders dan geheime informatie zoals passphrases en privésleutels publiceren. Ik wil nog wel geloven dat de betrokken medewerker dat niet met opzet gedaan heeft maar het is wél oerdom en zeer onzorgvuldig. Of ontslag terecht is kun je over twisten maar er mag op zijn minst een zeer serieus gesprek met de verantwoordelijke gehouden worden.

[kdekker]

Zonder het hele verhaal te kennen wat er binnen het bedrijf heeft plaatsgevonden, lijkt je reactie terecht. Echter als de tijdsdruk etc etc door het management kwam, dan wordt het verhaal al anders.

Veelal zijn - achteraf gezien - fouten 'dom' te noemen, of slordig, onzorgvuldig etc. In ieder geval kun je in NL niet zomaar voor domme fouten ontslagen worden. Het nadeel van 'ontslag bij domme fout' vaak een zondebok gezocht wordt in de uitvoerende hoek en management (altijd) de dans ontspringt. In de praktijk zie ik dat managers de verantwoordelijkheid niet kunnen/willen nemen.

Niet helemaal hetzelfde, maar als voorbeeld: Ik kan je vertellen dat in de praktijk geplande release data voorrang heeft boven veiligheids--fixes. Sterker nog, compatibiliteit, ook al gaat dat ten koste van de veiligheid, kan voorrang hebben. Als later blijkt dat het veiligheidslek een grotere impact heeft dan de gebroken compatibiliteit, dan is er wel een probleem, waar meestal niemand de verantwoordelijkheid voor wilt nemen. In genoemd voorbeeld kwam de veiligheidssoftware uit de opensource gemeenschap, wat het nog iets ingewikkelder maken.

[kaas-schaaf]

Het lijkt er op dat de Privesleutels in de repository stonden. Dit is een uiterst slecht idee, omdat je hierdoor makkelijk ze ergens achter laat of 'per ongeluk' mee verpakt in een package of installer.

Een goede deployment omgeving (lees apparte voor signen, waar geen source aan te pas komt) zou geen slecht idee zijn. Ook voor het openbaren van souce, want het copy pasten van een hele source tree zal niet de bedoeling zijn geweest.

Tijdsdruk is altijd een slecht idee, net als niet genoeg tijd krijgen voor (door management vaak gezien als secundaire) taken zoals deployment en het opzetten van een goede structuur voor het packagen van data. Dat voorkomt een hoop problemen met losse files die her en der achterblijven of meegestuurd worden.

[Bor]

Private keys dienen zo goed mogelijk beschermd te worden. Opslag in een toegankelijke repository is waanzin. Het liefst sla je de sleutels helemaal niet op op de computer waarop er mee gewerkt wordt maar maak je bijvoorbeeld gebruik van een hardware security module

[kaas-schaaf]

Het correct opslaan van release keys zou, in een HSM of niet, moeten gebeuren op een apparaat dat is losgekoppeld van directe toegang. Of dit nu via een tunnel of volledig losgekoppeld is, maakt niet uit. Helaas zijn de meeste apparaten die als hsm worden beschouwd niets meer dan wat flash geheugen met een crypto chip er voor/naast, en hebben ze 0.0 anti-tamper oplossingen.

Een betere oplossing zou zijn om in dit geval een smartcard als HSM te gebruiken, of om multi-card oplossingen (3 over 5 bijvoorbeeld, waarbij de sleutel verdeelde is over meerdere kaarten en zodoende minimaal 3 van de 5 nodig zijn om de sleutel te kunnen gebruiken) te gebruiken, maar dit is nogal tijdrovend en word door velen als overbodig gezien voor non-bedrijfskritieke operaties.

Een bedrijfs-hsm, zoals network accessable-hsms zouden bij non-kritieke operaties ook kunnen maar dan moet de identity die gekoppeld is aan de token op de hsm wel voorzien zijn van een externe manier om de identity vast te stellen en te valideren. Dit kan op vele manieren (populaire, niet heel betrouwbare oplossingen zijn de usb identifiers), maar dat is aan het bedrijf om de risicos vast te stellen.

Kort door de bocht hebben ze nogal wat fouten gemaakt en goede procedures voorkomen dat iemand niet weet wat hij met de sleutels moet doen en de juiste inrichting van het bedrijfsproces maakt het mogelijk om dit te doen.

Uit ervaring weet ik dat ondanks procedures en goede versleuteling, de zwakste schakel de mens is. En dan voornamelijk de luiheid van de mens.
(ik heb verschillende versies javacards en pci-e HSMs op mijn bureau liggen)