Skupina výzkumníků z Tel Avivské univerzity a Interdisciplinárního centra v Herzliya (Izrael) nový způsob útoku (), což vám umožňuje používat jakékoli DNS resolvery jako zesilovače provozu, poskytující míru zesílení až 1621krát, pokud jde o počet paketů (na každý požadavek odeslaný do resolveru můžete dosáhnout 1621 požadavků odeslaných na server oběti) a až 163krát z hlediska návštěvnosti.
Problém souvisí se zvláštnostmi protokolu a týká se všech serverů DNS, které podporují rekurzivní zpracování dotazů, včetně (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), stejně jako veřejné služby DNS společností Google, Cloudflare, Amazon, Quad9, ICANN a dalších. Oprava byla koordinována s vývojáři serverů DNS, kteří současně vydali aktualizace opravující zranitelnost ve svých produktech. Ochrana před útoky implementovaná ve vydáních
, , , .
Útok je založen na tom, že útočník používá požadavky, které odkazují na velké množství dříve neviděných fiktivních NS záznamů, na které je delegováno určení jména, ale bez zadání spojovacích záznamů s informacemi o IP adresách NS serverů v odpovědi. Útočník například odešle dotaz k vyřešení názvu sd1.attacker.com řízením serveru DNS odpovědného za doménu útočník.com. V reakci na požadavek překladače na server DNS útočníka je vydána odpověď, která deleguje určení adresy sd1.attacker.com na server DNS oběti uvedením záznamů NS v odpovědi bez podrobností o serverech IP NS. Vzhledem k tomu, že zmíněný NS server nebyl dosud nalezen a jeho IP adresa není specifikována, resolver se pokusí zjistit IP adresu NS serveru odesláním dotazu na DNS server oběti obsluhující cílovou doménu (victim.com).
Problém je v tom, že útočník může odpovědět obrovským seznamem neopakujících se serverů NS s neexistujícími fiktivními názvy subdomén obětí (fake-1.victim.com, fake-2.victim.com,... fake-1000. oběti.com). Překladač se pokusí odeslat požadavek na DNS server oběti, ale obdrží odpověď, že doména nebyla nalezena, načež se pokusí určit další NS server v seznamu atd., dokud nevyzkouší všechny NS záznamy uvedené útočníkem. Na žádost jednoho útočníka tedy překladač odešle velké množství požadavků na určení hostitelů NS. Vzhledem k tomu, že názvy serverů NS jsou generovány náhodně a odkazují na neexistující subdomény, nejsou získávány z mezipaměti a každý požadavek od útočníka má za následek příval požadavků na server DNS obsluhující doménu oběti.
Výzkumníci studovali míru zranitelnosti veřejných DNS resolverů vůči tomuto problému a zjistili, že při odesílání dotazů do CloudFlare resolveru (1.1.1.1) je možné zvýšit počet paketů (PAF, Packet Amplification Factor) 48krát, Google (8.8.8.8) - 30krát, FreeDNS (37.235.1.174) - 50krát, OpenDNS (208.67.222.222) - 32krát. Pozoruhodnější ukazatele jsou pozorovány pro
Úroveň 3 (209.244.0.3) - 273krát, Quad9 (9.9.9.9) - 415krát
SafeDNS (195.46.39.39) - 274krát, Verisign (64.6.64.6) - 202krát,
Ultra (156.154.71.1) - 405krát, Comodo Secure (8.26.56.26) - 435krát, DNS.Watch (84.200.69.80) - 486krát a Norton ConnectSafe (199.85.126.10krát) - 569 U serverů založených na BIND 9.12.3 může v důsledku paralelizace požadavků úroveň zisku dosáhnout až 1000. V Knot Resolver 5.1.0 je úroveň zisku přibližně několik desítekkrát (24-48), od určení Názvy NS se provádí postupně a spočívá na interním limitu počtu kroků rozlišení názvů povolených pro jeden požadavek.
Existují dvě hlavní obranné strategie. Pro systémy s DNSSEC k použití aby se zabránilo obcházení mezipaměti DNS, protože požadavky jsou odesílány s náhodnými názvy. Podstatou této metody je generování negativních odpovědí bez kontaktování autoritativních serverů DNS pomocí kontroly rozsahu pomocí DNSSEC. Jednodušší přístup je omezit počet názvů, které lze definovat při zpracování jednoho delegovaného požadavku, ale 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