Pētnieku grupa no Telavivas universitātes un starpdisciplinārā centra Herclijā (Izraēla) jauna uzbrukuma metode (), ļaujot izmantot jebkurus DNS atrisinātājus kā trafika pastiprinātājus, nodrošinot pastiprinājuma ātrumu līdz 1621 reizei pakešu skaita ziņā (katram atrisinātājam nosūtītajam pieprasījumam varat sasniegt 1621 pieprasījuma nosūtīšanu uz upura serveri) un satiksmes ziņā līdz 163 reizēm.
Problēma ir saistīta ar protokola īpatnībām un skar visus DNS serverus, kas atbalsta rekursīvo vaicājumu apstrādi, t.sk. (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), kā arī Google, Cloudflare, Amazon, Quad9, ICANN un citu uzņēmumu publiskie DNS pakalpojumi. Labojums tika saskaņots ar DNS serveru izstrādātājiem, kuri vienlaikus izlaida atjauninājumus, lai novērstu viņu produktu ievainojamību. Laidienos ieviesta aizsardzība pret uzbrukumiem
, , , .
Uzbrukuma pamatā ir uzbrucējs, izmantojot pieprasījumus, kas attiecas uz lielu skaitu iepriekš neredzētu fiktīvu NS ierakstu, kuriem tiek deleģēta nosaukuma noteikšana, bet atbildē nenorādot līmes ierakstus ar informāciju par NS serveru IP adresēm. Piemēram, uzbrucējs nosūta vaicājumu, lai atrisinātu nosaukumu sd1.attacker.com, kontrolējot DNS serveri, kas ir atbildīgs par domēnu attacker.com. Atbildot uz atrisinātāja pieprasījumu uzbrucēja DNS serverim, tiek izdota atbilde, kas deleģē sd1.attacker.com adreses noteikšanu upura DNS serverim, atbildē norādot NS ierakstus, neprecizējot IP NS serverus. Tā kā iepriekš minētais NS serveris nav sastapts un tā IP adrese nav norādīta, atrisinātājs mēģina noteikt NS servera IP adresi, nosūtot vaicājumu upura DNS serverim, kas apkalpo mērķa domēnu (victim.com).
Problēma ir tāda, ka uzbrucējs var atbildēt ar milzīgu sarakstu ar neatkārtotiem NS serveriem ar neeksistējošiem fiktīviem upuru apakšdomēnu nosaukumiem (fake-1.victim.com, fake-2.victim.com,... fake-1000. upuris.com). Atrisinātājs mēģinās nosūtīt pieprasījumu upura DNS serverim, bet saņems atbildi, ka domēns nav atrasts, pēc tam mēģinās noteikt nākamo NS serveri sarakstā un tā tālāk, līdz būs izmēģinājis visus Uzbrucēja uzskaitītie NS ieraksti. Attiecīgi vienam uzbrucēja pieprasījumam atrisinātājs nosūtīs milzīgu skaitu pieprasījumu, lai noteiktu NS saimniekdatorus. Tā kā NS serveru nosaukumi tiek ģenerēti nejauši un attiecas uz neesošiem apakšdomēniem, tie netiek izgūti no kešatmiņas, un katrs uzbrucēja pieprasījums rada pieprasījumu virkni DNS serverim, kas apkalpo upura domēnu.
Pētnieki pētīja publisko DNS risinātāju neaizsargātības pakāpi pret problēmu un konstatēja, ka, nosūtot vaicājumus uz CloudFlare atrisinātāju (1.1.1.1), ir iespējams palielināt pakešu skaitu (PAF, Packet Amplification Factor) par 48 reizēm, Google (8.8.8.8) - 30 reizes, FreeDNS (37.235.1.174) - 50 reizes, OpenDNS (208.67.222.222) - 32 reizes. Pamanāmāki rādītāji tiek novēroti par
3. līmenis (209.244.0.3) - 273 reizes, Quad9 (9.9.9.9) - 415 reizes
SafeDNS (195.46.39.39) — 274 reizes, Verisign (64.6.64.6) — 202 reizes,
Ultra (156.154.71.1) - 405 reizes, Comodo Secure (8.26.56.26) - 435 reizes, DNS.Watch (84.200.69.80) - 486 reizes un Norton ConnectSafe (199.85.126.10) - 569 reizes. Serveriem, kuru pamatā ir BIND 9.12.3, pieprasījumu paralēlizācijas dēļ pastiprinājuma līmenis var sasniegt pat 1000. Knot Resolver 5.1.0 pastiprinājuma līmenis ir aptuveni vairākus desmitus reižu (24-48), kopš NS nosaukumi tiek veikti secīgi un balstās uz iekšējo ierobežojumu vienam pieprasījumam atļauto nosaukumu atrisināšanas darbību skaitam.
Ir divas galvenās aizsardzības stratēģijas. Sistēmām ar DNSSEC izmantot lai novērstu DNS kešatmiņas apiešanu, jo pieprasījumi tiek nosūtīti ar nejaušiem nosaukumiem. Metodes būtība ir ģenerēt negatīvas atbildes, nesazinoties ar autoritatīviem DNS serveriem, izmantojot diapazona pārbaudi, izmantojot DNSSEC. Vienkāršāka pieeja ir ierobežot to nosaukumu skaitu, ko var definēt, apstrādājot vienu deleģēto pieprasījumu, taču šī metode var radīt problēmas ar dažām esošajām konfigurācijām, jo ierobežojumi nav definēti protokolā.
Avots: opennet.ru