Zespół badawczy z Uniwersytetu w Tel Awiwie oraz Centrum Interdyscyplinarnego w Herclijj (Izrael) nową metodę ataku (), która pozwala na wykorzystanie dowolnych resolverów DNS jako wzmacniaczy ruchu, zapewniających stopień wzmocnienia do 1621 razy w liczbie pakietów (na każdy wysłany do resolvera zapytanie, można uzyskać wysłanie na serwer ofiary 1621 zapytań) i do 163 razy według ruchu.
Problem związany jest z cechami działania protokołu i dotyczy wszystkich serwerów DNS, które obsługują rekursywne przetwarzanie zapytań, w tym (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), i (CVE-2020-12662), a także publiczne usługi DNS Google, Cloudflare, Amazon, Quad9, ICANN i innych firm. Naprawa problemu została skoordynowana z deweloperami serwerów DNS, którzy jednocześnie wydali aktualizacje z poprawą podatności w swoich produktach. Ochrona przed atakiem została zrealizowana w wydaniach
, , , .
Atak opiera się na wykorzystywaniu przez atakującego zapytań, które odnoszą się do dużej liczby wcześniej niewystępujących fikcyjnych rekordów NS, którym delegowane jest określenie nazwy, ale bez wskazania w odpowiedzi rekordów glue z informacjami o adresach IP serwerów NS. Na przykład, atakujący wysyła zapytanie o określenie nazwy sd1.attacker.com, kontrolując serwer DNS odpowiedzialny za domenę attacker.com. W odpowiedzi na zapytanie resolvera do serwera DNS atakującego, zwracana jest odpowiedź, delegująca określenie adresu sd1.attacker.com serwerowi DNS ofiary poprzez wskazanie w odpowiedzi rekordów NS bez szczegółów dotyczących adresów IP serwerów NS. Ponieważ wspomniany serwer NS wcześniej się nie pojawił i jego adres IP nie jest podany, resolver próbuje określić adres IP serwera NS, kierując zapytanie do serwera DNS ofiary, obsługującego docelową domenę (victim.com).
Problem polega na tym, że atakujący może odpowiedzieć ogromną listą niepowtarzających się serwerów NS z nieistniejącymi fikcyjnymi nazwami subdomen ofiary (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). Resolver spróbuje wysłać zapytanie do serwera DNS ofiary, ale otrzyma odpowiedź, że domena nie istnieje, po czym spróbuje określić kolejny serwer NS na liście i tak dalej, aż przeanalizuje wszystkie wymienione przez atakującego rekordy NS. W rezultacie na jedno zapytanie atakującego resolver wysyła ogromną liczbę zapytań w celu zidentyfikowania hostów NS. Ponieważ nazwy serwerów NS są tworzone losowo i odnoszą się do nieistniejących subdomen, nie są wyciągane z cache'a, a każde zapytanie atakującego prowadzi do salwy zapytań do serwera DNS obsługującego domenę ofiary.
Badacze zbadali stopień podatności publicznych resolverów DNS i stwierdzili, że przy wysyłaniu zapytań do resolvera CloudFlare (1.1.1.1) można osiągnąć zwiększenie liczby pakietów (PAF, Packet Amplification Factor) o 48 razy, Google (8.8.8.8) — 30 razy, FreeDNS (37.235.1.174) — 50 razy, OpenDNS (208.67.222.222) — 32 razy. Bardziej zauważalne wyniki obserwuje się dla
Level3 (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, oraz Norton ConnectSafe (199.85.126.10) — 569 razy. Dla serwerów opartych na BIND 9.12.3 dzięki równoległości zapytań poziom wzmocnienia może osiągać do 1000. W Knot Resolver 5.1.0 poziom wzmocnienia wynosi około kilku dziesięciu razy (24-48), ponieważ identyfikacja nazw NS odbywa się sekwencyjnie i napotyka wewnętrzne ograniczenie co do liczby kroków rozwiązywania nazw, dopuszczalnych dla jednego zapytania.
Wyróżnia się dwie główne strategie ochrony. Dla systemów z DNSSEC już trzeba coś wykorzystać (pracuję z klastrowym Proxmox VE 5.x i ZFS over iSCSI). w celu zapobiegania omijaniu cache'a DNS, ponieważ zapytania są wysyłane z losowymi nazwami. Meritum metody polega na generowaniu negatywnych odpowiedzi bez odwoływania się do autorytatywnych serwerów DNS, stosując weryfikację w oparciu o zakresy przez DNSSEC. Prostszy sposób polega na ograniczeniu liczby nazw, które można określić podczas przetwarzania jednego delegowanego zapytania, ale ta metoda może prowadzić do problemów z niektórymi istniejącymi konfiguracjami, ponieważ limity nie są określone w protokole.
Źródło: opennet.ru
