Un equipo de investigadores de la Universidad de California en Riverside ha publicado una nueva variante del ataque SAD DNS (CVE-2021-20322) que funciona a pesar de las protecciones agregadas 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 se diferencia sólo en el uso de un tipo diferente de paquetes ICMP para verificar los puertos UDP activos. El ataque propuesto permite la sustitución de datos ficticios en la caché del servidor DNS, que pueden usarse para reemplazar la dirección IP de un dominio arbitrario en la caché y redirigir solicitudes al dominio al servidor del atacante.
El método propuesto funciona sólo en la pila de red de Linux debido a su conexión con las peculiaridades del mecanismo de procesamiento de paquetes ICMP en Linux, que actúa como una fuente de fuga de datos que simplifica la determinación del número de puerto UDP utilizado por el servidor para enviar un petición externa. Los cambios que bloquean la fuga de información se adoptaron en el kernel de Linux a finales de agosto (la solución se incluyó en el kernel 5.15 y en las actualizaciones de septiembre de las ramas LTS del kernel). La solución se reduce a cambiar al uso del algoritmo hash SipHash en las cachés de red en lugar de Jenkins Hash. El estado de la reparación de la vulnerabilidad en distribuciones se puede evaluar en estas páginas: Debian, RHEL, Fedora, SUSE, Ubuntu.
Según los investigadores que identificaron el problema, alrededor del 38% de los solucionadores abiertos de la red son vulnerables, incluidos servicios DNS populares como OpenDNS y Quad9 (9.9.9.9). En cuanto al software del servidor, se puede llevar a cabo un ataque utilizando paquetes como BIND, Unbound y dnsmasq en un servidor Linux. El problema no aparece en servidores DNS que se ejecutan en sistemas Windows y BSD. Para llevar a cabo un ataque con éxito, es necesario utilizar IP spoofing, es decir. se requiere que el ISP del atacante no bloquee los paquetes con una dirección IP de origen falsa.
Como recordatorio, el ataque SAD DNS evita las protecciones agregadas 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 pequeño tamaño del campo de ID de consulta DNS, que es de sólo 16 bits. Para seleccionar el identificador de transacción DNS correcto necesario para la suplantación de nombres de host, basta con enviar aproximadamente 7000 solicitudes y simular unas 140 respuestas ficticias. El ataque se reduce a enviar una gran cantidad de paquetes con un enlace de IP ficticio y con diferentes identificadores de transacciones DNS al solucionador de DNS. Para evitar el almacenamiento en caché de la primera respuesta, cada respuesta ficticia contiene un nombre de dominio ligeramente modificado (1.ejemplo.com, 2.ejemplo.com, 3.ejemplo.com, etc.).
Para protegerse contra este tipo de ataques, los fabricantes de servidores DNS implementaron una distribución aleatoria del número de puertos de red de origen desde donde se envían las solicitudes de resolución, lo que compensó el tamaño insuficientemente grande del identificador. Después de implementar la protección para enviar una respuesta ficticia, además de seleccionar un identificador de 16 bits, fue necesario seleccionar uno entre 64 mil puertos, lo que aumentó el número de opciones de selección a 2^32.
El método SAD DNS le permite simplificar radicalmente la determinación del número de puerto de red y reducir el ataque al método clásico Kaminsky. Un atacante puede detectar 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. El método nos permite reducir el número de opciones de búsqueda en 4 órdenes de magnitud: 2^16+2^16 en lugar de 2^32 (131_072 en lugar de 4_294_967_296). La filtración de información que permite determinar rápidamente los puertos UDP activos se debe a una falla en el código para procesar paquetes ICMP con solicitudes de fragmentación (indicador ICMP Fragmentation Needed) o redirección (indicador ICMP Redirect). El envío de dichos paquetes cambia el estado del caché en la pila de la red, lo que permite determinar, en función de la respuesta del servidor, qué puerto UDP está activo y cuál no.
Escenario de ataque: cuando un solucionador de DNS intenta resolver un nombre de dominio, envía una consulta UDP al servidor DNS que atiende el dominio. Mientras el solucionador espera una respuesta, un atacante puede determinar rápidamente el número de puerto de origen que se utilizó para enviar la solicitud y enviarle una respuesta falsa, haciéndose pasar por el servidor DNS que sirve el dominio mediante la suplantación de direcciones IP. El solucionador de DNS almacenará en caché los datos enviados en la respuesta falsa y durante algún tiempo devolverá la dirección IP sustituida por el atacante para todas las demás solicitudes de DNS para el nombre de dominio.
Fuente: opennet.ru