In groep ûndersikers fan 'e Universiteit fan Tel Aviv en it Interdisciplinary Centre yn Herzliya (Israël) nije oanfal metoade (), wêrtroch jo alle DNS-resolvers kinne brûke as ferkearsfersterkers, en in fersterkingsnivo leverje fan maksimaal 1621 kear yn termen fan it oantal pakketten (foar elk fersyk dat nei de resolver stjoerd wurdt, kinne jo 1621 oanfragen berikke dy't stjoerd wurde nei de server fan it slachtoffer) en oant 163 kear yn termen fan ferkear.
It probleem is relatearre oan de eigenaardichheden fan it protokol en hat ynfloed op alle DNS-tsjinners dy't rekursive query-ferwurking stypje, ynklusyf (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), lykas ek iepenbiere DNS-tsjinsten fan Google, Cloudflare, Amazon, Quad9, ICANN en oare bedriuwen. De fix waard koördinearre mei DNS-tsjinnerûntwikkelders, dy't tagelyk updates útbrochten om de kwetsberens yn har produkten te reparearjen. Oanfalbeskerming ymplementearre yn releases
, , , .
De oanfal is basearre op de oanfaller mei help fan fersiken dy't ferwize nei in grut oantal earder net sjoen fiktive NS records, dêr't namme fêststelling wurdt delegearre, mar sûnder oantsjutte lijm records mei ynformaasje oer de IP adressen fan NS tsjinners yn it antwurd. Bygelyks, in oanfaller stjoert in query om de namme sd1.attacker.com op te lossen troch de DNS-tsjinner te kontrolearjen dy't ferantwurdlik is foar it attacker.com-domein. As antwurd op it fersyk fan 'e resolver oan' e DNS-tsjinner fan 'e oanfaller, wurdt in antwurd útjûn dat de bepaling fan it sd1.attacker.com-adres delegearret oan' e DNS-tsjinner fan it slachtoffer troch NS-records yn 'e antwurd oan te jaan sûnder de IP NS-tsjinners te detaillearjen. Om't de neamde NS-tsjinner net earder is tsjinkaam en it IP-adres net oanjûn is, besiket de resolver it IP-adres fan 'e NS-tsjinner te bepalen troch in fraach te stjoeren nei de DNS-tsjinner fan it slachtoffer dy't it doeldomein (victim.com) tsjinnet.
It probleem is dat de oanfaller kin reagearje mei in enoarme list fan net-werheljende NS-tsjinners mei net-besteand fiktive subdomeinnammen foar slachtoffers (fake-1.victim.com, fake-2.victim.com, ... fake-1000. victim.com). De resolver sil besykje in fersyk te stjoeren nei de DNS-tsjinner fan it slachtoffer, mar sil in antwurd krije dat it domein net fûn is, wêrnei't it sil besykje de folgjende NS-tsjinner yn 'e list te bepalen, en sa fierder oant it alle NS records listed troch de oanfaller. Dêrom sil de resolver foar it fersyk fan ien oanfaller in enoarm oantal oanfragen stjoere om NS-hosts te bepalen. Sûnt NS tsjinner nammen wurde generearre willekeurich en ferwize nei net-besteande subdomains, se wurde net ophelle út de cache en elk fersyk fan de oanfaller resultearret yn in fleury fan fersiken nei de DNS tsjinner tsjinje it slachtoffer syn domein.
Undersikers ûndersochten de mjitte fan kwetsberens fan iepenbiere DNS-resolvers foar it probleem en bepale dat by it ferstjoeren fan fragen nei de CloudFlare-resolver (1.1.1.1), it mooglik is om it oantal pakketten (PAF, Packet Amplification Factor) mei 48 kear te ferheegjen, Google (8.8.8.8) - 30 kear, FreeDNS (37.235.1.174) - 50 kear, OpenDNS (208.67.222.222) - 32 kear. Mear opfallende yndikatoaren wurde waarnommen foar
Level3 (209.244.0.3) - 273 kear, Quad9 (9.9.9.9) - 415 kear
SafeDNS (195.46.39.39) - 274 kear, Verisign (64.6.64.6) - 202 kear,
Ultra (156.154.71.1) - 405 kear, Comodo Secure (8.26.56.26) - 435 kear, DNS.Watch (84.200.69.80) - 486 kear, en Norton ConnectSafe (199.85.126.10 kear) - 569 kear. Foar tsjinners basearre op BIND 9.12.3, troch parallelisaasje fan fersiken, kin it winstnivo oant 1000. Yn Knot Resolver 5.1.0 is it winstnivo sawat ferskate tsientallen kearen (24-48), sûnt de bepaling fan NS-nammen wurdt opfolgjend útfierd en berustet op de ynterne limyt op it oantal nammeresolúsjestappen tastien foar ien fersyk.
D'r binne twa wichtichste ferdigeningsstrategyen. Foar systemen mei DNSSEC brûke om DNS-cache bypass te foarkommen, om't fersiken wurde ferstjoerd mei willekeurige nammen. De essinsje fan 'e metoade is om negative antwurden te generearjen sûnder kontakt te meitsjen mei autoritative DNS-tsjinners, mei berikkontrôle fia DNSSEC. In ienfâldiger oanpak is om it oantal nammen te beheinen dat kin wurde definieare by it ferwurkjen fan ien delegearre fersyk, mar dizze metoade kin problemen feroarsaakje mei guon besteande konfiguraasjes, om't de grinzen net definieare binne yn it protokol.
Boarne: opennet.ru