NXNSAttack, das alle DNS-Resolver betrifft

Eine Forschergruppe der Universität Tel Aviv und des Interdisziplinären Zentrums in Herzlia (Israel) hat eine neue Angriffs-Methode NXNSAttack (PDF), die es ermöglicht, beliebige DNS-Resolver als Traffic-Verstärker zu nutzen, mit einem Verstärkungsgrad von bis zu 1621-fach in Bezug auf die Anzahl der Pakete (für jede an den Resolver gesendete Anfrage können bis zu 1621 Anfragen an den Server des Opfers gesendet werden) und bis zu 163-fach in Bezug auf den Traffic.

Das Problem hängt mit den Besonderheiten des Protokolls zusammen und betrifft alle DNS-Server, die rekursive Anfragen unterstützen, einschließlich BIND (CVE-2020-8616), Knot (CVE-2020-12667), PowerDNS (CVE-2020-10995), Windows DNS Server und Unbound (CVE-2020-12662), sowie öffentliche DNS-Dienste von Google, Cloudflare, Amazon, Quad9, ICANN und anderen Unternehmen. Die Behebung des Problems wurde mit den Entwicklern der DNS-Server koordiniert, die gleichzeitig Updates zur Behebung der Sicherheitsanfälligkeit in ihren Produkten veröffentlichten. Der Schutz vor dem Angriff wurde in den Versionen
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.

Der Angriff basiert auf der Verwendung von Anfragen, die sich auf eine große Anzahl zuvor unbekannter fiktiver NS-Einträge beziehen, die für die Namensauflösung delegiert werden, jedoch ohne Angabe von Glue-Einträgen mit Informationen über die IP-Adressen der NS-Server. Beispielsweise sendet der Angreifer eine Anfrage zur Namensauflösung von sd1.attacker.com, wobei er den DNS-Server kontrolliert, der für die Domain attacker.com zuständig ist. Als Antwort auf die Anfrage des Resolvers an den DNS-Server des Angreifers wird eine Antwort zurückgegeben, die die Namensauflösung von sd1.attacker.com an den DNS-Server des Opfers delegiert, indem NS-Einträge ohne Details zu den IP-Adressen der NS-Server bereitgestellt werden. Da der genannte NS-Server zuvor nicht bekannt war und seine IP-Adresse nicht angegeben ist, versucht der Resolver, die IP-Adresse des NS-Servers zu bestimmen, indem er eine Anfrage an den DNS-Server des Opfers sendet, der die Ziel-Domain (victim.com) verwaltet.

NXNSAttack, das alle DNS-Resolver betrifft

Das Problem ist, dass der Angreifer in der Antwort eine riesige Liste von nicht wiederholten NS-Servern mit nicht existierenden fiktiven Subdomain-Namen des Opfers (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com) ausgeben kann. Der Resolver wird versuchen, eine Anfrage an den DNS-Server des Opfers zu senden, bekommt jedoch die Antwort, dass die Domain nicht gefunden wurde, wonach er versucht, den nächsten NS-Server in der Liste zu bestimmen und so weiter, bis er alle vom Angreifer aufgelisteten NS-Einträge durchläuft. Folglich wird für jede Anfrage des Angreifers eine enorme Anzahl an Anfragen zur Bestimmung der NS-Hosts durch den Resolver gesendet. Da die Namen der NS-Server zufällig generiert werden und auf nicht existierende Subdomains verweisen, werden sie nicht aus dem Cache abgerufen, und jede Anfrage des Angreifers führt zu einer Flut von Anfragen an den DNS-Server, der die Domain des Opfers verwaltet.

NXNSAttack, das alle DNS-Resolver betrifft

Die Forscher haben das Ausmaß der Anfälligkeit öffentlicher DNS-Resolver untersucht und festgestellt, dass bei Anfragen an den Resolver CloudFlare (1.1.1.1) ein Paket-Verstärkungsfaktor (PAF, Packet Amplification Factor) von 48-fach erreicht werden kann, Google (8.8.8.8) — 30-fach, FreeDNS (37.235.1.174) — 50-fach, OpenDNS (208.67.222.222) — 32-fach. Deutlich höhere Werte wurden bei
Level3 (209.244.0.3) — 273-fach, Quad9 (9.9.9.9) — 415-fach
SafeDNS (195.46.39.39) — 274-fach, Verisign (64.6.64.6) — 202-fach,
Ultra (156.154.71.1) — 405-fach, Comodo Secure (8.26.56.26) — 435-fach, DNS.Watch (84.200.69.80) — 486-fach, und Norton ConnectSafe (199.85.126.10) — 569-fach. Bei Servern, die auf BIND 9.12.3 basieren, kann durch paralleles Senden von Anfragen der Verstärkungsgrad bis zu 1000 erreichen. Beim Knot Resolver 5.1.0 liegt der Verstärkungsgrad bei etwa mehreren Dutzend (24-48), da die Bestimmung der NS-Namen sequenziell erfolgt und an einer internen Begrenzung der maximalen Anzahl an Namensauflösungs-Schritten für eine Anfrage besteht.

Es werden zwei Hauptstrategien zum Schutz hervorgehoben. Für Systeme mit DNSSEC eine Lösung eingesetzt zu werden. RFC-8198 um das Umgehen des DNS-Caches zu verhindern, da Anfragen mit zufälligen Namen gesendet werden. Der Kern der Methode besteht darin, negative Antworten zu generieren, ohne autoritative DNS-Server zu konsultieren, wobei eine Überprüfung über Bereiche mittels DNSSEC angewendet wird. Eine einfachere Methode besteht darin, die Anzahl der Namen zu begrenzen, die bei der Verarbeitung einer delegierten Anfrage aufgelöst werden können, aber diese Methode kann Probleme mit einigen bestehenden Konfigurationen verursachen, da die Grenzen im Protokoll nicht definiert sind.

Quelle: opennet.ru

Erwerben Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server 🔥 Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server | ProHoster