Browserfix beschermt niet automatisch iedere cryptobot tegen eMudhra-risico
Chrome of Firefox kan een gevaarlijk certificaat blokkeren terwijl een handelsbot op dezelfde computer het nog steeds vertrouwt. De problemen rond eMudhra laten zien waarom bescherming tegen vervalste HTTPS-certificaten per softwareketen moet worden gecontroleerd.
CertiK-onderzoeker Peiyu Wang waarschuwt dat cryptobots, exchange-applicaties en andere achtergrondprocessen buiten de browser andere certificaatcontroles kunnen gebruiken. Een opgeloste browsertest zegt daardoor niet automatisch iets over de verbinding waarmee een bot orders verstuurt.
Acht privésleutels bleken gecompromitteerd
Het incident draait om acht intermediate CA-certificaten van eMudhra.
Google kreeg op 17 oktober een melding dat de bijbehorende privésleutels waren gecompromitteerd. Volgens de Chrome Security-publicatie waren die sleutels met onvoldoende cryptografische willekeur gegenereerd.
Dat maakte het mogelijk om de privésleutels uit de openbare gegevens terug te halen.
Van de acht betrokken intermediates konden zes worden gebruikt voor TLS-certificaten. De andere twee waren bedoeld voor code signing.
Vervalst certificaat kan een server nabootsen
Een TLS-certificaat helpt software controleren of zij werkelijk verbinding maakt met de bedoelde server.
Bij een geldige keten vertrouwt de client erop dat bijvoorbeeld exchange.example ook werkelijk de server achter dat domein is.
Met een gecompromitteerde intermediate-sleutel kan een aanvaller een vervalst certificaat maken voor een domein dat hij niet bezit.
Cloudflare legt uit dat zo'n certificaat kan worden gebruikt om een server na te bootsen en verkeer te lezen of aan te passen wanneer de aanvaller de netwerkverbinding kan onderscheppen of omleiden.
De fout breekt dus niet de versleuteling van TLS zelf.
Het probleem zit in de controle van wie aan de andere kant van de versleutelde verbinding staat.
Chrome blokkeerde getroffen TLS-sleutels snel
Grote browsermakers konden relatief snel ingrijpen.
Chrome plaatste op 17 oktober de publieke sleutels van de zes getroffen TLS-intermediates in zijn CRLSet. Daarmee werden certificaten met die sleutels geblokkeerd zonder dat gebruikers eerst een volledige browserupdate hoefden te installeren.
Firefox deed hetzelfde via OneCRL.
Mozilla meldt dat de blokkade minder dan drie uur na ontvangst van de melding naar normale Firefox-installaties was uitgerold.
Voor een gewone browsergebruiker verkleint dat het risico sterk.
Voor alle andere software op hetzelfde apparaat volgt die bescherming niet automatisch.
Een handelsbot kan een andere trust store gebruiken
Daar zit het belangrijkste punt voor crypto.
Een browser heeft zijn eigen methode voor het controleren van certificaten en het snel blokkeren van onbetrouwbare sleutels.
Een trading bot kan iets anders gebruiken.
Dat kan de certificaatverificatie van het besturingssysteem zijn, maar ook een HTTP-library, een programmeertaalruntime of een eigen verzameling vertrouwde certificaten.
Cloudflare waarschuwt ontwikkelaars daarom expliciet om onder de SDK te kijken.
Een update van de bovenliggende applicatie verandert niet noodzakelijk de controle die diepere softwarecomponenten uitvoeren.
Browser groen, bot nog kwetsbaar
Dat levert een verraderlijke situatie op.
Een medewerker kan hetzelfde API-domein in Chrome openen en zien dat de browser het verdachte certificaat correct afwijst.
De handelssoftware kan via een andere certificaatketen alsnog verbinding maken.
Cloudflare schrijft daarom dat een geslaagde browsertest niet bewijst dat een achtergrondservice beschermd is.
Zelfs een test met curl bewijst alleen iets over een toepassing die dezelfde verifier gebruikt.
De echte test moet via het TLS-pad van de applicatie zelf lopen.
Exchange-API's maken dit relevant voor crypto
Veel geautomatiseerde cryptohandel verloopt via API's van exchanges.
Een bot maakt daarbij voortdurend HTTPS-verbindingen om prijzen op te halen, posities te bekijken en orders te versturen.
Wanneer een aanvaller zo'n verbinding kan omleiden én de client een vervalst eMudhra-certificaat nog vertrouwt, kan hij proberen zich voor te doen als de echte API.
Dat betekent niet automatisch dat hij toegang krijgt tot alles.
API-rechten, aanvullende authenticatie, IP-beperkingen en ondertekening van verzoeken kunnen extra verdedigingslagen vormen.
Maar een foutieve serveridentiteit breekt wel een fundamentele veiligheidsaanname.
Ook stortingsadressen kunnen doelwit worden
Voor crypto ontstaat nog een specifiek aanvalspad.
Stel dat een applicatie via HTTPS een stortingsadres van een platform opvraagt.
Een aanvaller die de verbinding succesvol nabootst, zou kunnen proberen dat antwoord te vervangen door een eigen adres.
Bij een wallet of betaalinterface kan hetzelfde principe worden gebruikt om informatie te manipuleren voordat de gebruiker een transactie goedkeurt.
Wang noemt zulke scenario's als mogelijke gevolgen.
Het zijn geen aangetoonde schadegevallen uit het eMudhra-incident.
Certificaatsleutels zijn geen wallet-privatekeys
Dat onderscheid is belangrijk.
De gecompromitteerde sleutels horen bij certificaatautoriteiten.
Het zijn niet de privésleutels waarmee bezitters hun Bitcoin, Ethereum of andere crypto uitgeven.
Wie een eMudhra-sleutel heeft, krijgt daardoor niet rechtstreeks toegang tot een cryptowallet.
De aanvaller moet bovendien verkeer kunnen onderscheppen of omleiden om de vervalste identiteit tegen een slachtoffer te gebruiken.
Een gecompromitteerd certificaat alleen verplaatst dus geen coins.
Google zag extra bescherming via Certificate Transparency
Chrome had nog een tweede verdedigingslaag.
Google meldt dat vóór de blokkade geen TLS-certificaten die via de zes getroffen intermediates liepen in Certificate Transparency-logs waren opgenomen.
Chrome vereist standaard zo'n geldige CT-registratie voor publiek vertrouwde certificaten.
Volgens Google konden frauduleuze certificaten via deze getroffen intermediates daarom vóór de CRLSet-blokkade niet standaard door Chrome worden vertrouwd.
Dat zegt specifiek iets over clients die zulke CT-regels afdwingen.
Software die Certificate Transparency niet op dezelfde manier controleert, kan opnieuw een ander risicoprofiel hebben.
Cloudflare vond geen actief misbruik op eigen diensten
Ook bij de schadeclaims is voorzichtigheid nodig.
Cloudflare zegt na eigen onderzoek geen actief misbruik op zijn diensten te hebben gevonden.
Dat is geruststellend, maar smaller dan de uitspraak dat de zwakke certificaten nergens zijn misbruikt.
Cloudflare kan alleen zeggen wat het binnen zijn eigen diensten en waarnemingen heeft vastgesteld.
Het incident blijft daarom in de eerste plaats een aangetoonde mogelijkheid tot serverimitatie, gevolgd door snelle blokkades.
Niet een bevestigde grootschalige aanval op cryptogebruikers.
Certificaten intrekken is niet voor iedere client genoeg
eMudhra heeft de getroffen intermediates ingetrokken.
Maar software verwerkt zo'n intrekking niet overal op dezelfde manier.
Sommige clients halen actuele revocatiegegevens op of ontvangen snelle blokkeerlijsten.
Andere toepassingen werken met een lokaal trustbestand dat pas verandert na een software- of pakketupdate.
Red Hat waarschuwt bijvoorbeeld dat systemen de vervalste certificaten kunnen blijven vertrouwen totdat de gebruikte certificaatbundel is bijgewerkt.
Juist servers, containers en lang draaiende bots kunnen daardoor meer controle vragen dan een browser die centraal een nieuwe blokkeerlijst ontvangt.
Certificaatfout negeren maakt het juist erger
Een update kan ook een nieuw praktisch probleem veroorzaken.
Na het blokkeren van de eMudhra-keten kan oudere software plots certificaatfouten tonen.
De gevaarlijkste reactie is dan om certificaatverificatie volledig uit te schakelen zodat de applicatie weer werkt.
Cloudflare waarschuwt daar rechtstreeks tegen.
Zonder verificatie controleert de applicatie immers helemaal niet meer of zij met de echte server communiceert.
Een storing verdwijnt dan uit beeld door precies de beveiliging te verwijderen die imitatie moet tegenhouden.
Cryptobedrijven moeten per applicatie testen
Voor een cryptobedrijf is “onze website werkt veilig in Chrome” daarom geen volledige controle.
De relevante vraag is welke software daadwerkelijk verbinding maakt met externe diensten.
Denk aan handelsbots, prijsfeeds, walletdiensten, betalingsprocessen, interne scripts en API-clients.
Voor elk daarvan telt welke TLS-library en trust store werkelijk worden gebruikt.
Cloudflare adviseert daarnaast om na updates ook containers opnieuw te bouwen en diensten te herstarten wanneer dat nodig is. Een gepatcht pakket op schijf beschermt immers niet altijd een proces dat nog met een oude versie draait.
De browserfix en de botfix zijn twee verschillende controles
Het eMudhra-incident legt daarmee een bredere fout in beveiligingsdenken bloot.
“Dit apparaat is bijgewerkt” is niet hetzelfde als “iedere applicatie op dit apparaat gebruikt dezelfde veiligheidsregels”.
Chrome en Firefox konden de getroffen sleutels snel centraal blokkeren.
Een zelfstandig draaiende cryptobot kan nog een eigen certificaatbundel, runtime of TLS-library gebruiken en daarmee buiten die bescherming vallen.
Voor crypto ligt het risico niet in een magische route naar privésleutels.
Het zit in iets fundamentelers: software die denkt dat zij veilig met een exchange, API of walletdienst praat, terwijl zij de verkeerde server vertrouwt.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
