Sulmi NXNSAttack, e cila prek të gjithë zgjidhësit DNS

Një grup kërkuesish nga Universiteti i Tel Avivit dhe Qendra Ndërdisiplinore në Herzliya (Izrael) ka zhvilluar një metodë të re sulmi NXNSAttack (PDF), e cila lejon përdorimin e çdo zgjidhësi DNS si forcues trafiku, që ofron një gradë forcimi deri në 1621 herë në numrin e paketave (për çdo kërkesë që dërgohet në zgjidhësin, mund të arrihet dërgimi në serverin e viktimës të 1621 kërkesave) dhe deri në 163 herë për trafik.

Problemi është i lidhur me veçoritë e funksionimit të protokollit dhe prek të gjithë serverët DNS që mbështesin përpunimin rekurziv të kërkesave, përfshirë BIND (CVE-2020-8616), Knot (CVE-2020-12667), PowerDNS (CVE-2020-10995), Windows DNS Server dhe Unbound (CVE-2020-12662), si dhe shërbimet publike DNS të Google, Cloudflare, Amazon, Quad9, ICANN dhe kompanive të tjera. Rregullimi i problemit u koordinua me zhvilluesit e serverëve DNS, të cilët në të njëjtën kohë lëshuan përditësime me rregullimin e dobësisë në produktet e tyre. Mbrojtja ndaj sulmit është implementuar në versionet
Unbound 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.

Sulmi bazohet në përdorimin nga sulmuesi të kërkesave që referohen në një numër të madh NS-rekordesh fiktive që nuk janë hasur më parë, të cilave u delegohet përcaktimi i emrit, por pa treguar në përgjigje rekordet glue me informacion mbi adresat IP të serverëve NS. Për shembull, sulmuesi dërgon një kërkesë për përcaktimin e emrit sd1.attacker.com, duke kontrolluar serverin DNS që është përgjegjës për domenin attacker.com. Në përgjigje të kërkesës së zgjidhësit ndaj serverit DNS të sulmuesit, jepet një përgjigje që delegon përcaktimin e adresës sd1.attacker.com te serveri DNS i viktimës duke treguar në përgjigje rekordet NS pa detaje për IP-të e serverëve NS. Pasi 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ë kërkesë te serveri DNS i viktimës, që shërben domenin e synuar (victim.com).

Sulmi NXNSAttack, e cila prek të gjithë zgjidhësit DNS

Problemi është se sulmuesi mund të japë në përgjigje një listë të madhe NS-serverësh të pa përsëritur me emra domenerësh të rremë të paekzistueshëm të nën-domenit të viktimës (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). Rezolveri do të përpiqet të dërgojë një kërkesë në DNS-serverin e viktimës, por do të marrë një përgjigje se domeni nuk është gjetur, dhe më pas do të përpiqet të përcaktojë NS-serverin tjetër në listë dhe kështu me radhë, derisa të kalojë të gjitha regjistrimet NS të caktuara nga sulmuesi. Prandaj, për çdo kërkesë nga sulmuesi, rezolveri do të dërgojë një numër të madh kërkesash për të përcaktuar hostet NS. Duke qenë se emrat e NS-serverëve formohen rastësisht dhe i referohen nën-domenëve të paekzistueshëm, ata nuk nxirren nga keq-ruajtja dhe çdo kërkesë nga sulmuesi çon në një valë kërkesash në DNS-serverin që shqetëson domenin e viktimës.

Sulmi NXNSAttack, e cila prek të gjithë zgjidhësit DNS

Kërkuesit kanë studiuar shkallën e ndjeshmërisë së DNS-rezolverëve publikë dhe kanë konstatuar se duke dërguar kërkesa në rezolverin CloudFlare (1.1.1.1) mund të arrihet një rritje e numrit të paketave (PAF, Packet Amplification Factor) deri në 48 herë, Google (8.8.8.8) deri në 30 herë, FreeDNS (37.235.1.174) deri në 50 herë, OpenDNS (208.67.222.222) deri në 32 herë. Shifrat më të dukshme vërehen për
Level3 (209.244.0.3) deri në 273 herë, Quad9 (9.9.9.9) deri në 415 herë
SafeDNS (195.46.39.39) deri në 274 herë, Verisign (64.6.64.6) deri në 202 herë,
Ultra (156.154.71.1) deri në 405 herë, Comodo Secure (8.26.56.26) deri në 435 herë, DNS.Watch (84.200.69.80) deri në 486 herë, dhe Norton ConnectSafe (199.85.126.10) deri në 569 herë. Për serverët e bazuar në BIND 9.12.3, përmes paralelizimit të kërkesave, niveli i amplifikimit mund të arrijë deri në 1000. Në Knot Resolver 5.1.0, niveli i amplifikimit është rreth disa dhjetëra herë (24-48), pasi përcaktimi i emrave NS është realizuar radhazi dhe përballet me një kufizim të brendshëm mbi numrin e hapave të përcaktimit të emrave të lejuar për një kërkesë.

Identifikohen dy strategji kryesore mbrojtjeje. Për sistemet me DNSSEC propozohet të përdorë RFC-8198 për të parandaluar shmangien e keq-ruajtjes së DNS, pasi kërkesat dërgohen me emra rastësorë. Thelbi i metodës është në gjenerimin e përgjigjeve negative pa u drejtuar në DNS-serverët autoritativ, duke përdorur verifikimin përmes intervaleve përmes DNSSEC. Një mënyrë më e thjeshtë është kufizimi i numrit të emrave që mund të përcaktohen gjatë trajtimit të një kërkese të deleguar, por ky metodë mund të sjellë probleme me disa konfigurime ekzistuese, pasi kufijtë nuk janë të përcaktuar në protokoll.

Burimi: opennet.ru

Blini hostim të besueshëm për faqe interneti me mbrojtje DDoS, serverë VPS VDS 🔥 Blini hostim të besueshëm për faqe interneti me mbrojtje DDoS, serverë VPS VDS - ProHoster