Een slot met heel veel sleutels: spoofing van met DNSSEC ondertekende domeinen in 8.8.8.8
Google fikste de kwetsbaarheid naar aanleiding van onze melding
Kies jouw kleur
Veel bezocht
Veelgestelde vragen
Via de Whois kun je de huidige houder van een domeinnaam opzoeken. Om de persoonsgegevens in te zien moet je vanwege de privacygevoelige informatie eerst de gebruikersvoorwaarden van de Whois accepteren. Gegevens van privé personen kunnen ook afgeschermd zijn vanwege de AVG (Algemene verordening gegevensbescherming).
Op de pagina domeinnaam zoeken lees je meer over wat een domeinnaam is, de werking van de Whois en de privacy van persoonsgegevens.
Je wilt je domeinnaam verhuizen naar een andere registrar. Vraag dan je verhuistoken op bij je huidige registrar. Lees de verhuisstappen op de pagina domeinnaam verhuizen.
Neem contact op met je registrar. Jouw registrar kan de contactgegevens bij je domeinnaam voor je aanpassen. Wij raden je aan het resultaat te controleren via de Whois. Lees meer over het aanpassen van je gegevens bij contactgegevens wijzigen.
Wij weten niet wat de reden van de opheffing is. Neem contact op met je registrar. Het voordeel van de quarantaine is dat je altijd de mogelijkheid hebt om een opheffing die je niet had bedoeld te herstellen.
Voorbeeld: In de voorwaarden van je registrar staat dat je elk jaar je abonnement moet verlengen. Dat gebeurt dan niet automatisch. Zo kan het gebeuren dat je domeinnaam wordt opgeheven zonder dat je er om gevraagd hebt.
Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.
Wil je zelf direct domeinnamen kunnen registreren bij SIDN voor je klanten of voor je eigen organisatie? Dan kun je .nl-registrar worden. Lees meer over de voorwaarden en de manier waarop je je kunt inschrijven als registrar via de pagina registrar worden.
Domeinnamen
Google fikste de kwetsbaarheid naar aanleiding van onze melding
De oorspronkelijke blog is in het Engels. Dit is de Nederlandse vertaling. We ontdekten dat Google Public DNS tot voor kort in theorie kwetsbaar was voor een DNS-cache-poisoning-aanval op met DNSSEC ondertekende domeinnamen. Een bug in de code die verantwoordelijk is voor het valideren van met DNSSEC ondertekende records maakte het technisch mogelijk om de populaire DNS-resolvingservice van Google om de tuin te leiden en vervalste DNS-bronrecords te laten accepteren voor met DNSSEC ondertekende domeinnamen. Daardoor zouden downgrade-aanvallen kunnen worden uitgevoerd, omdat voor, in potentie, miljoenen gebruikers de DNSSEC-bescherming zou kunnen worden omzeild. Op 12 januari stelden we Google hiervan op de hoogte en op 23 februari was er over de gehele linie een oplossing uitgerold. Google gaat ervan uit dat de kwetsbaarheid niet is misbruikt, omdat het bedrijf verschillende algemene beveiligingen tegen cachevervuiling heeft. Het is belangrijk om te benadrukken dat wat we ontdekten geen kwetsbaarheid was in het DNSSEC-protocol zelf, maar een kwetsbaarheid in een specifieke implementatie van DNSSEC. Voor zover we weten, werden alleen de resolvers van Google Public DNS erdoor geraakt.
Het Domain Name System (DNS) is niet ontworpen met veel aandacht voor de veiligheid. Dat werd in 2008 al gedemonstreerd met de gedenkwaardige Kaminsky-aanval. In dat jaar toonde Dan Kaminsky aan dat een off-path-aanvaller kwaadaardige antwoorden in de cache van een recursieve resolver kon plaatsen. Een dergelijke aanval kan ernstige gevolgen hebben. Elke client van een recursieve resolver zou bijvoorbeeld naar een schadelijke domeinnaam kunnen worden geleid. Naar aanleiding van Kaminsky's bevinding raakte de invoering van DNSSEC (DNS Security Extensions) in een stroomversnelling. Met DNSSEC kunnen domeinnaambeheerders de inhoud van hun DNS-zones voorzien van een cryptografische handtekening. Een recursieve resolver kan deze cryptografische handtekeningen weer valideren en zo cache-poisoning-aanvallen detecteren en gebruikers daartegen beschermen. Tegenwoordig ondertekenen veel DNS-operators hun domeinnamen en een toenemend aantal recursieve resolvers valideert DNSSEC-records, waardoor miljoenen gebruikers worden beschermd tegen cache-poisoning-aanvallen. De technologie wordt op grote schaal gebruikt in .nl, bekijk bijvoorbeeld https://stats.sidnlabs.nl/nl/dnssec.html#dnssec%20queries. Google Public DNS, beter bekend onder het IPv4-adres 8.8.8.8, valideert ook DNSSEC-records. Momenteel is 8.8.8.8 verantwoordelijk voor meer dan 15% van alle DNS-query's die door de nameservers van .nl worden ontvangen.
We vonden een aanvalsvector waarmee een kwaadwillende partij in theorie de resolvers van Google zou kunnen hebben misleiden tot het accepteren van vervalste DNS-antwoorden die betrekking hadden op met DNSSEC ondertekende domeinnamen. Als een aanvaller erin was geslaagd de cache van de Google-resolver te vervuilen met niet-ondertekende DNS-antwoorden, had deze daarna ook ondertekende domeinnamen kunnen vervalsen. De feitelijke oorzaak lag bij de manier waarop Google Public DNS omging met onbekende DNSSEC-sleutels. Het kwam erop neer dat alleen al het aanbieden van een willekeurige cryptografische sleutel genoeg was om Google Public DNS een vals antwoord te laten accepteren.
Normaal gesproken mag een handtekening pas worden gevalideerd als een recursieve resolver er zeker van is dat deze met een geldige sleutel is gemaakt. Zonder die zekerheid moet de handtekening als 'bogus' (vals) worden aangemerkt, wat betekent dat het antwoord niet kan worden vertrouwd. De resolver moet dan een SERVFAIL-foutcode retourneren aan de client waarvan de query afkomstig was. De manier waarop een resolver DNSSEC-records behoort te valideren, wordt hieronder geïllustreerd aan de hand van onze eigen domeinnaam sidnlabs.nl en de DNSSEC-debugger DNSviz (zie Figuur 1). In het voorbeeld zijn de records voor sidnlabs.nl ondertekend met een Zone Signing Key (ZSK) met key id 20853, die weer is ondertekend met de Key Signing Key (KSK) met id 52720. De KSK is gekoppeld aan de .nl-zone via het DS-record, waardoor een vertrouwensketen ontstaat. Na ontvangst van het AAAA-record voor sidnlabs.nl en de bijbehorende handtekeningen haalt een validerende resolver de sleutelset met de ZSK en KSK op.
Figuur 1: De met DNSSEC ondertekende domeinnaam sidnlabs.nl, zoals gezien in DNSViz.
De resolver moet de ontvangen sleutelset valideren, d.w.z. controleren of deze klopt. Is dat het geval, dan gaat de resolver over tot het valideren van het AAAA-record. De resolver gebruikt de key id in de handtekening op het AAAA-record om de bijbehorende sleutel te identificeren. Als wordt vastgesteld dat de sleutel geldig is, gebruikt de resolver de sleutel om de handtekening van het AAAA-record te valideren en retourneert het record aan de client.
Figuur 2: Onjuist geconfigureerde domeinnaam servfail.nl, zoals gezien in DNSviz. De bronrecords zijn ondertekend met een niet-bestaande Zone Signing Key.
Google Public DNS was kwetsbaar in de laatste fase van het validatieproces. We ontdekten de kwetsbaarheid min of meer per ongeluk. We beheren de domeinnaam servfail.nl, die voor test- en foutopsporingsdoeleinden opzettelijk onjuist is geconfigureerd voor DNSSEC. DNSSEC kan op allerlei manieren onjuist worden geconfigureerd. Oorspronkelijk had servfail.nl handtekeningen die waren verlopen. Om redenen die buiten de context van dit artikel vallen, hadden we echter besloten om de configuratie te wijzigen, zodat het AAAA-record van servfail.nl nu wordt ondertekend met een onbekende sleutel. Figuur 2 toont de huidige configuratie van servfail.nl, waarbij de records worden ondertekend met de sleutel met id 45918. Als je echter goed kijkt, bestaat de sleutelset voor servfail.nl alleen uit de KSK met id 15438 en de ZSK met id 45916. Zoals DNSViz in de afbeelding laat zien, leidt de onjuiste configuratie ertoe dat de andere records van servfail.nl als vals worden aangemerkt (door middel van de rode kaders), wat betekent dat ze niet kunnen worden gevalideerd. Een validerende resolver die het AAAA-record voor servfail.nl opzoekt, zal de ZSK met id 45918 niet kunnen vinden en valideren en zou daarom de foutcode SERVFAIL aan clients moeten retourneren. Dat is wat resolvers met correct geïmplementeerde DNSSEC-validatie doen: als we het AAAA-record opzoeken met een validerende resolver zoals Quad9, wordt de foutcode SERVFAIL geretourneerd, zoals te zien is in Figuur 3.
Figuur 3: DNS-query m.b.t. het AAAA-record voor servfail.nl, verzonden met de validerende resolver van Quad9.
Helaas was dat niet de manier waarop de resolvers van Google Public DNS zich gedroegen. Toen we het AAAA-record voor servfail.nl opvroegen met behulp van 8.8.8.8, ontvingen we het daadwerkelijke AAAA-record (zie Figuur 4) in plaats van de foutcode.
Figuur 4: DNS-query m.b.t. het AAAA-record voor servfail.nl, verzonden met de validerende resolvers van Google Public DNS.
Let er ook op dat 8.8.8.8 geen AD-vlag retourneerde, wat aangeeft dat het antwoord niet was geauthentiseerd met DNSSEC. Bijgevolg zouden de resolvers van Google als een record was ondertekend met een onbekende sleutel niet alleen een onjuiste configuratie over het hoofd gezien hebben, maar zouden de resolvers bovendien kwetsbaar zijn geweest voor downgrade-aanvallen. Als een aanvaller vervalste DNS-records in de cache van Google Public DNS weet te krijgen, zou hij zelfs met DNSSEC ondertekende records kunnen spoofen door te doen alsof de handtekeningen op de vervalste records waren gemaakt met sleutels die niet bestaan.
De potentiële impact van het vervalsen van met DNSSEC ondertekende records zou ernstiger zijn geweest dan bij het vervalsen van niet-ondertekende records. Een antwoord dat betrekking heeft op een niet-ondertekend record kan per definitie niet worden gevalideerd en moet daarom sowieso als onbetrouwbaar worden behandeld. Als een validerende resolver daarentegen een record voor een ondertekende domeinnaam ontvangt, wordt ervan uitgegaan dat het antwoord juist is en de verstrekte informatie betrouwbaar. De kwetsbaarheid die we hebben blootgelegd, ondermijnde die betrouwbaarheid.
SAD DNS: nieuwe 'DNS cache poisoning'-aanval ontdekt Nieuwe SAD DNS 'cache poisoning'-aanval op Domain Name System gepubliceerdDe praktische impact van de kwetsbaarheid is moeilijker in te schatten. Sinds de Kaminsky-aanval zijn er verschillende andere werkwijzen gepubliceerd die de kans vergroten dat een aanvaller de cache van een resolver vervuilt [1, 2]. Niettemin is het ons niet duidelijk hoe makkelijk het was om gespoofde antwoorden in de caches van Google Public DNS te krijgen. Ook hebben we uit ethische overwegingen niet actief geprobeerd de kwetsbaarheid te misbruiken. Google Public DNS werkt met een complexe cachearchitectuur, waardoor cachevergiftiging waarschijnlijk lastiger is dan bij kleinschalige recursieve resolvers.
Op 12 januari van dit jaar stelden we Google op de hoogte van de bug en op 23 februari hadden ze naar al hun instanties een oplossing uitgerold. De resolvers van Google retourneren nu ook SERVFAIL servfail.nl. Google zelf is ervan overtuigd dat het met al hun beveiligingen zeer onwaarschijnlijk is dat een cache-poisoning-aanval kans van slagen zou hebben. We wilden achterhalen of andere resolverimplementaties dan Google Public DNS mogelijk ook kwetsbaar waren voor een dergelijke aanval. Daarom namen we contact op met de ontwikkelaars van de DNS-softwarepakketten BIND, Unbound, Knot Resolver en PowerDNS Recursor. Nadat zij hun software hadden gecontroleerd, bleek dat geen van hun resolvers kwetsbaar was voor de beschreven aanvalsmethode. Ten slotte voerden we een grootschalige DNS-meting uit met behulp van 10.000 probes in het meetnetwerk RIPE Atlas. We wilden zien of we resolvers konden vinden die het AAAA-record van servfail.nl retourneerden, ook al valideerden ze DNSSEC. Net als de softwareontwikkelaars vonden we geen duidelijk bewijs dat er naast de resolvers van Google Public DNS nog andere resolvers waren die mogelijk kwetsbaar waren voor onze aanval.
Hoewel DNSSEC cruciaal is voor de beveiliging van het DNS, blijft het ook de meest gecompliceerde uitbreiding van het systeem. Dit incident is daar eens te meer het bewijs van. Ook kwamen we erachter dat andere ontwikkelaars van recursieve resolvers na onze wijziging van servfail.nl tegen een paar niet-kritieke corner cases aanliepen, die niets te maken hadden met de kwetsbaarheid bij Google. Net als bij andere beveiligingsprotocollen adviseren we ontwikkelaars en operators te vertrouwen op bestaande, goed geteste implementaties van DNSSEC, zoals de ldns-bibliotheek of een van de open-source recursieve resolvers, en niet op zelfgefabriceerde implementaties.
Voor het melden van deze bug ontvingen we $ 5.000 uit het ‘bug bounty’-programma van Google. We doneren dit bedrag aan een nader te bepalen goed doel. We danken Google voor hun open communicatie en voor het nalezen van dit artikel.
Moment | Gebeurtenis |
---|---|
Begin januari 2022 | We signaleren vreemd gedrag met betrekking tot ons onlangs geconfigureerde testdomein servfail.nl en Google Public DNS. We voeren tests uit om het probleem beter te begrijpen. |
12 januari 2022 | We dienen het probleem in bij de Issue Tracker van Google. |
13 januari 2022 | Google bevestigt het probleem. |
31 januari 2022 | Voor de volledigheid melden we het probleem ook bij Google als een kwetsbaarheid in de beveiliging. |
23 februari 2022 | Google verhelpt het probleem en rolt de oplossing uit. |
11 maart 2022 | Openbaarmaking via deze blog, met goedkeuring van Google. |
Artikel door:
Deel dit artikel