NXNSAttack erasoa DNS konpontzaile guztiei eragiten die

Tel Aviveko Unibertsitateko eta Herzliyako (Israel) Diziplinarteko Zentroko ikertzaile talde bat garatu da eraso metodo berria NXNSAttack (PDF), edozein DNS konpontzaile trafiko-anplifikatzaile gisa erabiltzeko aukera ematen dizu, pakete kopuruari dagokionez 1621 aldiz arteko anplifikazio-tasa emanez (ebazleari bidalitako eskaera bakoitzeko, biktimaren zerbitzarira bidaltzeko 1621 eskaera lor ditzakezu). eta gehienez 163 aldiz trafikoari dagokionez.

Arazoa protokoloaren berezitasunekin lotuta dago eta kontsulta prozesamendu errekurtsiboa onartzen duten DNS zerbitzari guztiei eragiten die, besteak beste. BIND (CVE-2020-8616) Korapilo (CVE-2020-12667) PowerDNS (CVE-2020-10995) Windows DNS zerbitzaria ΠΈ Lotu gabe (CVE-2020-12662), baita Google, Cloudflare, Amazon, Quad9, ICANN eta beste enpresa batzuen DNS zerbitzu publikoak ere. Konponketa DNS zerbitzariaren garatzaileekin koordinatu zen, eta aldi berean eguneraketak kaleratu zituzten beren produktuen ahultasuna konpontzeko. Argitalpenetan inplementatutako erasoen babesa
Lotu gabe 1.10.1, Korapiloen ebazpena 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

Erasoa erasotzaileak aurrez ikusi gabeko fikziozko NS erregistro kopuru handi bati erreferentzia egiten dioten eskaerak erabiltzen ditu, eta izenaren zehaztapena eskuordetzen da, baina erantzunean NS zerbitzarien IP helbideei buruzko informazioa duten kola-erregistroak zehaztu gabe. Adibidez, erasotzaile batek sd1.attacker.com izena ebazteko kontsulta bat bidaltzen du attacker.com domeinuaren ardura duen DNS zerbitzaria kontrolatuz. Erasotzailearen DNS zerbitzariari ebazleak egindako eskaerari erantzunez, sd1.attacker.com helbidearen zehaztapena biktimaren DNS zerbitzariari delegatzen dion erantzuna ematen da, erantzunean NS erregistroak adieraziz IP NS zerbitzariak zehaztu gabe. Aipatutako NS zerbitzaria aurretik topatu ez denez eta bere IP helbidea zehaztu ez denez, ebazpena NS zerbitzariaren IP helbidea zehazten saiatzen da biktimaren DNS zerbitzariari xede-domeinua (victim.com) zerbitzatzen duen kontsulta bat bidaliz.

NXNSAttack erasoa DNS konpontzaile guztiei eragiten die

Arazoa da erasotzaileak errepikatzen ez diren NS zerbitzarien zerrenda handi batekin erantzun dezakeela fikziozko biktimen azpidomeinu-izenak existitzen ez direnak (fake-1.victim.com, fake-2.victim.com,... fake-1000). biktima.com). Ebazlea biktimaren DNS zerbitzariari eskaera bat bidaltzen saiatuko da, baina domeinua aurkitu ez dela dioen erantzuna jasoko du, ondoren zerrendako hurrengo NS zerbitzaria zehazten saiatuko da, eta abar guztiak probatu arte. Erasotzaileak zerrendatutako NS erregistroak. Horren arabera, erasotzaile baten eskaerarako, ebazleak eskaera ugari bidaliko ditu NS ostalariak zehazteko. NS zerbitzariaren izenak ausaz sortzen direnez eta existitzen ez diren azpidomeinuei erreferentzia egiten zaienez, ez dira cachetik ateratzen eta erasotzailearen eskaera bakoitzak biktimaren domeinua zerbitzatzen duen DNS zerbitzariari eskaera ugari eragiten ditu.

NXNSAttack erasoa DNS konpontzaile guztiei eragiten die

DNS konpontzaile publikoek arazoaren aurrean duten ahultasun-maila aztertu zuten ikertzaileek eta zehaztu zuten CloudFlare ebazleari (1.1.1.1) kontsultak bidaltzean pakete kopurua (PAF, Packet Amplification Factor) 48 aldiz handitzea posible dela, Google-k. (8.8.8.8) - 30 aldiz, FreeDNS (37.235.1.174) - 50 aldiz, OpenDNS (208.67.222.222) - 32 aldiz. Adierazle nabarmenagoak ikusten dira
3. maila (209.244.0.3) - 273 aldiz, Quad9 (9.9.9.9) - 415 aldiz
SafeDNS (195.46.39.39) - 274 aldiz, Verisign (64.6.64.6) - 202 aldiz,
Ultra (156.154.71.1) - 405 aldiz, Comodo Secure (8.26.56.26) - 435 aldiz, DNS.Watch (84.200.69.80) - 486 aldiz eta Norton ConnectSafe (199.85.126.10) - 569 aldiz. BIND 9.12.3-n oinarritutako zerbitzarietarako, eskaeren paralelismoa dela eta, irabazi-maila 1000era arte irits daiteke. Knot Resolver 5.1.0-n, irabazi-maila gutxi gorabehera hamarnaka aldiz (24-48) da, eta NS izenak sekuentzialki egiten dira eta eskaera baterako onartzen diren izenak ebazteko urratsen barne-mugan oinarritzen dira.

Bi defentsa estrategia nagusi daude. DNSSEC duten sistemetarako proposatu erabiltzea RFC-8198 DNS cache saihesteko eskaerak ausazko izenekin bidaltzen direlako. Metodoaren funtsa erantzun negatiboak sortzea da DNS zerbitzari autoritarioekin harremanetan jarri gabe, DNSSEC bidez barrutiaren egiaztapena erabiliz. Ikuspegi sinpleagoa da eskuordetutako eskaera bakarra prozesatzen denean definitu daitezkeen izen kopurua mugatzea, baina metodo honek arazoak sor ditzake dauden konfigurazio batzuekin, mugak protokoloan definituta ez daudelako.

Iturria: opennet.ru

Gehitu iruzkin berria