NXNSAttack-atako influanta ĉiujn DNS-solvilojn

Grupo de esploristoj de Tel-Aviva Universitato kaj la Interfaka Centro en Herzliya (Israelo) disvolviĝis nova atakmetodo NXNSAtako (PDF), permesante al vi uzi iujn ajn DNS-solvilojn kiel trafikamplifilojn, disponigante plifortigon de ĝis 1621 fojojn laŭ la nombro da pakaĵetoj (por ĉiu peto sendita al la solvilo, vi povas atingi 1621 petojn senditajn al la servilo de la viktimo) kaj ĝis 163 fojojn laŭ trafiko.

La problemo rilatas al la proprecoj de la protokolo kaj influas ĉiujn DNS-servilojn kiuj subtenas rekursivan pritraktadon, inkluzive de BIND (CVE-2020-8616) nodon (CVE-2020-12667) PowerDNS (CVE-2020-10995) Vindoza DNS-Servilo и Unbound (CVE-2020-12662), same kiel publikaj DNS-servoj de Google, Cloudflare, Amazon, Quad9, ICANN kaj aliaj kompanioj. La riparo estis kunordigita kun DNS-servilaj programistoj, kiuj samtempe publikigis ĝisdatigojn por ripari la vundeblecon en siaj produktoj. Atako protekto efektivigita en eldonoj
Neligita 1.10.1, Noda Solvilo 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

La atako baziĝas sur la atakanto uzante petojn kiuj rilatas al granda nombro da antaŭe neviditaj fikciaj NS-rekordoj, al kiuj nomdetermino estas delegita, sed sen specifi gluajn rekordojn kun informoj pri la IP-adresoj de NS-serviloj en la respondo. Ekzemple, atakanto sendas demandon por solvi la nomon sd1.attacker.com kontrolante la DNS-servilon respondecan pri la domajno attacker.com. En respondo al la peto de la solvanto al la DNS-servilo de la atakanto, respondo estas elsendita kiu delegas la persistemon de la sd1.attacker.com-adreso al la DNS-servilo de la viktimo indikante NS-rekordojn en la respondo sen detaligi la IP-NS-servilojn. Ĉar la menciita NS-servilo ne estis renkontita antaŭe kaj ĝia IP-adreso ne estas precizigita, la solvanto provas determini la IP-adreson de la NS-servilo sendante demandon al la DNS-servilo de la viktimo servanta la celdomajnon (victim.com).

NXNSAttack-atako influanta ĉiujn DNS-solvilojn

La problemo estas, ke la atakanto povas respondi per grandega listo de ne-ripetantaj NS-serviloj kun neekzistantaj fikciaj viktimaj subdomajnaj nomoj (fake-1.victim.com, fake-2.victim.com,... fake-1000. viktimo.com). La solvanto provos sendi peton al la DNS-servilo de la viktimo, sed ricevos respondon, ke la domajno ne estis trovita, post kio ĝi provos determini la sekvan NS-servilon en la listo, kaj tiel plu ĝis ĝi provis ĉiujn. NS-rekordoj listigitaj de la atakanto. Sekve, por peto de unu atakanto, la solvanto sendos grandegan nombron da petoj por determini NS-gastigantojn. Ĉar NS-servilnomoj estas generitaj hazarde kaj rilatas al neekzistantaj subdomajnoj, ili ne estas prenitaj de la kaŝmemoro kaj ĉiu peto de la atakanto rezultigas ekblovon de petoj al la DNS-servilo servanta la domajnon de la viktimo.

NXNSAttack-atako influanta ĉiujn DNS-solvilojn

Esploristoj studis la gradon de vundebleco de publikaj DNS-solviloj al la problemo kaj determinis, ke sendante demandojn al la solvilo CloudFlare (1.1.1.1), eblas pliigi la nombron da pakaĵoj (PAF, Packet Amplification Factor) je 48 fojojn, Google. (8.8.8.8) - 30 fojojn, FreeDNS (37.235.1.174) - 50 fojojn, OpenDNS (208.67.222.222) - 32 fojojn. Pli rimarkindaj indikiloj estas observataj por
Nivelo3 (209.244.0.3) - 273 fojojn, Quad9 (9.9.9.9) - 415 fojojn
SafeDNS (195.46.39.39) - 274 fojojn, Verisign (64.6.64.6) - 202 fojojn,
Ultra (156.154.71.1) - 405 fojojn, Comodo Secure (8.26.56.26) - 435 fojojn, DNS.Watch (84.200.69.80) - 486 fojojn, kaj Norton ConnectSafe (199.85.126.10) - 569 fojojn. Por serviloj bazitaj sur BIND 9.12.3, pro paraleligo de petoj, la gajnonivelo povas atingi ĝis 1000. En Knot Resolver 5.1.0, la gajnonivelo estas proksimume pluraj dekoj da fojoj (24-48), ekde la determino de NS-nomoj estas farataj sinsekve kaj dependas de la interna limo de la nombro da nomsolvopaŝoj permesitaj por unu peto.

Estas du ĉefaj defendaj strategioj. Por sistemoj kun DNSSEC proponita uzi RFC-8198 malhelpi DNS kaŝmemoro preterpasi ĉar petoj estas senditaj kun hazardaj nomoj. La esenco de la metodo estas generi negativajn respondojn sen kontakti aŭtoritatajn DNS-servilojn, uzante intervalkontroladon per DNSSEC. Pli simpla aliro estas limigi la nombron da nomoj kiuj povas esti difinitaj dum prilaborado de ununura delegita peto, sed tiu metodo povas kaŭzi problemojn kun kelkaj ekzistantaj konfiguracioj ĉar la limoj ne estas difinitaj en la protokolo.

fonto: opennet.ru

Aldoni komenton