Një grup kërkuesish nga Universiteti i Tel Avivit dhe Qendra Ndërdisiplinore në Herzlië (Izrael) metoda e re e sulmit (), e cila lejon përdorimin e çdo DNS-resolveri si amplifikator trafiku, duke ofruar një shkallë amplifikimi deri në 1621 herë për numrin e paketave (për çdo kërkesë të dërguar te resolveri, mund të arrihet dërgimi i 1621 kërkesave në serverin e viktimës) dhe deri në 163 herë për trafik.
Problemi është i lidhur me veçoritë e punës së protokollit dhe preku të gjitha serverat DNS që mbështesin përpunimin rekurziv të kërkesave, përfshirë (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), dhe (CVE-2020-12662), si dhe shërbimet publike të DNS si Google, Cloudflare, Amazon, Quad9, ICANN dhe kompani 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 për të eliminuar dobësinë në produktet e tyre. Mbrojtja nga sulmi është realizuar në lëshimet
, , , .
Sulmi bazohet në përdorimin nga sulmuesi të kërkesave që referohen në një numër të madh të NS-rekordeve fiktive të pa përdorura më parë, të cilëve u delegohet përcaktimi i emrit, por pa specifikuar në përgjigje NS-rekordeve 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ë përgjigjet për domenin attacker.com. Në përgjigje të kërkesës së resolverit për serverin 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 NS-rekordet në përgjigje pa detajet IP të serverëve NS. Duke qenë se serveri NS i përmendur nuk është parë më parë dhe adresa IP e tij nuk është e specifikuar, resolveri përpiqet të përcaktojë adresën IP të serverit NS duke dërguar një kërkesë në serverin DNS të viktimës, i cili shërben domenin e synuar (victim.com).
Problemi është se sulmuesi mund të japë në përgjigje një listë të madhe me serverë NS të pa përsëritshëm me emra fiktivë të padomeneve të viktimës (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). Resolveri do të përpiqet të dërgojë një kërkesë në serverin DNS të viktimës, por do të marrë një përgjigje që tregon se domeni nuk është i gjetur, pas së cilës do të përpiqet të përcaktojë NS-serverin e radhës në listë dhe kështu deri sa të shpenzojë të gjitha NS-rekordet e renditura nga sulmuesi. Si rezultat, për çdo kërkesë të sulmuesit, resolveri do të dërgojë një numër të madh kërkesash për të përcaktuar NS-hostet. Duke qenë se emrat e serverëve NS formohen rastësisht dhe referohen në subdomena të pa ekzistuese, ata nuk nxiten nga cache dhe çdo kërkesë e sulmuesit shkakton një valë kërkesash në serverin DNS që shërben domenin e viktimës.
Kërkuesit shqyrtuan shkallën e ndjeshmërisë ndaj problemit të DNS-resolverëve publikë dhe përcaktuan se gjatë dërgimit të kërkesave në resolverin CloudFlare (1.1.1.1) mund të arrihet një amplifikim të numrit të paketave (PAF, Packet Amplification Factor) deri në 48 herë, Google (8.8.8.8) — 30 herë, FreeDNS (37.235.1.174) — 50 herë, OpenDNS (208.67.222.222) — 32 herë. Të dhëna më të dukshme shihen për
Level3 (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) — 569 herë. Për serverët e bazuar në BIND 9.12.3, për shkak të paralelizmit të kërkesave, niveli i amplifikimit mund të arrijë deri në 1000. Në Knot Resolver 5.1.0, niveli i amplifikimit është rreth disa dhjetra herë (24-48), pasi përcaktimi i emrave NS bëhet në mënyrë sequential dhe ngjitet në një kufizim të brendshëm për numrin e hapjeve të përcaktimit të emrave që janë të lejuara për një kërkesë.
Dalin dy strategji kryesore mbrojtjeje. Për sistemet me DNSSEC përdorimi për të parandaluar kalimin përmes cache-it DNS, pasi kërkesat dërgohen me emra rastësorë. Thelbi i metodës është gjenerimi i përgjigjeve negative pa u drejtuar në serverët DNS autoritativë, duke përdorur verifikimin përmes diapazoneve me DNSSEC. Një mënyrë më e thjeshtë është kufizimi i numrit të emrave që mund të përcaktohen gjatë përpunimit të një kërkese të deleguar, por kjo metodë mund të sjellë probleme me disa konfiguracione ekzistuese, pasi kufizimet nuk përcaktohen në protokoll.
Burimi: opennet.ru
