Grupa istraživača sa Univerziteta u Tel Avivu i Interdisciplinarnog centra u Herzliji (Izrael) nova metoda napada (), omogućavajući vam da koristite bilo koji DNS razrješavač kao pojačivač saobraćaja, pružajući stopu pojačanja do 1621 puta u smislu broja paketa (za svaki zahtjev poslat razrješivaču, možete postići da se 1621 zahtjev pošalje na server žrtve) i do 163 puta u smislu saobraćaja.
Problem je povezan sa specifičnostima protokola i utiče na sve DNS servere koji podržavaju rekurzivnu obradu upita, uključujući (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), kao i javne DNS usluge Google, Cloudflare, Amazon, Quad9, ICANN i drugih kompanija. Ispravka je koordinirana sa programerima DNS servera, koji su istovremeno objavili ažuriranja kako bi popravili ranjivost u svojim proizvodima. Zaštita od napada implementirana u izdanjima
, , , .
Napad se zasniva na tome da napadač koristi zahtjeve koji se odnose na veliki broj ranije nevidljivih fiktivnih NS zapisa, na koje je delegirano određivanje imena, ali bez specificiranja lijepljenih zapisa sa informacijama o IP adresama NS servera u odgovoru. Na primjer, napadač šalje upit da riješi ime sd1.attacker.com kontroliranjem DNS servera odgovornog za domen napadača.com. Kao odgovor na zahtev razrešivača upućen DNS serveru napadača, izdaje se odgovor koji delegira određivanje sd1.attacker.com adrese na DNS server žrtve navođenjem NS zapisa u odgovoru bez detalja o IP NS serverima. Budući da se pomenuti NS server ranije nije susreo i njegova IP adresa nije navedena, rezolver pokušava da odredi IP adresu NS servera tako što šalje upit DNS serveru žrtve koji opslužuje ciljni domen (viktim.com).
Problem je u tome što napadač može odgovoriti ogromnom listom NS servera koji se ne ponavljaju sa nepostojećim fiktivnim nazivima poddomena žrtve (fake-1.victim.com, fake-2.victim.com,... fake-1000. žrtva.com). Resolver će pokušati poslati zahtjev na DNS server žrtve, ali će dobiti odgovor da domena nije pronađena, nakon čega će pokušati odrediti sljedeći NS server na listi, i tako sve dok ne pokuša sve NS zapisi koje je naveo napadač. Shodno tome, za jedan zahtjev napadača, razrješavač će poslati ogroman broj zahtjeva za određivanje NS hostova. Pošto se imena NS servera generišu nasumično i odnose se na nepostojeće poddomene, oni se ne preuzimaju iz keša i svaki zahtev od napadača rezultira naletom zahteva ka DNS serveru koji opslužuje domen žrtve.
Istraživači su proučavali stepen ranjivosti javnih DNS razrešivača na problem i utvrdili da je prilikom slanja upita CloudFlare razrešivaču (1.1.1.1) moguće povećati broj paketa (PAF, Packet Amplification Factor) za 48 puta, Google (8.8.8.8) - 30 puta, FreeDNS (37.235.1.174) - 50 puta, OpenDNS (208.67.222.222) - 32 puta. Uočljiviji pokazatelji se posmatraju za
Level3 (209.244.0.3) - 273 puta, Quad9 (9.9.9.9) - 415 puta
SafeDNS (195.46.39.39) - 274 puta, Verisign (64.6.64.6) - 202 puta,
Ultra (156.154.71.1) - 405 puta, Comodo Secure (8.26.56.26) - 435 puta, DNS.Watch (84.200.69.80) - 486 puta i Norton ConnectSafe (199.85.126.10) - 569 Za servere bazirane na BIND 9.12.3, zbog paralelizacije zahteva, nivo pojačanja može dostići i do 1000. U Knot Resolveru 5.1.0 nivo pojačanja je otprilike nekoliko desetina puta (24-48), od određivanja NS imena se izvode sekvencijalno i oslanjaju se na interno ograničenje broja koraka rješavanja imena dozvoljenih za jedan zahtjev.
Postoje dvije glavne strategije odbrane. Za sisteme sa DNSSEC koristite kako bi se spriječilo zaobilaženje DNS keš memorije jer se zahtjevi šalju s nasumičnim imenima. Suština metode je da generiše negativne odgovore bez kontaktiranja autoritativnih DNS servera, koristeći provjeru opsega putem DNSSEC-a. Jednostavniji pristup je ograničavanje broja imena koja se mogu definirati prilikom obrade jednog delegiranog zahtjeva, ali ovaj metod može uzrokovati probleme s nekim postojećim konfiguracijama jer ograničenja nisu definirana u protokolu.
izvor: opennet.ru