28 oktober 2013
Nieuwe kwetsbaarheden in DNS maken DNSSEC -validatie noodzakelijk
In de afgelopen weken zijn er twee wetenschappelijke studies verschenen die nieuwe kwetsbaarheden in het DNS-systeem beschrijven. Daarnaast is er wederom een aantal registrars en registrar resellers gehackt, wat duidelijk maakt dat DNS en de provisioning van DNS steeds vaker doelwit zijn van aanvallen op de internet-infrastructuur.
Er zijn al veel individuele kwetsbaarheden om bij te houden. Er is echter wel één ding dat professionele internet-infrastructuurleveranciers kunnen doen om niet vatbaar te zijn voor een toenemend aantal kwetsbaarheden. Door DNSSEC-validatie te doen op DNS resolvers, zijn de meeste aanvallen niet mogelijk.
Response Rate Limiting
Een eerste nieuwe kwetsbaarheid waar we op werden geattendeerd, betreft het vatbaarder zijn van resolvers voor "cache pollution" omdat authoritative nameservers "Response Rate Limiting" (RRL) hebben geïmplementeerd om DNS amplification aanvallen af te slaan. Bij zo'n aanval wordt het afzend-adres van een DNS-vraag vervalst met die van het slachtoffer, zodat een aanvaller er voor kan zorgen dat het slachtoffer heel veel DNS-verkeer van grote antwoorden krijgt.
Het afgelopen jaar was er een stormvloed aan DDOS-aanvallen (Distributed Denial-Of-Service) die gebruik maakten van DNS amplification. In reactie daarop hebben veel DNS-operators, waaronder ook die voor .nl, een RRL-filter op hun DNS-servers moeten zetten. Wat RRL doet, is het tijdelijk niet beantwoorden van DNS-vragen van adressen die het te bont maken, en dus waarschijnlijk bezig zijn met het misbruiken van DNS voor amplification attacks. Zodra een adres een vraag te vaak stelt waarvan een normale resolver het antwoord eigenlijk al zou moeten weten, zorgt het RRL-filter dat dat adres tijdelijk geen antwoord krijgt op zijn vragen, of wordt uitgenodigd om zijn vragen opnieuw over TCP in plaats van UDP te stellen om vast te stellen dat de vragen niet vervalst zijn.
Cache pollution
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 de resolver tijdelijk geen of minder antwoorden krijgt. Dit vergroot het aanvalsvenster op die resolver om een cache pollution aanval uit te voeren. Daarbij probeert de aanvaller een vervalst DNS-antwoord in de caching resolver op te laten nemen om zo een gebruiker om te leiden naar een ander adres met een vervalste website. De aanvaller krijgt het voor elkaar om een resolver in de blacklist op te laten nemen door veel vervalst verkeer naar de authoritative server met RRL te sturen, zodat het lijkt alsof de resolver is betrokken in een amplification attack. Een uitgebreide beschrijving van de aanval wordt binnenkort uitgelegd op de aanstaande DNS-OARC conferentie.
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.
Pleister plakken
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. En die kosten worden gedragen door de authoritative nameserver operators. Bij een aanval gaan die hun eigen defensie niet verlagen om infrastructuur van anderen te beschermen.
Daarnaast is deze aanval een zoveelste variant waarbij het pleister plakken enkel diegene beschermt die niet bereid zijn om DNS daadwerkelijk veiliger te maken door validatie aan te zetten op hun resolver. Hun insteek is dan ook dat wie niet luisteren wil moet voelen. Zonder DNSSEC-validatie op de 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.
UDP-fragmentatie
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 één UDP-pakket te passen worden verdeeld over meerdere UDP-fragmenten. Oorspronkelijk was een DNS-antwoord maximaal 512 bytes groot, maar doordat DNS-antwoorden in de loop der tijd — mede door DNSSEC — steeds groter zijn geworden, passen die niet meer in 512 bytes. Inmiddels mogen DNS-antwoorden die gebruik maken van de DNS-extensie EDNS0 groter zijn dan 512 bytes, onderhandelbaar tussen DNS-servers tot wel 4096 bytes.
Maar dat is alleen wat de betrokken servers denken dat ze aankunnen wat DNS-pakketten betreft. In het pad tussen een authoritative server en een resolver staat vaak nog verouderde netwerkapparatuur zoals routers, switches en firewalls, of wordt IP-verkeer getunneld over andere netwerken, en die netwerken kunnen de grotere pakketten niet aan. Een typische waarde voor deze zogenaamde path MTU is 1280 bytes als minimale grootte voor IPv6. Op Ethernet-niveau is 1500 bytes een typische MTU, en op sommige IPv4 netwerken met verouderde firewalls is 512 bytes nog steeds de maximale grootte. Een UDP-pakket dat groter is, wordt op netwerk-niveau dan alsnog gefragmenteerd.
Geen antwoord
De kwetsbaarheid, die beschreven wordt in dit document 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 aan te passen.
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. Bovendien zal het beperken van de grootte van de DNS-antwoorden leiden tot meer pakketten en dus netwerkverkeer. Wederom is DNSSEC en validatie een betere oplossing, want een validerende resolver zal meteen merken als er met het DNS-antwoord is geknoeid. Deze kwetsbaarheid werkt dus niet als je resolver valideert. Je krijgt dan geen antwoord in plaats van een vervalst antwoord als er onderweg met het DNS-antwoord is geknoeid.
Registrar credentials
En tenslotte hadden we natuurlijk ook de hack van de New York Times en Twitter doordat de wachtwoorden van een reseller van registrar Melbourne IT in verkeerde handen waren gevallen. Ook SIDN had recent een geval waar bij een registrar credentials voor domeinnaamregistratie waren gestolen, en bij SIDN waren gebruikt om delegaties aan te passen. 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. Het simpelweg toevoegen van een DS record om ongemerkt te verhuizen gaat al helemaal niet, want daarvoor is het het nodig dat een nieuwe DNSKEY wordt opgenomen in de oude zone die de aanvaller niet onder controle heeft. Bij tijdige detectie door goede monitoring kan DNSSEC dus zorgen dat er gedurende de TTL van het DS-record (bij .nl 2 uur) actie kan worden ondernomen om de schade te beperken.
Voorkomen beter dan genezen
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 die 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 kan in ieder geval worden beperkt. Waar ik het mee eens ben is dat met DNSSEC niet te voorkomen is dat een delegatie moedwillig wordt stukgemaakt als de credentials van een registrar in verkeerde handen vallen. Ik verwacht dan ook dat registrars steeds zorgvuldiger worden met die credentials, en dat registrants ook steeds kritischer worden in hun keuze van registrar en DNS-operators aan wie ze hun zone-beheer uitbesteden. Want de eenvoudigste hack die overblijft is natuurlijk rechtstreeks indringen in het provisioning systeem van de zone zelf. Tegen die kwetsbaarheid helpt zelfs DNSSEC niet.
Voor de meeste andere DNS-kwetsbaarheden, bestaande en nog uit te vinden door Kaminski-wannabees, is validatie op de resolver de enige uitweg. Zet daarom validatie op je resolver zo snel mogelijk aan. Op http://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.
Auteur: Antoin Verschuren
