A Tel-Aviv Egyetem és a Herzlívai Interdiszciplináris Központ kutatócsoportja (Izrael) az új támadási módszert (), amely lehetővé teszi bármilyen DNS-rezolver áramlásának fokozását, akár 1621-szeres fokozással a csomagok számában (minden egyes, a rezolverhez küldött kérés esetén 1621 kérés küldhető a célkiszolgálóhoz) és akár 163-szoros fokozással a forgalomban.
A probléma a protokoll működésének sajátosságaival kapcsolatos, és minden DNS-szervert érint, amely támogatja a rekurzív kérésfeldolgozást, beleértve a (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), és (CVE-2020-12662), valamint a Google, Cloudflare, Amazon, Quad9, ICANN és más cégek nyilvános DNS-szolgáltatásait. A probléma megoldását a DNS-szerverek fejlesztőivel koordinálták, akik egyszerre adták ki az érzékenység kiküszöbölésével kapcsolatos frissítéseket termékeikben. A támadás ellen védelmet nyújtanak a kiadások:
, , , .
A támadás alapja, hogy a támadó olyan lekérdezéseket használ, amelyek nagy számú korábban nem látott fiktív NS-rekordra hivatkoznak, amelyeknek delegált névmeghatározásukat kell végezniük, de a válaszban nem szerepelnek a NS-szerverek IP-címéről szóló glue-rekordok. Például a támadó kérdést küld a sd1.attacker.com név meghatározására, miközben az attacker.com domainért felelős DNS-szervert irányítja. Amikor a rezolver a támadó DNS-szerverhez fordul, egy olyan választ kap, amely delegálja a sd1.attacker.com név címének meghatározását a céljogosultat tartalmazó NS-rekordok megadásával, a NS-szerverek IP-részletezése nélkül. Mivel a említett NS-szerver korábban nem találkozott, és IP-címe nem szerepel, a rezolver megpróbálja meghatározni a NS-szerver IP-címét, kérdést küldve a céljogosult domain (victim.com) DNS-szerveréhez.
A probléma az, hogy a támadó hatalmas, nem ismétlődő NS-szerverek listáját adhatja meg a válaszban, amelyek fiktív nevű aldomain-eket használnak, mint például (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). A resolver megpróbálja elküldeni a lekérdezést a sértett DNS-szerveréhez, de azt a választ kapja, hogy a domain nem található, majd megkísérli meghatározni a következő NS-szervert a listában, és így folytatja, amíg el nem fogy az összes, a támadó által felsorolt NS-felvétel. Ennek megfelelően egy támadói lekérdezésre a resolver hatalmas számú lekérdezést küld az NS-hosztok meghatározásához. Mivel az NS-szerverek neve véletlenszerűen keletkezik, és nem létező aldomain-ekre mutatnak, nem kerülnek a cache-be, és minden támadói lekérdezés özönnyi lekérdezést eredményez a sértett domain DNS-szerveréhez.
A kutatók megvizsgálták a nyilvános DNS-reszolverek sebezhetőségét, és megállapították, hogy a CloudFlare (1.1.1.1) reszolverhez küldött lekérdezések esetén 48-szoros csomagfelerősödés (PAF, Packet Amplification Factor) érhető el, a Google (8.8.8.8) esetén 30-szor, a FreeDNS (37.235.1.174) esetén 50-szer, az OpenDNS (208.67.222.222) a szám 32-szeres. A figyelemre méltóbb mutatók a
Level3 (209.244.0.3) esetén 273-szoros, a Quad9 (9.9.9.9) esetén 415-szörös.
SafeDNS (195.46.39.39) esetén 274-szeres, a Verisign (64.6.64.6) pedig 202-szeres,
Ultra (156.154.71.1) esetén 405-szörös, a Comodo Secure (8.26.56.26) 435-szörös, a DNS.Watch (84.200.69.80) 486-szor, és a Norton ConnectSafe (199.85.126.10) pedig 569-szeres. A BIND 9.12.3 alapú szerverek esetén a lekérdezések párhuzamosítása révén az erősítés mértéke elérheti az 1000-et. A Knot Resolver 5.1.0 esetében az erősítés mértéke körülbelül néhány tucat (24-48) alkalom, mivel az NS-nevek meghatározása sorozatosan történik, és belső korlátok ütköznek a nevek feloldásához megengedett lépések számában, amelyeket egy lekérdezés során használnak.
Két fő védelmi stratégiát emelnek ki. A DNSSEC rendszerhez használni a DNS-cache megkerülésének megakadályozására, mivel az lekérdezések véletlenszerű nevekkel történnek. A módszer lényege, hogy negatív válaszokat generálunk anélkül, hogy hiteles DNS-szerverekhez fordulnánk, a DNSSEC segítségével történő tartomány-ellenőrzéssel. Egy egyszerűbb módszer a neveket korlátozni az egy delegált lekérdezés feldolgozása során, de ez a módszer problémákat okozhat egyes meglévő konfigurációkkal, mivel a határok nincsenek meghatározva a protokollban.
Forrás: opennet.ru
