Útok NXNSAttack ovplyvňujúci všetky DNS resolvery

Skupina výskumníkov z Tel Avivskej univerzity a Interdisciplinárneho centra v Herzliyi (Izrael) vyvinula nová metóda útoku NXNSAttack (PDF), čo vám umožňuje používať akékoľvek DNS resolvery ako zosilňovače prevádzky, poskytujúce rýchlosť zosilnenia až 1621-krát, pokiaľ ide o počet paketov (pre každú požiadavku odoslanú do resolvera môžete dosiahnuť 1621 odoslaných požiadaviek na server obete) a až 163-krát z hľadiska návštevnosti.

Problém súvisí so zvláštnosťami protokolu a týka sa všetkých serverov DNS, ktoré podporujú rekurzívne spracovanie dotazov, vrátane BIND (CVE-2020-8616) uzol (CVE-2020-12667) PowerDNS (CVE-2020-10995) Server DNS systému Windows и neviazaný (CVE-2020-12662), ako aj verejné služby DNS spoločností Google, Cloudflare, Amazon, Quad9, ICANN a ďalších. Oprava bola koordinovaná s vývojármi serverov DNS, ktorí súčasne vydali aktualizácie na opravu zraniteľnosti vo svojich produktoch. Ochrana pred útokmi implementovaná vo vydaniach
Bez obmedzenia 1.10.1, Knot Resolver 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

Útok je založený na tom, že útočník používa požiadavky, ktoré odkazujú na veľké množstvo predtým neviditeľných fiktívnych NS záznamov, na ktoré je delegované určenie mena, avšak bez špecifikovania združených záznamov s informáciami o IP adresách NS serverov v odpovedi. Útočník napríklad odošle dotaz na vyriešenie názvu sd1.attacker.com ovládaním servera DNS zodpovedného za doménu útočník.com. V reakcii na požiadavku prekladača na server DNS útočníka sa vydá odpoveď, ktorá deleguje určenie adresy sd1.attacker.com na server DNS obete uvedením záznamov NS v odpovedi bez uvedenia podrobností o serveroch NS IP. Keďže spomenutý NS server sa predtým nestretol a jeho IP adresa nie je špecifikovaná, resolver sa pokúsi zistiť IP adresu NS servera odoslaním dotazu na DNS server obete obsluhujúci cieľovú doménu (victim.com).

Útok NXNSAttack ovplyvňujúci všetky DNS resolvery

Problém je v tom, že útočník môže odpovedať obrovským zoznamom neopakujúcich sa serverov NS s neexistujúcimi fiktívnymi názvami subdomén obetí (falošná-1.victim.com, falošná-2.victim.com,... falošná-1000. obete.com). Prekladač sa pokúsi odoslať požiadavku na DNS server obete, ale dostane odpoveď, že doména nebola nájdená, potom sa pokúsi určiť ďalší NS server v zozname atď., kým nevyskúša všetky NS záznamy uvedené útočníkom. V súlade s tým na žiadosť jedného útočníka pošle resolver veľké množstvo požiadaviek na určenie hostiteľov NS. Keďže názvy serverov NS sú generované náhodne a odkazujú na neexistujúce subdomény, nezískavajú sa z vyrovnávacej pamäte a každá požiadavka od útočníka má za následok príval požiadaviek na server DNS obsluhujúci doménu obete.

Útok NXNSAttack ovplyvňujúci všetky DNS resolvery

Výskumníci študovali mieru zraniteľnosti verejných DNS resolverov na problém a zistili, že pri odosielaní dotazov na CloudFlare resolver (1.1.1.1) je možné zvýšiť počet paketov (PAF, Packet Amplification Factor) 48-krát, Google (8.8.8.8) - 30-krát, FreeDNS (37.235.1.174) - 50-krát, OpenDNS (208.67.222.222) - 32-krát. Pozorujú sa výraznejšie ukazovatele pre
Úroveň 3 (209.244.0.3) - 273-krát, Quad9 (9.9.9.9) - 415-krát
SafeDNS (195.46.39.39) - 274-krát, Verisign (64.6.64.6) - 202-krát,
Ultra (156.154.71.1) - 405-krát, Comodo Secure (8.26.56.26) - 435-krát, DNS.Watch (84.200.69.80) - 486-krát a Norton ConnectSafe (199.85.126.10-krát) - 569 Pri serveroch založených na BIND 9.12.3 môže v dôsledku paralelizácie požiadaviek dosiahnuť úroveň zisku až 1000. V Knot Resolver 5.1.0 je úroveň zisku približne niekoľko desiatok krát (24-48), pretože Názvy NS sa vykonávajú postupne a spočívajú na internom limite počtu krokov rozlíšenia názvu povolených pre jednu požiadavku.

Existujú dve hlavné obranné stratégie. Pre systémy s DNSSEC navrhnuté na použitie RFC-8198 aby sa zabránilo obchádzaniu vyrovnávacej pamäte DNS, pretože požiadavky sa odosielajú s náhodnými názvami. Podstatou metódy je generovanie negatívnych odpovedí bez kontaktovania autoritatívnych serverov DNS pomocou kontroly rozsahu cez DNSSEC. Jednoduchším prístupom je obmedzenie počtu mien, ktoré možno definovať pri spracovaní jednej delegovanej požiadavky, ale táto metóda môže spôsobiť problémy s niektorými existujúcimi konfiguráciami, pretože limity nie sú definované v protokole.

Zdroj: opennet.ru

Pridať komentár