Kutatók egy csoportja a Tel Aviv Egyetemről és a Herzliya-i Interdiszciplináris Központról (Izrael) új támadási módszer (), lehetővé téve bármilyen DNS-feloldó használatát forgalomerősítőként, akár 1621-szeres erősítési arányt biztosítva a csomagok számát tekintve (a feloldónak küldött kérésenként 1621 kérést érhet el az áldozat szerverére) forgalom szempontjából pedig akár 163-szor.
A probléma a protokoll sajátosságaihoz kapcsolódik, és minden DNS-kiszolgálót érint, amely támogatja a rekurzív lekérdezésfeldolgozást, beleértve a (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), valamint a Google, a Cloudflare, az Amazon, a Quad9, az ICANN és más cégek nyilvános DNS-szolgáltatásai. A javítást a DNS-kiszolgáló fejlesztőivel egyeztették, akik egyidejűleg frissítéseket adtak ki termékeik sebezhetőségének javítására. A kiadásokban megvalósított támadásvédelem
, , , .
A támadás azon alapul, hogy a támadó olyan kéréseket használ, amelyek nagyszámú, korábban nem látott fiktív NS-rekordra hivatkoznak, amelyekre a névmeghatározás delegálva van, de nem ad meg összeragasztó rekordokat az NS-kiszolgálók IP-címére vonatkozó információkkal a válaszban. Például egy támadó lekérdezést küld az sd1.attacker.com név feloldására az attacker.com tartományért felelős DNS-kiszolgáló vezérlésével. A feloldónak a támadó DNS-kiszolgálójához intézett kérésére válaszul egy olyan válasz érkezik, amely az sd1.attacker.com cím meghatározását az áldozat DNS-kiszolgálójára delegálja az NS-rekordok megjelölésével a válaszban, az IP NS-kiszolgálók részletezése nélkül. Mivel az említett NS szerverrel korábban nem találkoztunk, és annak IP-címe nincs megadva, a feloldó megkísérli meghatározni az NS szerver IP-címét úgy, hogy lekérdezést küld az áldozat céltartományt kiszolgáló DNS-kiszolgálójához (victim.com).
A probléma az, hogy a támadó a nem ismétlődő NS-kiszolgálók hatalmas listájával tud válaszolni nem létező fiktív áldozati aldomainnevekkel (fake-1.victim.com, fake-2.victim.com,... fake-1000. áldozat.com). A feloldó megpróbál kérelmet küldeni az áldozat DNS-kiszolgálójának, de azt a választ kapja, hogy a tartomány nem található, majd megpróbálja meghatározni a következő NS-kiszolgálót a listában, és így tovább, amíg az összes A támadó által felsorolt NS rekordok. Ennek megfelelően egy támadó kérésére a feloldó hatalmas számú kérést küld az NS-állomások meghatározásához. Mivel az NS-kiszolgálónevek véletlenszerűen jönnek létre, és nem létező altartományokra hivatkoznak, a rendszer nem kéri le őket a gyorsítótárból, és a támadótól érkező minden egyes kérés özönét eredményezi az áldozat tartományát kiszolgáló DNS-kiszolgálónak.
A kutatók megvizsgálták a nyilvános DNS-feloldók sérülékenységét a problémával szemben, és megállapították, hogy a CloudFlare-feloldóhoz (1.1.1.1) irányuló lekérdezések esetén 48-szorosára növelhető a csomagok száma (PAF, Packet Amplification Factor), a Google (8.8.8.8) - 30-szor, FreeDNS (37.235.1.174) - 50-szer, OpenDNS (208.67.222.222) - 32-szer. Feltűnőbb mutatók figyelhetők meg
3. szint (209.244.0.3) – 273-szor, Quad9 (9.9.9.9) – 415-szer
SafeDNS (195.46.39.39) - 274-szer, Verisign (64.6.64.6) - 202-szer,
Ultra (156.154.71.1) - 405-ször, Comodo Secure (8.26.56.26) - 435-ször, DNS.Watch (84.200.69.80) - 486-szor és Norton ConnectSafe (199.85.126.10) - 569 A BIND 9.12.3-on alapuló szervereknél a kérések párhuzamosítása miatt az erősítési szint elérheti az 1000-et is. A Knot Resolver 5.1.0-ban az erősítési szint megközelítőleg több tízszeres (24-48), mivel a Az NS nevek végrehajtása szekvenciálisan történik, és az egy kérelemhez engedélyezett névfeloldási lépések számának belső korlátján alapul.
Két fő védekezési stratégia létezik. DNSSEC rendszerekhez használatához hogy megakadályozza a DNS-gyorsítótár megkerülését, mivel a kérések véletlenszerű nevekkel kerülnek elküldésre. A módszer lényege, hogy a DNSSEC-en keresztüli tartományellenőrzés segítségével negatív válaszokat generál anélkül, hogy kapcsolatba lépne a hiteles DNS-kiszolgálókkal. Egy egyszerűbb megközelítés a meghatározható nevek számának korlátozása egyetlen delegált kérés feldolgozásakor, de ez a módszer problémákat okozhat néhány meglévő konfigurációnál, mivel a korlátozások nincsenek meghatározva a protokollban.
Forrás: opennet.ru