Skupina výzkumníků z Telavivské univerzity a Mezioborového centra v Herzliyi (Izrael) novou metodu útoku (), která umožňuje využít libovolné DNS resolvery jako zesilovače provozu, dosahující stupně zesílení až 1621 násobku počtu paketů (na každý odeslaný požadavek k resolveru lze dosáhnout odeslání 1621 požadavků na server oběti) a až 163 násobku podle provozu.
Problém souvisí se specifiky fungování protokolu a zasahuje všechny DNS servery, které podporují rekurzivní zpracování požadavků, včetně (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), a (CVE-2020-12662), a také veřejné DNS služby Google, Cloudflare, Amazon, Quad9, ICANN a dalších společností. Oprava problému byla koordinována s vývojáři DNS serverů, kteří zároveň vydali aktualizace s opravou zranitelnosti ve svých produktech. Ochrana proti útoku byla zavedena v verzích
, , , .
Útok se zakládá na používání útočníkem požadavků odkazujících na velké množství dříve neviděných fiktivních NS záznamů, kterým je delegováno určení jména, ale bez uvedení v odpovědi glue záznamů s informacemi o IP adresách NS serverů. Například útočník odešle požadavek na určení jména sd1.attacker.com, přičemž ovládá DNS server odpovídající za doménu attacker.com. V odpovědi na dotaz resolveru k DNS serveru útočníka se vrátí odpověď, která deleguje určení adresy sd1.attacker.com DNS serveru oběti prostřednictvím uvedení NS záznamů bez detailizace IP NS serverů. Jelikož zmíněný NS server předtím nebyl viděn a jeho IP adresa není uvedena, resolver se pokouší určit IP adresu NS serveru, a to tím, že odešle dotaz k DNS serveru oběti, který spravuje cílovou doménu (victim.com).
Problém je v tom, že útočník může vrátit obrovský seznam unikátních NS serverů s neexistujícími falešnými názvy subdomén oběti (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). Resolver se pokusí poslat dotaz DNS serveru oběti, ale dostane odpověď, že doména nebyla nalezena, po čemž se pokusí zjistit další NS server v seznamu a tak dál, dokud neprojde všemi uvedenými NS záznamy útočníka. Podle toho bude na jeden dotaz útočníka resolverem odesláno obrovské množství dotazů pro určení NS hostitelů. Protože názvy NS serverů jsou generovány náhodně a odkazují na neexistující subdomény, nejsou vybírány z cache a každý dotaz útočníka vede k lavině dotazů k DNS serveru, který obsluhuje doménu oběti.
Výzkumníci prozkoumali míru zranitelnosti veřejných DNS resolverů a zjistili, že při odesílání dotazů resolveru CloudFlare (1.1.1.1) lze dosáhnout násobení počtu paketů (PAF, Packet Amplification Factor) o 48x, Google (8.8.8.8) — 30x, FreeDNS (37.235.1.174) — 50x, OpenDNS (208.67.222.222) — 32x. Výrazně vyšší hodnoty byly zaznamenány pro
Level3 (209.244.0.3) — 273x, Quad9 (9.9.9.9) — 415x
SafeDNS (195.46.39.39) — 274x, Verisign (64.6.64.6) — 202x,
Ultra (156.154.71.1) — 405x, Comodo Secure (8.26.56.26) — 435x, DNS.Watch (84.200.69.80) — 486x a Norton ConnectSafe (199.85.126.10) — 569x. Pro servery na bázi BIND 9.12.3 lze díky paralelizaci dotazů dosáhnout úrovně zesílení až 1000. U Knot Resolver 5.1.0 je úroveň zesílení přibližně několik desítek násobků (24-48), protože určení NS názvů probíhá sekvenčně a narazí na vnitřní omezení počtu kroků vyřešení názvů, které jsou povoleny pro jeden dotaz.
Vyznačují se dvě hlavní strategie ochrany. Pro systémy s DNSSEC použít pro zabránění obcházení cache DNS, protože dotazy jsou odesílány s náhodnými názvy. Podstatou metody je generování negativních odpovědí bez oslovení autoritativních DNS serverů, přičemž se používá ověření podle rozsahů přes DNSSEC. Jednodušší metodou je omezit počet názvů, které lze určit při zpracování jednoho delegovaného dotazu, avšak tato metoda může způsobit problémy s některými existujícími konfiguracemi, protože limity nejsou definovány v protokolu.
Zdroj: opennet.ru
