Atak NXNSAttack wpływający na wszystkie programy rozpoznawania nazw DNS

Grupa badaczy z Uniwersytetu w Tel Awiwie i Centrum Interdyscyplinarnego w Herzliya (Izrael) rozwinęła się nowa metoda ataku NXNSAtak (PDF), umożliwiając wykorzystanie dowolnych programów rozpoznawania nazw DNS jako wzmacniaczy ruchu, zapewniając współczynnik wzmocnienia do 1621 razy w przeliczeniu na liczbę pakietów (na każde żądanie wysłane do mechanizmu rozpoznawania nazw można osiągnąć 1621 żądań wysłanych do serwera ofiary) i aż 163 razy pod względem ruchu.

Problem jest związany ze specyfiką protokołu i dotyczy wszystkich serwerów DNS obsługujących rekurencyjne przetwarzanie zapytań, w tym WIĄZAĆ (CVE-2020-8616) Węzeł (CVE-2020-12667) PowerDNS (CVE-2020-10995) Serwer DNS systemu Windows и Rozwiązany (CVE-2020-12662), a także publiczne usługi DNS Google, Cloudflare, Amazon, Quad9, ICANN i innych firm. Poprawka została skoordynowana z twórcami serwerów DNS, którzy jednocześnie opublikowali aktualizacje naprawiające lukę w swoich produktach. Ochrona przed atakami zaimplementowana w wersjach
Bez ograniczeń 1.10.1, Narzędzie do rozwiązywania węzłów 5.1.1, Rekursor PowerDNS 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

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).

Atak NXNSAttack wpływający na wszystkie programy rozpoznawania nazw DNS

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.

Atak NXNSAttack wpływający na wszystkie programy rozpoznawania nazw DNS

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 proponowane używać RFC-8198 aby zapobiec omijaniu pamięci podręcznej DNS, ponieważ żądania są wysyłane z losowymi nazwami. Istotą tej metody jest generowanie odpowiedzi negatywnych bez konieczności kontaktowania się z autorytatywnymi serwerami DNS, przy użyciu sprawdzania zasięgu poprzez DNSSEC. Prostszym podejściem jest ograniczenie liczby nazw, które można zdefiniować podczas przetwarzania pojedynczego delegowanego żądania, ale ta metoda może powodować problemy w niektórych istniejących konfiguracjach, ponieważ limity nie są zdefiniowane w protokole.

Źródło: opennet.ru

Dodaj komentarz