Eine Gruppe von Forschern der Universität Tel Aviv und des Interdisziplinären Zentrums in Herzliya (Israel)
Das Problem hängt mit den Besonderheiten des Protokolls zusammen und betrifft alle DNS-Server, die die rekursive Abfrageverarbeitung unterstützen, einschließlich
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.
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.
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
Source: opennet.ru