Atacul NXNSAttack care afectează toate rezolutoarele DNS

Un grup de cercetători de la Universitatea Tel Aviv și Centrul Interdisciplinar din Herzliya (Israel) a dezvoltat noua metoda de atac NXNSAttack (PDF), permițându-vă să utilizați orice rezolutoare DNS ca amplificatoare de trafic, oferind o rată de amplificare de până la 1621 de ori în ceea ce privește numărul de pachete (pentru fiecare cerere trimisă către resolver, puteți obține 1621 de solicitări trimise către serverul victimei) și de până la 163 de ori în ceea ce privește traficul.

Problema este legată de particularitățile protocolului și afectează toate serverele DNS care acceptă procesarea recursivă a interogărilor, inclusiv LEGA (CVE-2020-8616) Nod (CVE-2020-12667) PowerDNS (CVE-2020-10995) Server DNS Windows и unbound (CVE-2020-12662), precum și servicii DNS publice ale Google, Cloudflare, Amazon, Quad9, ICANN și alte companii. Remedierea a fost coordonată cu dezvoltatorii de servere DNS, care au lansat simultan actualizări pentru a remedia vulnerabilitatea în produsele lor. Protecție împotriva atacurilor implementată în versiuni
Neconsolidat 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.

Atacul se bazează pe faptul că atacatorul folosește solicitări care se referă la un număr mare de înregistrări NS fictive nevăzute anterior, cărora le este delegată determinarea numelui, dar fără a specifica înregistrări lipite cu informații despre adresele IP ale serverelor NS în răspuns. De exemplu, un atacator trimite o interogare pentru a rezolva numele sd1.attacker.com controlând serverul DNS responsabil pentru domeniul attacker.com. Ca răspuns la solicitarea rezolutorului către serverul DNS al atacatorului, este emis un răspuns care deleagă determinarea adresei sd1.attacker.com serverului DNS al victimei, indicând înregistrările NS în răspuns fără a detalia serverele IP NS. Deoarece serverul NS menționat nu a fost întâlnit înainte și adresa sa IP nu este specificată, rezolutorul încearcă să determine adresa IP a serverului NS trimițând o interogare către serverul DNS al victimei care deservește domeniul țintă (victim.com).

Atacul NXNSAttack care afectează toate rezolutoarele DNS

Problema este că atacatorul poate răspunde cu o listă uriașă de servere NS care nu se repetă cu nume de subdomenii de victimă fictive inexistente (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). Resolverul va încerca să trimită o cerere către serverul DNS al victimei, dar va primi un răspuns că domeniul nu a fost găsit, după care va încerca să determine următorul server NS din listă și așa mai departe până când va încerca toate Înregistrările NS listate de atacator. În consecință, pentru cererea unui atacator, soluția va trimite un număr mare de solicitări pentru a determina gazdele NS. Deoarece numele serverelor NS sunt generate aleatoriu și se referă la subdomenii inexistente, ele nu sunt preluate din cache și fiecare solicitare din partea atacatorului are ca rezultat un val de cereri către serverul DNS care deservește domeniul victimei.

Atacul NXNSAttack care afectează toate rezolutoarele DNS

Cercetătorii au studiat gradul de vulnerabilitate al rezolutorilor DNS publici la problemă și au stabilit că atunci când se trimit interogări către rezolutorul CloudFlare (1.1.1.1), este posibil să crească numărul de pachete (PAF, Packet Amplification Factor) de 48 de ori, Google. (8.8.8.8) - de 30 de ori, FreeDNS (37.235.1.174) - de 50 de ori, OpenDNS (208.67.222.222) - de 32 de ori. Se observă indicatori mai vizibili pentru
Nivelul 3 (209.244.0.3) - de 273 de ori, Quad9 (9.9.9.9) - de 415 ori
SafeDNS (195.46.39.39) - de 274 de ori, Verisign (64.6.64.6) - de 202 de ori,
Ultra (156.154.71.1) - de 405 de ori, Comodo Secure (8.26.56.26) - de 435 de ori, DNS.Watch (84.200.69.80) - de 486 de ori și Norton ConnectSafe (199.85.126.10) - de 569 de ori. Pentru serverele bazate pe BIND 9.12.3, datorită paralelizării solicitărilor, nivelul câștigului poate ajunge până la 1000. În Knot Resolver 5.1.0, nivelul câștigului este de aproximativ câteva zeci de ori (24-48), de la determinarea Numele NS se execută secvenţial şi se bazează pe limita internă a numărului de paşi de rezoluţie a numelor permise pentru o cerere.

Există două strategii principale de apărare. Pentru sisteme cu DNSSEC propus pentru a utiliza RFC-8198 pentru a preveni ocolirea memoriei cache DNS, deoarece cererile sunt trimise cu nume aleatorii. Esența metodei este de a genera răspunsuri negative fără a contacta serverele DNS autorizate, folosind verificarea intervalului prin DNSSEC. O abordare mai simplă este limitarea numărului de nume care pot fi definite la procesarea unei singure cereri delegate, dar această metodă poate cauza probleme cu unele configurații existente deoarece limitele nu sunt definite în protocol.

Sursa: opennet.ru

Adauga un comentariu