Sulmi NXNSAttack që prek të gjithë zgjidhësit DNS

Një grup studiuesish nga Universiteti i Tel Avivit dhe Qendra Ndërdisiplinore në Herzliya (Izrael) ka zhvilluar Metoda e re e sulmit Sulmi NXNSA (PDF), duke ju lejuar të përdorni çdo zgjidhës DNS si përforcues trafiku, duke siguruar një shkallë përforcimi deri në 1621 herë për sa i përket numrit të paketave (për çdo kërkesë të dërguar te zgjidhësi, mund të arrini 1621 kërkesa që dërgohen në serverin e viktimës) dhe deri në 163 herë për sa i përket trafikut.

Problemi lidhet me veçoritë e protokollit dhe prek të gjithë serverët DNS që mbështesin përpunimin rekurziv të pyetjeve, duke përfshirë BIND (CVE-2020-8616) nyjë (CVE-2020-12667) PowerDNS (CVE-2020-10995) Serveri DNS i Windows и i pavarur (CVE-2020-12662), si dhe shërbimet publike DNS të Google, Cloudflare, Amazon, Quad9, ICANN dhe kompani të tjera. Rregullimi u koordinua me zhvilluesit e serverëve DNS, të cilët lëshuan njëkohësisht përditësime për të rregulluar cenueshmërinë në produktet e tyre. Mbrojtja nga sulmet e zbatuar në lëshime
Pa lidhje 1.10.1, Zgjidhësi i nyjeve 5.1.1, Rekursori PowerDNS 4.3.1, 4.2.2, 4.1.16, LIND 9.11.19, 9.14.12, 9.16.3.

Sulmi bazohet në sulmuesin duke përdorur kërkesa që i referohen një numri të madh të regjistrimeve fiktive NS të paparë më parë, të cilave u delegohet përcaktimi i emrit, por pa specifikuar regjistrime ngjitëse me informacione për adresat IP të serverëve NS në përgjigje. Për shembull, një sulmues dërgon një pyetje për të zgjidhur emrin sd1.attacker.com duke kontrolluar serverin DNS përgjegjës për domenin sulmer.com. Në përgjigje të kërkesës së zgjidhësit për serverin DNS të sulmuesit, lëshohet një përgjigje që delegon përcaktimin e adresës sd1.attacker.com te serveri DNS i viktimës duke treguar të dhënat NS në përgjigje pa detajuar serverët IP NS. Meqenëse serveri NS i përmendur nuk është hasur më parë dhe adresa e tij IP nuk është e specifikuar, zgjidhësi përpiqet të përcaktojë adresën IP të serverit NS duke dërguar një pyetje te serveri DNS i viktimës që shërben domenin e synuar (victim.com).

Sulmi NXNSAttack që prek të gjithë zgjidhësit DNS

Problemi është se sulmuesi mund të përgjigjet me një listë të madhe të serverëve NS që nuk përsëriten me emra fiktive të nëndomaineve të viktimave që nuk ekzistojnë (fake-1.victim.com, fake-2.victim.com,... fake-1000. viktima.com). Zgjidhësi do të përpiqet të dërgojë një kërkesë në serverin DNS të viktimës, por do të marrë një përgjigje se domeni nuk u gjet, pas së cilës do të përpiqet të përcaktojë serverin tjetër NS në listë, dhe kështu me radhë derisa të ketë provuar të gjitha Regjistrimet NS të listuara nga sulmuesi. Prandaj, për kërkesën e një sulmuesi, zgjidhësi do të dërgojë një numër të madh kërkesash për të përcaktuar hostet NS. Meqenëse emrat e serverëve NS krijohen në mënyrë të rastësishme dhe u referohen nëndomaineve joekzistente, ato nuk merren nga cache dhe çdo kërkesë nga sulmuesi rezulton në një mori kërkesash për serverin DNS që i shërben domenit të viktimës.

Sulmi NXNSAttack që prek të gjithë zgjidhësit DNS

Studiuesit studiuan shkallën e cenueshmërisë së zgjidhësve publik DNS ndaj problemit dhe përcaktuan se kur dërgoni pyetje në zgjidhësin CloudFlare (1.1.1.1), është e mundur të rritet numri i paketave (PAF, Faktori i Përforcimit të Paketave) me 48 herë, Google (8.8.8.8) - 30 herë, FreeDNS (37.235.1.174) - 50 herë, OpenDNS (208.67.222.222) - 32 herë. Vërehen tregues më të dukshëm për
Niveli 3 (209.244.0.3) - 273 herë, Quad9 (9.9.9.9) - 415 herë
SafeDNS (195.46.39.39) - 274 herë, Verisign (64.6.64.6) - 202 herë,
Ultra (156.154.71.1) - 405 herë, Comodo Secure (8.26.56.26) - 435 herë, DNS.Watch (84.200.69.80) - 486 herë dhe Norton ConnectSafe (199.85.126.10 herë) Për serverët e bazuar në BIND 569, për shkak të paralelizimit të kërkesave, niveli i fitimit mund të arrijë deri në 9.12.3. Në Knot Resolver 1000, niveli i fitimit është afërsisht disa dhjetëra herë (5.1.0-24), që nga përcaktimi i Emrat NS kryhet në mënyrë sekuenciale dhe mbështetet në kufirin e brendshëm të numrit të hapave të zgjidhjes së emrave të lejuar për një kërkesë.

Ekzistojnë dy strategji kryesore të mbrojtjes. Për sistemet me DNSSEC propozuar për t'u përdorur RFC-8198 për të parandaluar anashkalimin e cache DNS sepse kërkesat dërgohen me emra të rastësishëm. Thelbi i metodës është të gjeneroni përgjigje negative pa kontaktuar serverët autoritativë DNS, duke përdorur kontrollin e diapazonit përmes DNSSEC. Një qasje më e thjeshtë është kufizimi i numrit të emrave që mund të përcaktohen kur përpunohet një kërkesë e vetme e deleguar, por kjo metodë mund të shkaktojë probleme me disa konfigurime ekzistuese sepse kufijtë nuk janë të përcaktuar në protokoll.

Burimi: opennet.ru

Shto një koment