DNS protocol onveilig

Het recentelijk ontdekte lek in het DNS protocol blijft de gemoederen beroeren. Het blijkt namelijk dat er nog steeds veel ongepatchte nameservers op internet actief zijn. Deze servers zijn vatbaar voor een aantal nieuwe exploits waarmee de DNS cache van resolving nameservers binnen seconden kan worden vervuild. Hierdoor zijn hackers in staat om internetverkeer om te leiden naar hun eigen servers.

Je denkt dus dat je inlogt op de website van je bank, terwijl je in werkelijkheid je vertrouwelijke gegevens afgeeft aan een hacker. Kortom, een behoorlijk probleem met grote risico’s. De hoogste tijd dus om eens te bekijken wat er precies aan de hand is.

De ontdekker van het lek Dan Kaminsky was oorspronkelijk van plan de details van het lek pas vrij te geven op de Blackhat Conferentie in Las Vegas. Op deze manier wilde hij bedrijven en open source communities tijd geven het lek te dichten zodat beheerders hun systemen konden patchen voordat het lek alom bekend zou worden en hackers ermee aan de haal zouden gaan. Hij verzocht de security gemeenschap dan ook om nog even het mondje dicht te houden en niet publiekelijk te speculeren over het door Kaminsky ontdekte lek.

Hacker Halvar Flake was het echter niet eens met het door Kaminsky voorgestelde proces, en ging aan de slag met het reverse engineeren van een aantal uitgebrachte patches om er op deze manier achter te komen wat het lek was. Dat is hem gelukt met als gevolg dat de details van het lek bekend werden.

Ook bij security bedrijf Matasano liep het niet helemaal soepel. Een aantal personen hadden moeite om het mondje dicht te houden (of waren niet op de hoogte van de afspraken met Kaminsky) waardoor er informatie werd gepubliceerd op de website. Vóór en na de bekendmaking door Flake verschenen er details op het blog van Matasano. Er werd vlug ingegrepen; blogposts werden offline gehaald en excuses werden aangeboden. Maar toen was het natuurlijk al te laat; de informatie rouleerde al over internet.

De publicatie van Flake en de fouten bij Matasano waren voldoende aanleiding voor Dan Kaminsky om niet te wachten tot de Blackhat conferentie, maar zijn bevindingen online te presenteren. Hierna was het een kwestie van tijd voordat de eerste exploits verschenen. De een nog gevaarlijker dan de ander. Sommige exploits werden zelfs toegevoegd aan de hackertoolkit Metasploit. Op dit moment is er zelfs sprake van nieuwe exploits die bij de security gemeenschap nog niet bekend waren.

Het is een beetje een open deur, maar ik adviseer iedereen die een nameserver beheert zo spoedig mogelijk te patchen. Het blijkt echter dat het toepassen van de huidige beschikbare patches het probleem niet oplost. Zo kan de configuratie van een firewall nog roet in het eten gooien. De huidige patches zorgen er namelijk voor dat resolving nameservers een willekeurig in plaats van een vast IP-poortnummer gebruiken voor het bevragen van authoritative nameservers. Het wordt voor hackers dan moeilijker het poortnummer te ‘raden’, waardoor het de vraag aan de authoritative nameserver niet kan worden onderschept (om vervolgens een vervalst antwoord terug te kunnen sturen). Een firewall kan echter zodanig zijn geconfigureerd dat deze het aantal te gebruiken poortnummers beperkt. Hierdoor wordt het effect van de toegepaste patch weer grotendeels ongedaan gemaakt.

Ondanks het feit dat een firewall dus roet in het eten kan gooien, is het ook mogelijk de firewall te gebruiken om ongepatchte systemen minder kwetsbaar te maken. Gebruikers van iptables kunnen een specifieke rule aan het firewall script toevoegen die er (net als de patch) voor zorgt dat het gebruikte IP-poortnummer willekeurig wordt. Hiervoor is wel minimaal kernel 2.6.24 nodig.

Naast het probleem met het poortnummer is er ook nog het probleem van het identificatienummer. Elke keer wanneer een resolving nameserver een authoritative nameserver bevraagd, wordt er een willekeurig identificatienummer gebruikt als een vorm van beveiliging. Ditzelfde nummer moet door de authoritative nameserver worden terug gestuurd bij het antwoordbericht. Als dit niet zo is dan negeert de resolving nameserver het binnen gekomen antwoord. Het identificatienummer is 16 bits lang, met als gevolg dat er grofweg 65000 mogelijke nummers zijn. Critici hebben al eerder geroepen dat dit te weinig mogelijkheden zijn, omdat het voor de snelle computers van tegenwoordig een koud kunstje is om in zeer korte tijd alle mogelijke identificatienummers te genereren; een zogenaamde brute-force-attack. Echter, volgens Kaminsky is het mogelijk om deze identificatienummers nog veel sneller te raden (details hierover heb ik niet kunnen vinden).

De laatste uitdaging waar een hacker tegenaan loopt, is dat het vervalste antwoordbericht sneller bij de resolving nameserver moet aankomen dan het antwoord van de authentieke authoritative nameserver. In het verleden lag hier vaak de bottleneck, maar doordat het poortnummer en identificatienummer nu zoveel sneller te ‘raden’ zijn, zijn er veel minder foutieve valse antwoorden nodig waardoor de kans op een succesvolle hack veel groter wordt.

Het gevaar is dus nog niet helemaal geweken, omdat de huidige patches alleen het probleem van het poortnummer oplossen. Het lijkt erop dat er eerst goed nagedacht gaat worden over een definitieve oplossing alvorens er weer nieuwe patches worden uitgebracht. Ik ben erg benieuwd naar de afloop van dit hele verhaal dus ik zou zeggen: wordt vervolgd…

(Intussen is dit natuurlijk een prima aanleiding om het huidige patchmodel te bekritiseren en de aandacht te vestigen op het betere en goedkopere secure-by-design principe.)