NXNSAttack-Angriff, der alle DNS-Resolver betrifft

Eine Gruppe von Forschern der Universität Tel Aviv und des Interdisziplinären Zentrums in Herzliya (Israel) hat sich entwickelt neue Angriffsmethode NXNSAttack (PDF), sodass Sie beliebige DNS-Resolver als Verkehrsverstärker verwenden können, was eine bis zu 1621-fache Verstärkungsrate in Bezug auf die Anzahl der Pakete bietet (für jede an den Resolver gesendete Anfrage können Sie erreichen, dass 1621 Anfragen an den Server des Opfers gesendet werden). und bis zu 163 Mal in Bezug auf den Verkehr.

Das Problem hängt mit den Besonderheiten des Protokolls zusammen und betrifft alle DNS-Server, die die rekursive Abfrageverarbeitung unterstützen, einschließlich BINDEN (CVE-2020-8616), Knoten (CVE-2020-12667), PowerDNS (CVE-2020-10995), Windows-DNS-Server и Nicht gebunden (CVE-2020-12662) sowie öffentliche DNS-Dienste von Google, Cloudflare, Amazon, Quad9, ICANN und anderen Unternehmen. Der Fix wurde mit DNS-Serverentwicklern koordiniert, die gleichzeitig Updates veröffentlichten, um die Schwachstelle in ihren Produkten zu beheben. In Releases implementierter Angriffsschutz
Ungebunden 1.10.1, Knotenlöser 5.1.1, PowerDNS-Rekursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

Der Angriff basiert darauf, dass der Angreifer Anfragen verwendet, die sich auf eine große Anzahl bisher ungesehener fiktiver NS-Records beziehen, an die die Namensfindung delegiert wird, ohne jedoch in der Antwort Glue-Records mit Informationen über die IP-Adressen von NS-Servern anzugeben. Beispielsweise sendet ein Angreifer eine Anfrage zur Auflösung des Namens sd1.attacker.com, indem er den DNS-Server kontrolliert, der für die Domäne attacker.com verantwortlich ist. Als Antwort auf die Anfrage des Resolvers an den DNS-Server des Angreifers wird eine Antwort ausgegeben, die die Ermittlung der sd1.attacker.com-Adresse an den DNS-Server des Opfers delegiert, indem NS-Einträge in der Antwort angegeben werden, ohne die IP-NS-Server anzugeben. Da der erwähnte NS-Server noch nie zuvor angetroffen wurde und seine IP-Adresse nicht angegeben ist, versucht der Resolver, die IP-Adresse des NS-Servers zu ermitteln, indem er eine Anfrage an den DNS-Server des Opfers sendet, der die Zieldomäne (victim.com) bedient.

NXNSAttack-Angriff, der alle DNS-Resolver betrifft

Das Problem besteht darin, dass der Angreifer mit einer riesigen Liste sich nicht wiederholender NS-Server mit nicht existierenden fiktiven Opfer-Subdomain-Namen (fake-1.victim.com, fake-2.victim.com, ... fake-1000) reagieren kann. Opfer.com). Der Resolver versucht, eine Anfrage an den DNS-Server des Opfers zu senden, erhält jedoch die Antwort, dass die Domäne nicht gefunden wurde. Anschließend versucht er, den nächsten NS-Server in der Liste zu ermitteln usw., bis er alle Versuche unternommen hat Vom Angreifer aufgelistete NS-Datensätze. Dementsprechend sendet der Resolver für die Anfrage eines Angreifers eine große Anzahl von Anfragen zur Ermittlung von NS-Hosts. Da NS-Servernamen zufällig generiert werden und sich auf nicht vorhandene Subdomänen beziehen, 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 Domäne des Opfers bedient.

NXNSAttack-Angriff, der alle DNS-Resolver betrifft

Forscher untersuchten den Grad der Anfälligkeit öffentlicher DNS-Resolver für das Problem und stellten fest, dass es beim Senden von Abfragen an den CloudFlare-Resolver (1.1.1.1) möglich ist, die Anzahl der Pakete (PAF, Packet Amplification Factor) um das 48-fache zu erhöhen, so Google (8.8.8.8) – 30 Mal, FreeDNS (37.235.1.174) – 50 Mal, OpenDNS (208.67.222.222) – 32 Mal. Es werden auffälligere Indikatoren beobachtet
Level3 (209.244.0.3) – 273 Mal, Quad9 (9.9.9.9) – 415 Mal
SafeDNS (195.46.39.39) – 274 Mal, Verisign (64.6.64.6) – 202 Mal,
Ultra (156.154.71.1) – 405 Mal, Comodo Secure (8.26.56.26) – 435 Mal, DNS.Watch (84.200.69.80) – 486 Mal und Norton ConnectSafe (199.85.126.10) – 569 Mal. Bei Servern, die auf BIND 9.12.3 basieren, kann die Verstärkungsstufe aufgrund der Parallelisierung von Anforderungen bis zu 1000 erreichen. In Knot Resolver 5.1.0 beträgt die Verstärkungsstufe ungefähr mehrere Zehnfache (24–48), seit der Bestimmung von NS-Namen werden sequentiell ausgeführt und basieren auf der internen Begrenzung der Anzahl der für eine Anfrage zulässigen Namensauflösungsschritte.

Es gibt zwei Hauptverteidigungsstrategien. Für Systeme mit DNSSEC vorgeschlagen von verwenden RFC-8198 um eine DNS-Cache-Umgehung zu verhindern, da Anfragen mit zufälligen Namen gesendet werden. Der Kern der Methode besteht darin, mithilfe der Bereichsprüfung über DNSSEC negative Antworten zu generieren, ohne autorisierende DNS-Server zu kontaktieren. Ein einfacherer Ansatz besteht darin, die Anzahl der Namen zu begrenzen, die bei der Verarbeitung einer einzelnen delegierten Anfrage definiert werden können. Diese Methode kann jedoch bei einigen vorhandenen Konfigurationen zu Problemen führen, da die Grenzwerte nicht im Protokoll definiert sind.

Source: opennet.ru

Kommentar hinzufügen