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
