Un grup d'investigadors de la Universitat de Tel Aviv i del Centre Interdisciplinari d'Herzliya (Israel) nou mètode d'atac (), que us permet utilitzar qualsevol resolutor DNS com a amplificador de trànsit, proporcionant una taxa d'amplificació de fins a 1621 vegades en termes de nombre de paquets (per a cada sol·licitud enviada al resolutor, podeu aconseguir 1621 sol·licituds enviades al servidor de la víctima) i fins a 163 vegades en termes de trànsit.
El problema està relacionat amb les peculiaritats del protocol i afecta tots els servidors DNS que admeten el processament recursiu de consultes, inclosos (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), així com els serveis públics de DNS de Google, Cloudflare, Amazon, Quad9, ICANN i altres empreses. La correcció es va coordinar amb els desenvolupadors de servidors DNS, que simultàniament van publicar actualitzacions per solucionar la vulnerabilitat dels seus productes. Protecció contra atacs implementada a les versions
, , , .
L'atac es basa en que l'atacant utilitza sol·licituds que fan referència a un gran nombre de registres NS ficticis abans no vists, als quals es delega la determinació del nom, però sense especificar registres de cola amb informació sobre les adreces IP dels servidors NS a la resposta. Per exemple, un atacant envia una consulta per resoldre el nom sd1.attacker.com controlant el servidor DNS responsable del domini attacker.com. En resposta a la sol·licitud del resolutor al servidor DNS de l'atacant, s'emet una resposta que delega la determinació de l'adreça sd1.attacker.com al servidor DNS de la víctima indicant els registres NS a la resposta sense detallar els servidors IP NS. Com que el servidor NS esmentat no s'ha trobat abans i no s'ha especificat la seva adreça IP, el resolutor intenta determinar l'adreça IP del servidor NS enviant una consulta al servidor DNS de la víctima que serveix el domini objectiu (victim.com).
El problema és que l'atacant pot respondre amb una llista enorme de servidors NS que no es repeteixen amb noms de subdomini de víctimes ficticis inexistents (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). El resolutor intentarà enviar una sol·licitud al servidor DNS de la víctima, però rebrà una resposta que el domini no s'ha trobat, després del qual intentarà determinar el següent servidor NS de la llista, i així successivament fins que hagi provat totes les Registres NS enumerats per l'atacant. En conseqüència, per a la sol·licitud d'un atacant, el resolutor enviarà un gran nombre de sol·licituds per determinar els amfitrions NS. Com que els noms dels servidors NS es generen aleatòriament i fan referència a subdominis inexistents, no es recuperen de la memòria cau i cada sol·licitud de l'atacant dóna lloc a una sèrie de peticions al servidor DNS que serveix el domini de la víctima.
Els investigadors van estudiar el grau de vulnerabilitat dels solucionadors de DNS públics davant el problema i van determinar que quan s'envien consultes al solucionador de CloudFlare (1.1.1.1), és possible augmentar 48 vegades el nombre de paquets (PAF, Factor d'amplificació de paquets), Google. (8.8.8.8) - 30 vegades, FreeDNS (37.235.1.174) - 50 vegades, OpenDNS (208.67.222.222) - 32 vegades. S'observen indicadors més notables
Nivell 3 (209.244.0.3) - 273 vegades, Quad9 (9.9.9.9) - 415 vegades
SafeDNS (195.46.39.39) - 274 vegades, Verisign (64.6.64.6) - 202 vegades,
Ultra (156.154.71.1) - 405 vegades, Comodo Secure (8.26.56.26) - 435 vegades, DNS.Watch (84.200.69.80) - 486 vegades i Norton ConnectSafe (199.85.126.10) - 569 vegades. Per als servidors basats en BIND 9.12.3, a causa de la paral·lelització de peticions, el nivell de guany pot arribar fins a 1000. A Knot Resolver 5.1.0, el nivell de guany és aproximadament diverses desenes de vegades (24-48), ja que la determinació de Els noms NS es realitzen de manera seqüencial i es basa en el límit intern del nombre de passos de resolució de noms permesos per a una sol·licitud.
Hi ha dues estratègies de defensa principals. Per a sistemes amb DNSSEC ús per evitar l'evitació de la memòria cau DNS perquè les sol·licituds s'envien amb noms aleatoris. L'essència del mètode és generar respostes negatives sense contactar amb servidors DNS autoritzats, utilitzant la comprovació de rang mitjançant DNSSEC. Un enfocament més senzill és limitar el nombre de noms que es poden definir quan es processa una única sol·licitud delegada, però aquest mètode pot causar problemes amb algunes configuracions existents perquè els límits no estan definits al protocol.
Font: opennet.ru