Nieuwe kwetsbaarheden in DNS maken DNSSEC-validatie noodzakelijk

Afgelopen weken zijn er twee wetenschappelijke studies verschenen die nieuwe kwetsbaarheden in het DNS-systeem beschrijven. Daarnaast zijn er wederom een aantal registrars en registrar resellers gehackt wat duidelijk maakt dat DNS en de provisioning van DNS steeds vaker doelwit is van aanvallen op de internetinfrastructuur. Er zijn veel individuele kwetsbaarheden om bij te houden. Er is echter wel een ding dat professionele internetinfrastructuurleveranciers kunnen doen om niet vatbaar te zijn voor een toenemend aantal kwetsbaarheden. Door DNSSEC en validatie te doen op DNS-resolvers, zijn de meeste aanvallen niet mogelijk.

Een eerste nieuwe kwetsbaarheid waar we op werden geattendeerd betreft het vatbaarder zijn van resolvers voor “cache pollution” aanvallen omdat authoritative nameservers “response rate limiting” (RRL) hebben geïmplementeerd om DNS amplification attacks af te slaan.

De nieuwe DNS-kwetsbaarheid maakt misbruik van deze RRL door een resolver die men wil aanvallen bewust in de blacklist op te laten nemen van de authoritative server, waardoor deze tijdelijk geen of minder antwoorden krijgt. Dit vergroot het aanvalsvenster op die resolver om een cache pollution aanval uit te voeren. Een uitgebreide beschrijving van de aanval wordt binnenkort uitgelegd op de aanstaande DNS-OARC conferentie en op DNSSEC.nl.

In eerste instantie was de conclusie van de onderzoekers dat het bij RRL niet verstandig was om geen antwoord te geven, en altijd uit te nodigen om een vraag opnieuw te stellen via TCP door de zogenaamde slip factor in de RRL configuratie op 1 te zetten. Daarnaast was het verstandig om DNSSEC-validatie te doen, want dan zou een resolver niet vatbaar zijn voor cache pollution.

Met die tweede conclusie zijn we het volmondig eens, maar de eerste conclusie is niet levensvatbaar. DNS amplification attacks zijn immers aan de orde van de dag, en de kosten van zo’n aanval zijn evenredig met de antwoorden die worden gegeven. Zonder DNSSEC-validatie op je resolver ben je kwetsbaar voor deze aanval. Daar is niets nieuws aan. Een zoveelste pleister plakken op de authoritative server maakt het DNS niet veiliger maar enkel complexer, en er zal weer een nieuwe aanval worden verzonnen waar ook deze pleister niet helpt. De onderzoekers hebben daarom hun conclusie aangepast en DNSSEC-validatie door resolvers als eerste aanbeveling opgenomen om deze nieuwe kwetsbaarheid tegen te gaan.

Nog voordat het eerste onderzoek openbaar werd, kwam er inderdaad al weer een ander onderzoek uit, waar ook een nieuwe DNS-kwetsbaarheid werd beschreven. Deze kwetsbaarheid wordt gedeeltelijk veroorzaakt door DNSSEC, maar DNSSEC en validatie door de resolvers is ook hier de enige duurzame oplossing.

Deze aanval maakt gebruik van het feit dat DNS-antwoorden die te groot worden om in 1 UDP-pakket te passen worden gefragmenteerd over meerdere UDP-fragmenten. In het pad tussen een authoritative server en een resolver staat vaak nog verouderde netwerkapparatuur, of wordt IP-verkeer getunneld over andere netwerken, en die netwerken kunnen grotere pakketten niet aan. Een typische waarde voor deze zogenaamde path MTU is 1280 bytes. Een UDP-pakket dat groter is, wordt op netwerkniveau alsnog gefragmenteerd.

De kwetsbaarheid, die beschreven wordt in arxiv.org/pdf/1205.4011v1.pdf bestaat er uit dat het tweede deel van zo’n gefragmenteerd UDP-pakket eenvoudig te vervalsen is. Doordat de controle bits over de juistheid van het DNS-antwoord zonder DNSSEC enkel in het eerste UDP-fragment aanwezig zijn, is de inhoud van het tweede fragment gemakkelijk te raden, en dus ook te vervalsen.

Ook hier wordt als conclusie in eerste instantie een pleister voorgesteld. Zorg dat authoritative DNS-servers geen DNS-antwoorden middels EDNS0 onderhandelen die groter zijn dan de path MTU zodat er geen fragmentatie plaatsvindt. Maar dat is erg onvoorspelbaar, en afhankelijk van het pad tussen de twee nameservers. Ook hier is DNSSEC en validatie een betere oplossing, want een validerende resolver zal meteen merken als er met het DNS-antwoord is geknoeid. Deze aanval werkt dus niet als je resolver valideert.

En tenslotte hadden we natuurlijk ook de hack van New York Times en Twitter doordat de credentials van een reseller van registrar Melbourne IT in verkeerde handen waren gevallen. Velen menen dat DNSSEC daar geen oplossing was geweest. Ik ben het daar slechts gedeeltelijk mee eens. Met DNSSEC was het niet meer voldoende geweest om enkel de nameservers aan te passen in de delegatie. Ook het DS-record moet worden verwijderd of vervangen bij de registry, en dat gaat meestal niet onopgemerkt. Bovendien duurt het enige tijd voordat dat is gepropageerd in caching resolvers. Bij tijdige detectie door goede monitoring kan DNSSEC dus zorgen dat er gedurende de TTL van het DS-record (bij SIDN twee uur) actie kan worden ondernomen.

Ook hier zou ik als ISP kiezen om mijn klanten te beschermen door een resolver te laten valideren, en liever geen dan een vervalste website aan te bieden. De vraag is natuurlijk of de twee uur voldoende zijn om actie te ondernemen, en resolvers die de domeinnaam nog niet in hun cache hebben komen alsnog bij de verkeerde site uit. Maar de omvang van de aanval wordt in ieder geval beperkt.

Ook voor de meeste andere DNS-kwetsbaarheden is validatie op de resolver de enige uitweg.
Op dnssectest.sidn.nl/test.php kan gecontroleerd worden of de resolver op je lokale netwerk valideert. Het aantal aanvallen op de DNS-infrastructuur neemt toe, en voorkomen van een aanval is beter en goedkoper dan genezen.


Antoin Verschuren is sinds 2005 technisch adviseur bij SIDN.

Dit artikel verscheen op 11 september 2013 op SIDN Labs en is met toestemming gepubliceerd op ISP Today.