NXNSAttack, som påverkar alla DNS-resolverare

En forskargrupp från Tel Aviv-universitetet och det tvärvetenskapliga centret i Herzliya (Israel) har utvecklat en ny attackmetod NXNSAttack (PDF), som gör det möjligt att använda alla DNS-resolverare som trafikförstärkare och som möjliggör en förstärkningsgrad på upp till 1621 gånger antalet paket (för varje begäran som skickas till resolvern kan upp till 1621 begärningar sendas till offrets server)

Problemet är relaterat till protokollets arbetsmetod och påverkar alla DNS-servrar som stöder rekursiv begäran, inklusive BIND (CVE-2020-8616), Knot (CVE-2020-12667), PowerDNS (CVE-2020-10995), Windows DNS Server och Unbound (CVE-2020-12662), samt offentliga DNS-tjänster som Google, Cloudflare, Amazon, Quad9, ICANN och andra företag. Åtgärden mot problemet har koordinerats med utvecklarna av DNS-servrar, som samtidigt har släppt uppdateringar som åtgärdar sårbarheten i sina produkter. Skydd mot attacken har införts i versionerna
Unbound 1.10.1, Knot Resolver 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

Attacken baseras på att angriparen använder begärningar som hänvisar till ett stort antal tidigare okända fiktiva NS-poster, som ges befogenhet att definiera namnet men utan att ange glue-poster med information om NS-servernas IP-adresser. Till exempel skickar angriparen en begäran om namnidentifiering sd1.attacker.com, kontrollerande DNS-servern som ansvarar för domänen attacker.com. Som svar på resolverns begäran till angriparens DNS-server ges ett svar som delegerar adressidentifieringen för sd1.attacker.com till offrets DNS-server genom att ange NS-poster utan detaljer om IP-adresserna för NS-servrarna. Eftersom den nämnda NS-servern tidigare inte har setts och dess IP-adress inte är angiven, försöker resolvern att identifiera IP-adressen för NS-servern genom att skicka en begäran till offrets DNS-server, som hanterar mål-domen (victim.com).

Problemet är att angriparen kan skicka ett enormt antal unika NS-servrar med icke-existerande fiktiva domännamn till offrets underdomäner (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com) i svaret. Resolvatorn kommer att försöka skicka en begäran till offrets DNS-server, men kommer att få ett svar om att domänen inte hittades, varefter den kommer att försöka identifiera nästa NS-server i listan och så vidare, tills alla angivna NS-poster har gåtts igenom. Följaktligen kommer en begäran från angriparen att leda till ett enormt antal begärningar för att fastställa NS-värdar. Eftersom namnen på NS-servrarna genereras slumpmässigt och hänvisar till icke-existerande underdomäner, extraheras de inte från cachen, och varje begäran från angriparen resulterar i en våg av begärningar till DNS-servern som hanterar offrets domän.

Forskare har undersökt hur utsatta offentliga DNS-resolvatorer är och har funnit att vid skickande av begärningar till CloudFlare-resolvatorn (1.1.1.1) kan de uppnå en paketförstärkningsfaktor (PAF, Packet Amplification Factor) på 48 gånger, Google (8.8.8.8) - 30 gånger, FreeDNS (37.235.1.174) - 50 gånger, OpenDNS (208.67.222.222) - 32 gånger. Mer framträdande siffror observeras för
Level3 (209.244.0.3) - 273 gånger, Quad9 (9.9.9.9) - 415 gånger
SafeDNS (195.46.39.39) - 274 gånger, Verisign (64.6.64.6) - 202 gånger,
Ultra (156.154.71.1) - 405 gånger, Comodo Secure (8.26.56.26) - 435 gånger, DNS.Watch (84.200.69.80) - 486 gånger, och Norton ConnectSafe (199.85.126.10) - 569 gånger. För servrar baserade på BIND 9.12.3 kan förstärkningsnivån, genom att hantera begärningarna parallellt, nå upp till 1000. I Knot Resolver 5.1.0 är förstärkningsnivån cirka några tiotal gånger (24-48), eftersom identifieringen av NS-namn görs sekventiellt och möter en inre begränsning på antalet namnuppslagningssteg som är tillåtna för en begäran.

Två huvudstrategier för skydd framhävs. För system med DNSSEC föreslagit använda RFC-8198 för att förhindra DNS-cache-omgångar, eftersom begärningar skickas med slumpmässiga namn. Metoden innebär att generera negativa svar utan att behöva kontakta auktoritativa DNS-servrar, genom att använda intervallkontroll via DNSSEC. Ett enklare sätt är att begränsa antalet namn som kan identifieras vid behandling av en enda delegerad begäran, men denna metod kan leda till problem med vissa befintliga konfigurationer, eftersom gränserna inte definieras i protokollet.

Källa: opennet.ru