Un grupo de investigadores de la Universidad de Tsinghua y la Universidad de California en Riverside han desarrollado un nuevo tipo de ataque que permite la sustitución de datos falsos en la caché del servidor DNS, que pueden usarse para falsificar la dirección IP de un dominio arbitrario y redirigir las llamadas al dominio al servidor del atacante.

El ataque evita la protección agregada a los servidores DNS para bloquear el método clásico de envenenamiento de la caché de DNS propuesto en 2008 por Dan Kaminsky.

El método de Kaminsky manipula el tamaño insignificante del campo de identificación de la consulta de DNS, que es solo de 16 bits. Para encontrar el identificador correcto necesario para suplantar el nombre de host, basta con enviar unas 7.000 solicitudes y simular unas 140.000 respuestas falsas.

El ataque se reduce a enviar una gran cantidad de paquetes falsos vinculados a IP al resolutor de DNS con diferentes identificadores de transacciones de DNS. Para evitar que la primera respuesta se almacene en caché, en cada respuesta falsa se especifica un nombre de dominio ligeramente modificado.

Para protegerse contra este tipo de ataque, los fabricantes de servidores DNS implementaron una distribución aleatoria de los números de los puertos de la red de origen desde los que se envían las solicitudes de resolución, lo que compensó el tamaño del identificador insuficientemente grande (para enviar una respuesta ficticia, además de seleccionar un identificador de 16 bits, se hizo necesario seleccionar uno de 64 mil puertos, que aumentó el número de opciones para la selección a 2 ^ 32).

El ataque SAD DNS simplifica drásticamente la identificación de puertos al aprovechar la actividad filtrada en los puertos de red. El problema se manifiesta en todos los sistemas operativos (Linux, Windows, macOS y FreeBSD) y cuando se utilizan diferentes servidores DNS (BIND, Unbound, dnsmasq).

Se afirma que el 34% de todos los solucionadores abiertos son atacados, así como 12 de los 14 principales servicios DNS probados, incluidos los servicios 8.8.8.8 (Google), 9.9.9.9 (Quad9) y 1.1.1.1 (CloudFlare), así como 4 de 6 enrutadores probados de fabricantes reconocidos.

El problema se debe a la peculiaridad de la formación de paquetes de respuesta ICMP, que permite determinar el acceso a puertos de red activos y no utilizados a través de UDP. Esta función permite escanear muy rápidamente los puertos UDP abiertos y omitir de manera efectiva la protección basada en una selección aleatoria de puertos de red de origen, lo que reduce el número de opciones de fuerza bruta a 2 ^ 16 + 2 ^ 16 en lugar de 2 ^ 32.

La fuente del problema es el mecanismo para limitar la intensidad del envío de paquetes ICMP en la pila de la red, que utiliza un valor de contador predecible, a partir del cual comienza la limitación de envío. Este contador es común para todo el tráfico, incluido el tráfico falso del atacante y el tráfico real. De forma predeterminada, en Linux, las respuestas ICMP están limitadas a 1000 paquetes por segundo. Para cada solicitud que llega a un puerto de red cerrado, la pila de red incrementa el contador en 1 y envía un paquete ICMP con datos del puerto inalcanzable.

Por lo tanto, si envía 1000 paquetes a diferentes puertos de red, todos los cuales están cerrados, el servidor restringirá el envío de respuestas ICMP durante un segundo y el atacante puede estar seguro de que no hay puertos abiertos entre los 1000 puertos buscados. Si se envía un paquete a un puerto abierto, el servidor no devolverá una respuesta ICMP y no cambiará el valor del contador, es decir, después de que se envíen 1000 paquetes, no se alcanzará el límite de tasa de respuesta.

Dado que los paquetes falsos se llevan a cabo desde una IP falsa, el atacante no puede recibir respuestas ICMP, pero gracias al contador total, después de cada 1000 paquetes falsos, puede enviar una solicitud a un puerto inexistente desde una IP real y evaluar la llegada de la respuesta; si la respuesta llegó, entonces en uno de los 1000 paquetes. Cada segundo, un atacante puede enviar 1000 paquetes falsos a diferentes puertos y determinar rápidamente en qué bloque se encuentra el puerto abierto, luego reducir la selección y determinar un puerto específico.

El kernel de Linux resuelve el problema con un parche que aleatoriza los parámetros para limitar la intensidad del envío de paquetes ICMP, lo que introduce ruido y minimiza la fuga de datos a través de canales laterales.

Fuente: https://www.saddns.net/