SAD DNS maakt cache poisoning opnieuw mogelijk

Met SAD DNS  wordt nieuw leven ingeblazen in de Kaminsky-aanval uit 2008, waarmee aanvallers DNS-caches kunnen vergiftigen met valse informatie.  De remedie die toen bedacht werd is nu onderuit gehaald: het blijkt mogelijk om via een slimme methode de uitgaande UDP-poort van de DNS resolver te achterhalen. Hoe gaat SAD DNS in zijn werk en hoe kan je het voorkomen?

DNS Cache poisoning: een oud zeer

Ter herinnering, en zoals beschreven door Cloudflare: het DNS-systeem en -protocol zorgen er, kort samengevat, voor dat domeinnamen in natuurlijke taal gekoppeld worden aan IP-adressen. Het DNS-protocol bestaat telkens uit een set boodschappen: een vraag of query en een antwoord of reply. Die boodschappen worden uitgewisseld over een netwerk tussen machines, door middel van een transport protocol. 

Het meest gebruikte transport protocol van DNS is UDP. UDP heeft als grote voordeel dat het snel en alomtegenwoordig is en geen sessie setup vereist. Maar zonder DNSSEC zit er geen authenticatie bij.  Wat eigenlijk betekent dat iedereen een antwoord op een request zou kunnen sturen met daarin valse informatie over het bijhorende IP adres. Dat zou niet mogelijk zijn met andere DNS-transportprotocollen zoals TCP, of zelf TLS of HTTPS .

Om te vermijden dat bij elke request opnieuw het bijhorende adres opgezocht moet worden in de DNS-tabellen, worden de resultaten van DNS-query's tijdelijk bewaard in de cache van caching name servers. Als een caching DNS server zo'n vals antwoord bijhoudt in zijn cache, dan spreken we van ‘DNS cache poisoning': deze valse informatie blijft in de cache bestaan zolang de TTL (Time To Live) duurt.

Dit fenomeen kan tot heel wat misbruiken leiden. Zo kunnen bezoekers die een domeinnaam intikken in hun browser , afgeleid worden naar een nagemaakte versie van de website die zij willen bezoeken bijvoorbeeld. Waar zij slachtoffer kunnen worden van fraude enz. 

Dergelijke aanvallen worden gericht tegen verschillende soorten servers in de DNS-hiërarchie die gebruik maken van DNS-caching. Dus zowel op het niveau van publieke DNS resolvers, van internet service providers en telecomoperatoren, bedrijven die een eigen resolver draaien als zelfs op home gateway niveau, de cache van particulieren. Op al deze niveaus bestaat het risico dat er valse records geïnjecteerd worden die de gebruiker naar onveilige websites afleiden.

Kaminsky-aanval in 2008 snel verholpen

Het DNS-systeem heeft eigenlijk wel degelijk een tactiek die tegen het vervalsen van de antwoorden moet beschermen: de eerste twee bytes in de boodschap moeten hetzelfde zijn in zowel query als respons. Toen in 2008 een methode gevonden om die ID's te raden, wat de naam Kaminsky-aanval kreeg, werd ook hiervoor een oplossing gevonden: source port randomization.. Door een willekeurige bronpoort te gebruiken, moest de aanvaller niet alleen de ID’s raden, maar ook die source poort. Wat het aantal pogingen die nodig zijn voor een succesvolle aanval van tienduizenden tot over een miljard bracht. Deze aanval werd dan ook minder interessant, en daarom werd deze aanvalsmethode de laatste jaren niet meer gebruikt.

SAD DNS blaast cache poisoning nieuw leven in

Recent hebben onderzoekers van de UC Riverside en Tsinghua University echter een nieuwe aanvalsmethode ontdekt: SAD DNS of Side Channel AttackeD DNS. Daarbij wordt misbruik gemaakt van ICMP rate limiting, een manier die moet voorkomen dat een server misbruikt wordt in een reflection aanval, door het aantal ICMP responses te beperken die een server in een bepaalde tijd zal geven. 

SIDN.nl legt duidelijk uit hoe het principe werkt. Stel dat de limiet op maximaal 1.000 berichten staat per seconde, dan kan de aanvaller alle 65.000 UDP-poorten afscannen in blokjes van duizend stuks, en zo zien in welk blok de uitgaande poort van de DNS-resolver zich bevindt. Daarvoor zendt hij eerst 1.000 valse DNS-responses vanop een nagemaakt adres naar alle poorten van dat blok. De ICMP-foutmeldingen zal hij niet zien, want die gaan naar dat vervalste adres. Maar als hij dan binnen diezelfde seconde ook nog eens een 1.001ste bericht stuurt, ditmaal vanop zijn eigen, echte IP-adres , en hij krijgt daarop toch ook nog een ICMP respons terug, dan weet hij dat de juiste poort binnen die reeks van duizend poorten ligt. Want het feit dat hij überhaupt een bericht terugkreeg, wil zeggen dat de limiet van duizend foutmeldingen niet bereikt was, en de juiste poort binnen die reeks van 1.000 poorten ligt.

Dit doet de port randomization bescherming tegen de Kaminsky-aanval teniet, want nu moet de aanvaller alleen nog maar de 65.000 verschillende transactie-ID's proberen te achterhalen.

Welke actie moet jij ondernemen?

De maintainers van de linux kernel hebben een patch uitgebracht die het probleem van de rate limits aanpakt door ze willekeurig te maken. 

Dit is echter enkel een ad-hoc oplossing. Een meer structurele manier om cache poisoning te voorkomen is het gebruik van DNSSEC. Want een niet-beveiligde resolver accepteert informatie zolang die maar op het juiste moment, via de juiste poort, en voorzien van de juiste transactie ID door de juiste afzender aangeboden wordt. Maar die kunnen geraden of gespoofd worden, zoals de naam van de afzender. 

Een resolver die met DNSSEC werkt (een validating resolver) zal echter die vervalste informatie niet aanvaarden, want hij zal ook afgaan op de juiste digitale handtekening.

Voor DNS cache-beheerders zoals telecomoperatoren, ISP's (home nat gateways), beheerders van bedrijfsnetwerken raden wij aan:

• Pas de kernel patch zo snel mogelijk toe (kernel versie > 5.10)
• Indien je niet kan upgraden naar de allerlaatste kernel dan kan je door middel van het blokkeren van uitgaande ICMP-berichten (meer bepaald, type ICMP port-unreachable) de SAD DNS attack ook onmogelijk maken.
• Indien je een caching resolver opereert achter een NAT-device (Network Address Translation) zoals routers, denk er dan ook aan deze NAT-toestellen te patchen (of een voorgenoemde workaround te implementeren). Ook via deze toestellen kan de aanval immers nog altijd uitgevoerd worden. Dat werd opgemerkt door onze eigen DNS Belgium-ingenieurs, en door het onderzoek bevestigd. Belangrijk om weten is dat deze attack vector via het NAT device werkt, zelfs indien de caching DNS resolver gepatched is (of een workaround geconfigureerd werd).
• Benadruk bij je klanten het belang van DNSSEC. Lees meer over DNSSEC en hoe DNS Belgium deze extra beveiliging implementeert.

Nota: In sommige resolver software zit al langer een extra detectiemechanisme voor cache poisoning: deze laat dan de DNS communicatie geforceerd terugvallen op het transport protocol, TCP. De SAD DNS attack wordt hierdoor ook onmogelijk. 

Voor domeinnaamhouders en internetgebruikers in het algemeen raden wij aan:

• Vraag bij je ISP of je registrar om DNSSEC te activeren. Dat is de ultieme oplossing om de integriteit van een look-up record te waarborgen, en zorgt ervoor dat bezoekers aan je website niet omgeleid kunnen worden. Je bezoekers moeten wel nog een DNSSEC validating resolver gebruiken om effectief te genieten van de bescherming die DNSSEC biedt.
• Bij de meeste aanbieders is DNSSEC voor domeinnamen wel degelijk mogelijk, en moet jij het enkel nog maar activeren.