Grupa badaczy z Uniwersytetu w Tel Awiwie i Centrum Interdyscyplinarnego w Herzliya (Izrael)
Problem jest związany ze specyfiką protokołu i dotyczy wszystkich serwerów DNS obsługujących rekurencyjne przetwarzanie zapytań, w tym
Atak polega na tym, że atakujący wykorzystuje żądania odwołujące się do dużej liczby niewidzianych wcześniej fikcyjnych rekordów NS, do których delegowane jest określanie nazwy, ale bez podawania w odpowiedzi rekordów klejących z informacją o adresach IP serwerów NS. Na przykład osoba atakująca wysyła zapytanie w celu rozpoznania nazwy sd1.attacker.com, kontrolując serwer DNS odpowiedzialny za domenę atakujący.com. W odpowiedzi na żądanie mechanizmu rozpoznawania nazw skierowane do serwera DNS atakującego, wydawana jest odpowiedź, która deleguje określenie adresu sd1.attacker.com serwerowi DNS ofiary poprzez wskazanie rekordów NS w odpowiedzi bez wyszczególniania serwerów IP NS. Ponieważ wspomniany serwer NS nie został wcześniej napotkany i jego adres IP nie został określony, moduł rozpoznawania nazw próbuje ustalić adres IP serwera NS, wysyłając zapytanie do serwera DNS ofiary obsługującego domenę docelową (victim.com).
Problem w tym, że atakujący może odpowiedzieć ogromną listą niepowtarzalnych serwerów NS z nieistniejącymi fikcyjnymi nazwami subdomen ofiar (fake-1.victim.com, fake-2.victim.com,... fake-1000. ofiara.com). Funkcja rozpoznawania nazw spróbuje wysłać żądanie do serwera DNS ofiary, ale otrzyma odpowiedź, że domeny nie odnaleziono, po czym spróbuje określić następny serwer NS na liście i tak dalej, aż wypróbuje wszystkie Rekordy NS wymienione przez atakującego. W związku z tym na jedno żądanie atakującego moduł rozpoznawania nazw wyśle ogromną liczbę żądań w celu określenia hostów NS. Ponieważ nazwy serwerów NS są generowane losowo i odnoszą się do nieistniejących subdomen, nie są pobierane z pamięci podręcznej, a każde żądanie atakującego powoduje lawinę żądań kierowanych do serwera DNS obsługującego domenę ofiary.
Badacze zbadali stopień podatności publicznych usług rozpoznawania nazw DNS na problem i ustalili, że wysyłając zapytania do usługi rozpoznawania CloudFlare (1.1.1.1), możliwe jest 48-krotne zwiększenie liczby pakietów (PAF, Packet Amplification Factor), Google (8.8.8.8) – 30 razy, FreeDNS (37.235.1.174) – 50 razy, OpenDNS (208.67.222.222) – 32 razy. Bardziej zauważalne wskaźniki obserwuje się dla
Poziom 3 (209.244.0.3) – 273 razy, Quad9 (9.9.9.9) – 415 razy
SafeDNS (195.46.39.39) – 274 razy, Verisign (64.6.64.6) – 202 razy,
Ultra (156.154.71.1) – 405 razy, Comodo Secure (8.26.56.26) – 435 razy, DNS.Watch (84.200.69.80) – 486 razy, a Norton ConnectSafe (199.85.126.10) – 569 razy. W przypadku serwerów opartych na BIND 9.12.3, ze względu na równoległość żądań, poziom wzmocnienia może sięgać nawet 1000. W Knot Resolver 5.1.0 poziom wzmocnienia jest około kilkudziesięciu razy (24-48), ponieważ określenie Nazwy NS są wykonywane sekwencyjnie i opierają się na wewnętrznym limicie liczby kroków rozpoznawania nazw dozwolonych dla jednego żądania.
Istnieją dwie główne strategie obronne. Dla systemów z DNSSEC
Źródło: opennet.ru