Alle DNS-software en -diensten bleken kwetsbaar voor DoS-aanval

De KeyTrap-kwetsbaarheid [technisch rapport] werd eind vorig jaar ontdekt door onderzoekers van het Duitse National Research Center for Applied Cybersecurity (ATHENE). De oorzaak van het probleem is echter al meer dan 20 jaar oud: het vindt zijn oorsprong in RFC 2535, in 1999 gepubliceerd als de eerste versie van de moderne DNSSEC-beveiliging. Via de opvolgers van deze RFC kwam de kwetsbaarheid terecht in de implementaties van BIND9, Unbound, PowerDNS en andere resolversoftware.

Uitputtende evaluatie

De oorsprong van de KeyTrap-kwetsbaarheid zit in wat de onderzoekers "eager validation of signatures and of keys" noemen. Validerende resolvers moeten volgens de DNSSEC-standaard alle aangeboden handtekeningen (in een RRSIG-record) en alle bijbehorende publieke sleutels (in een DNSKEY-record) evalueren, net zolang tot ze een geldige ondertekening voor het betreffende DNS-record hebben gevonden. Uiteraard is dit gedaan om het DNSSEC-mechanisme zo robuust mogelijk te maken. De gelijktijdige publicatie/overlap van meerdere handtekeningen en meerdere publieke sleutels is ook een veelvoorkomend verschijnsel, dat optreedt bij elke herondertekening en rollover.

Het gaat mis bij de key tag, een 16-bits identificatie om de verschillende sleutelparen van elkaar te onderscheiden. Daarmee kan de resolver gelijk de juiste publieke sleutel pakken bij de evaluatie van een handtekening. Hoewel de key tag (pseudo-)random wordt gegenereerd – RFC 4034, appendix B schrijft een eenvoudige checksum voor – is deze niet afgedwongen uniek. Dat betekent dat 'key tag collissions' gewoon legaal kunnen voorkomen.

Een kwaadwillende kan deze vrijheid nu misbruiken door een DNS-record te publiceren met daarbij een hele rits handtekeningen van hetzelfde cryptografische type in combinatie met een hele rits sleutels die allemaal dezelfde key tag hebben. Als alle handtekeningen ongeldig zijn, zal de resolver dus eerst alle beschikbare handtekeningen voor alle beschikbare sleutels moeten evalueren alvorens tot die conclusie te mogen komen.

Omdat cryptografische operaties veel verwerkingskracht kosten – en dat geldt in het bijzonder voor de validatie van ECDSA-gebaseerde handtekeningen – zet deze combinatie de resolver dus flink aan het rekenen totdat alle combinaties geprobeerd zijn. Al die tijd kan de resolver nauwelijks of geen andere dingen doen, met een Denial-of-Service als resultaat. Een validerende resolver op hardware met beperkte verwerkingskracht bleek op deze manier wel 16 uur lang beziggehouden te kunnen worden.

Vanwege het gemak waarmee grote delen van het internet aangevallen konden worden, spreken betrokkenen van "de grootste kwetsbaarheid van DNS ooit ontdekt". Op hun bewering dat dit beveiligingsgat 25 jaar onopgemerkt bleef, blijkt echter wel wat af te dingen: In 2019 publiceerde Dex Bleeker over precies ditzelfde probleem. Hij optimaliseerde zijn sleutels echter niet voor maximale impact, waarmee hij wel een verhoogde load zag maar de resolver niet platlegde. [1]

De Wet van Postel

De bron van de KeyTrap-kwetsbaarheid ligt dus niet in de software, maar in het ontwerp van DNSSEC zelf. Sterker nog, deze blijkt een gevolg te zijn van een van de belangrijkste uitgangspunten bij de ontwikkeling van internetstandaarden: "Be conservative in what you send, and liberal in what you accept." Dit robuustheidsprincipe werd 45 jaar geleden bij het ontwerp van het Internet Protocol door Jon Postel geformuleerd in RFC 791 en staat inmiddels bekend als de Wet van Postel.

Uiteraard zijn er in de loop der tijd vanuit beveiligingsperspectief terechte kanttekeningen geplaatst bij het robuustheidsprincipe. Postel zelf nuanceerde dit uitgangspunt dan ook zelf in RFC 1122 als volgt: "assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect".

Ontwikkelaars van resolversoftware valt in deze niets te verwijten. De evaluatie van alle beschikbare handtekeningen en alle beschikbare sleutels met bijbehorende key tag is ingebakken in het DNSSEC-mechanisme (dat voorschrijft: doorgaan zolang geen geldige ondertekening is gevonden).

Platgelegd

De ontdekkers van de KeyTrap-kwetsbaarheid geven aan de afgelopen maanden samen met 31 verschillende partijen – softwareontwikkelaars, leveranciers, grote dienstaanbieders en mensen van de IETF – in stilte te hebben gewerkt aan een oplossing voor dit probleem. Alle door hun onderzochte resolvers en diensten bleken kwetsbaar, al zaten er wel grote verschillen tussen de implementaties. Door een enkel DNS-record te voorzien van 340 handtekeningen en 582 sleutels (op basis van algoritme 14: ECDSAP384SHA384) wisten zij de werklast voor een query met een factor 2 miljoen te verhogen. Daarmee bedroeg de tijd om het betreffende record te evalueren op een single-core processor meestal al een paar minuten (e.g. PowerDNS, Stubby, Akamai DNSi CacheServe), met uitschieters naar boven voor Unbound (ruim een kwartier) en BIND9 (16 uur!), en een uitschieter naar beneden voor Knot (één minuut). Al die tijd blokkeerden de resolvers voor verzoeken van andere clients, waarmee Internet voor de gebruikers daarvan onbereikbaar werd.

Multi-threading systemen konden net zo makkelijk aangevallen worden, door deze simpelweg meerdere van dergelijke geprepareerde DNS-records te laten evalueren. Alleen Akamai's DNSi CacheServe bleek clients nog uit de cache te kunnen beantwoorden, omdat deze via een aparte thread in de software bediend worden.

Op dezelfde manier bleken niet alleen veelgebruikte resolvers maar ook bekende tools (e.g. dig, delv, DNSViz), libraries (e.g. dnspython, ldns) en de grootste DNS-dienstverleners (Cloudflare, Google DNS, OpenDNS, Quad9) kwetsbaar voor deze aanval.

Geen structurele oplossing

Na enig experimenteren heeft de groep ervoor gekozen om het aantal sleutels met dezelfde key tag (per algoritme) te beperken tot 4. Een dergelijk aantal blijkt in de praktijk nooit voor te komen. Om ook weerstand te bieden aan aanvallen met behulp van een enkele sleutel in combinatie met een heleboel handtekeningen (SigJam), wordt in aanvulling het aantal ongeldige handtekeningen beperkt tot 16. Voor ANY-verzoeken worden maximaal 8 evaluaties uitgevoerd.

Deze beperkingen leiden bij een KeyTag-aanval nog steeds tot een verhoogde werklast, maar (ook met veel malafide aanvragen) niet meer tot het onbeschikbaar raken van de dienst (DoS).

Vanzelfsprekend is dit geen structurele oplossing voor de KeyTrap-kwetsbaarheid. Daarvoor zal de DNSSEC-standaard uiteindelijk aangepast moeten worden.

Zo snel mogelijk opwaarderen

De afgelopen weken is alle (open) resolversoftware op deze manier gepatcht voor de KeyTrap-kwetsbaarheid, die inmiddels officieel bekend staat als CVE-2023-50387. Meer informatie en de versienummers van de software vind je hier: Unbound, BIND9, PowerDNS, Akamai. Ook alle grote DNS-diensten zijn inmiddels beschermd tegen dit type aanvallen.

Beheerders van (validerende) resolvers wordt dringend aangeraden hun software zo snel mogelijk op te waarderen.