Un grupo de investigadores de la Universidad de Tel Aviv y del Centro Interdisciplinario de Herzlía (Israel) un nuevo método de ataque (), que permite utilizar cualquier resolutor DNS como amplificadores de tráfico, proporcionando un grado de amplificación de hasta 1621 veces en número de paquetes (por cada solicitud enviada al resolutor, se puede lograr el envío de 1621 solicitudes al servidor de la víctima) y hasta 163 veces en tráfico.
El problema está relacionado con las características del protocolo y afecta a todos los servidores DNS que soportan el procesamiento recursivo de solicitudes, incluyendo (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), y (CVE-2020-12662), así como a los servicios DNS públicos de Google, Cloudflare, Amazon, Quad9, ICANN y otras compañías. La corrección del problema fue coordinada con los desarrolladores de servidores DNS, quienes lanzaron simultáneamente actualizaciones que solucionaban la vulnerabilidad en sus productos. La protección contra el ataque se implementó en las versiones
, , , .
El ataque se basa en el uso de solicitudes del atacante que hacen referencia a un gran número de registros NS ficticios que nunca se habían encontrado anteriormente, a los que se les delega la resolución de nombres, pero sin incluir en la respuesta registros glue con información sobre las direcciones IP de los servidores NS. Por ejemplo, el atacante envía una solicitud para resolver el nombre sd1.attacker.com, controlando el servidor DNS responsable del dominio attacker.com. En respuesta a la consulta del resolutor al servidor DNS del atacante, se proporciona una respuesta que delega la resolución de la dirección sd1.attacker.com al servidor DNS de la víctima a través de la indicación en la respuesta de los registros NS sin detallar las IP de los servidores NS. Dado que el mencionado servidor NS no se había encontrado anteriormente y su dirección IP no está especificada, el resolutor intenta determinar la dirección IP del servidor NS enviando una solicitud al servidor DNS de la víctima que atiende el dominio objetivo (victim.com).
El problema es que un atacante puede devolver una enorme lista de servidores NS únicos con nombres de subdominios ficticios que no existen de la víctima (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). El resolutor intentará enviar la consulta al servidor DNS de la víctima, pero recibirá una respuesta indicando que el dominio no se encontró, tras lo cual intentará determinar el siguiente servidor NS en la lista y así sucesivamente, hasta que haya agotado todos los registros NS enumerados por el atacante. En consecuencia, por cada consulta del atacante, el resolutor enviará una enorme cantidad de consultas para determinar los hosts NS. Dado que los nombres de los servidores NS se generan de forma aleatoria y hacen referencia a subdominios inexistentes, no se extraen de la caché y cada consulta del atacante provoca una avalancha de consultas al servidor DNS que atenderá el dominio de la víctima.
Los investigadores han estudiado el grado de vulnerabilidad de los resolutores DNS públicos y han determinado que al enviar consultas al resolutor de CloudFlare (1.1.1.1) se puede lograr un aumento en el número de paquetes (PAF, Factor de Amplificación de Paquetes) de 48 veces, Google (8.8.8.8) — 30 veces, FreeDNS (37.235.1.174) — 50 veces, OpenDNS (208.67.222.222) — 32 veces. Se observan cifras aún más notables para
Level3 (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 los servidores basados en BIND 9.12.3, gracias a la paralelización de las consultas, el nivel de amplificación puede llegar a alcanzar hasta 1000. En Knot Resolver 5.1.0, el nivel de amplificación es de aproximadamente varias decenas de veces (24-48), ya que la determinación de los nombres NS se realiza de manera secuencial y se enfrenta a una limitación interna en la cantidad de pasos de resolución de nombres permitidos para una sola consulta.
Se destacan dos estrategias principales de protección. Para sistemas con DNSSEC utilizar para prevenir el elusión de caché DNS, ya que las consultas se envían con nombres aleatorios. La esencia del método es generar respuestas negativas sin recurrir a servidores DNS autoritativos, empleando una verificación por rangos a través de DNSSEC. Un método más simple es limitar la cantidad de nombres que se pueden resolver al procesar una sola consulta delegada, pero este método puede causar problemas con algunas configuraciones existentes, ya que los límites no están definidos en el protocolo.
Fuente: opennet.ru
