Un grupo de investigadores de la Universidad de Tel Aviv y del Centro Interdisciplinario de Herzliya (Israel) nuevo método de ataque (), lo que le permite utilizar cualquier solucionador de DNS como amplificador de tráfico, proporcionando una tasa de amplificación de hasta 1621 veces en términos de cantidad de paquetes (por cada solicitud enviada al solucionador, puede lograr que se envíen 1621 solicitudes al servidor de la víctima) y hasta 163 veces en términos de tráfico.
El problema está relacionado con las peculiaridades del protocolo y afecta a todos los servidores DNS que admiten el procesamiento de consultas recursivas, incluidos (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), и (CVE-2020-12662), así como servicios DNS públicos de Google, Cloudflare, Amazon, Quad9, ICANN y otras empresas. La solución se coordinó con los desarrolladores del servidor DNS, quienes simultáneamente lanzaron actualizaciones para corregir la vulnerabilidad en sus productos. Protección contra ataques implementada en versiones
, , , .
El ataque se basa en que el atacante utiliza solicitudes que hacen referencia a una gran cantidad de registros NS ficticios nunca antes vistos, a los que se delega la determinación del nombre, pero sin especificar registros adhesivos con información sobre las direcciones IP de los servidores NS en la respuesta. Por ejemplo, un atacante envía una consulta para resolver el nombre sd1.attacker.com controlando el servidor DNS responsable del dominio attacker.com. En respuesta a la solicitud del solucionador al servidor DNS del atacante, se emite una respuesta que delega la determinación de la dirección sd1.attacker.com al servidor DNS de la víctima indicando registros NS en la respuesta sin detallar los servidores IP NS. Dado que el servidor NS mencionado no se ha encontrado antes y su dirección IP no está especificada, el solucionador intenta determinar la dirección IP del servidor NS enviando una consulta al servidor DNS de la víctima que presta servicio al dominio de destino (victim.com).
El problema es que el atacante puede responder con una lista enorme de servidores NS no repetidos con nombres de subdominios de víctimas ficticios inexistentes (fake-1.victim.com, fake-2.victim.com,... fake-1000. víctima.com). El solucionador intentará enviar una solicitud al servidor DNS de la víctima, pero recibirá una respuesta de que no se encontró el dominio, después de lo cual intentará determinar el siguiente servidor NS en la lista, y así sucesivamente hasta que haya probado todos los Registros NS listados por el atacante. En consecuencia, para la solicitud de un atacante, el solucionador enviará una gran cantidad de solicitudes para determinar los hosts NS. Dado que los nombres de los servidores NS se generan aleatoriamente y se refieren a subdominios inexistentes, no se recuperan de la memoria caché y cada solicitud del atacante genera una avalancha de solicitudes al servidor DNS que atiende el dominio de la víctima.
Los investigadores estudiaron el grado de vulnerabilidad de los solucionadores de DNS públicos al problema y determinaron que al enviar consultas al solucionador de CloudFlare (1.1.1.1), es posible aumentar la cantidad de paquetes (PAF, factor de amplificación de paquetes) en 48 veces, según Google. (8.8.8.8) - 30 veces, FreeDNS (37.235.1.174) - 50 veces, OpenDNS (208.67.222.222) - 32 veces. Se observan indicadores más notables para
Nivel3 (209.244.0.3) - 273 veces, Quad9 (9.9.9.9) - 415 veces
SafeDNS (195.46.39.39) - 274 veces, Verisign (64.6.64.6) - 202 veces,
Ultra (156.154.71.1): 405 veces, Comodo Secure (8.26.56.26): 435 veces, DNS.Watch (84.200.69.80): 486 veces y Norton ConnectSafe (199.85.126.10): 569 veces. Para servidores basados en BIND 9.12.3, debido a la paralelización de solicitudes, el nivel de ganancia puede alcanzar hasta 1000. En Knot Resolver 5.1.0, el nivel de ganancia es aproximadamente varias decenas de veces (24-48), desde la determinación de Los nombres NS se realizan de forma secuencial y se basan en el límite interno en la cantidad de pasos de resolución de nombres permitidos para una solicitud.
Hay dos estrategias de defensa principales. Para sistemas con DNSSEC utilizar para evitar la omisión de la caché de DNS porque las solicitudes se envían con nombres aleatorios. La esencia del método es generar respuestas negativas sin contactar servidores DNS autorizados, utilizando la verificación de rango a través de DNSSEC. Un enfoque más simple es limitar la cantidad de nombres que se pueden definir al procesar una única solicitud delegada, pero este método puede causar problemas con algunas configuraciones existentes porque los límites no están definidos en el protocolo.
Fuente: opennet.ru