Un grupo de investigadores de la Universidad de California en Riverside dieron a conocer hace algunos dias una nueva variante del ataque SAD DNS que funciona a pesar de la protección agregada el año pasado para bloquear la vulnerabilidad CVE-2020-25705.
El nuevo método es generalmente similar a la vulnerabilidad del año pasado y solo se diferencia por el uso de un tipo diferente de paquetes ICMP para verificar los puertos UDP activos. El ataque propuesto hace posible sustituir datos ficticios en la caché de un servidor DNS, que se puede utilizar para falsificar la dirección IP de un dominio arbitrario en la caché y redirigir las llamadas al dominio al servidor del atacante.
El método propuesto es operable solo en la pila de red de Linux debido a su conexión a las peculiaridades del mecanismo de procesamiento de paquetes ICMP en Linux, que actúa como una fuente de fugas de datos que simplifican la determinación del número de puerto UDP utilizado por el servidor para enviar una solicitud externa.
Según los investigadores que identificaron el problema, la vulnerabilidad afecta aproximadamente al 38% de los solucionadores abiertos en la red, incluidos los servicios DNS populares como OpenDNS y Quad9 (9.9.9.9). Para el software de servidor, el ataque se puede llevar a cabo utilizando paquetes como BIND, Unbound y dnsmasq en un servidor Linux. Los servidores DNS que se ejecutan en sistemas Windows y BSD no muestran el problema. Se debe utilizar la suplantación de IP para completar con éxito un ataque. es necesario para garantizar que el ISP del atacante no bloquee los paquetes con una dirección IP de origen falsificada.
Como recordatorio, el ataque SAD DNS permite omitir la protección agregada a los servidores DNS para bloquear el método clásico de envenenamiento de caché DNS propuesto poren 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 de solo 16 bits. Para encontrar el identificador de transacción de DNS correcto necesario para falsificar 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 sistema de resolución de DNS con diferentes identificadores de transacciones de DNS.
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 red de origen desde los que se envían las solicitudes de resolución, lo que compensó el tamaño del identificador insuficientemente grande. Después de la implementación de la protección para el envío de una respuesta ficticia, además de la selección de un identificador de 16 bits, se hizo necesario seleccionar uno de los 64 mil puertos, lo que aumentó el número de opciones para la selección a 2 ^ 32.
El método SAD DNS permite simplificar radicalmente la determinación del número de puerto de red y reducir el ataque al método clásico de Kaminsky. Un atacante puede determinar el acceso a puertos UDP activos y no utilizados aprovechando la información filtrada sobre la actividad de los puertos de red al procesar paquetes de respuesta ICMP.
La fuga de información que le permite identificar rápidamente los puertos UDP activos se debe a una falla en el código para manejar paquetes ICMP con solicitudes de fragmentación (indicador de fragmentación necesaria de ICMP) o redirección (indicador de redireccionamiento de ICMP). El envío de dichos paquetes cambia el estado de la caché en la pila de la red, lo que hace posible, en función de la respuesta del servidor, determinar qué puerto UDP está activo y cuál no.
Los cambios que bloquean la fuga de información se aceptaron en el kernel de Linux a finales de agosto (la corrección se incluyó en el kernel 5.15 y las actualizaciones de septiembre de las ramas LTS del kernel). La solución es cambiar al uso del algoritmo hash SipHash en cachés de red en lugar de Jenkins Hash.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.