Un grupo 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 la protección añadida el año pasado para bloquear la vulnerabilidad CVE-2020-25705. El nuevo método es en general análogo a la vulnerabilidad del año pasado y se diferencia solo por el uso de un tipo diferente de paquetes ICMP para verificar puertos UDP activos. El ataque propuesto permite la inyección de datos falsos en la caché del servidor DNS, lo que puede utilizarse para sustituir en caché la dirección IP de un dominio arbitrario y redirigir las solicitudes a ese dominio hacia un servidor del atacante.
El método propuesto solo es eficaz en la pila de red de Linux debido a la vinculación con la particularidad de funcionamiento del mecanismo de manejo de paquetes ICMP en Linux, que es la fuente de la filtración de datos que facilita la identificación del número de puerto UDP utilizado el servidor para enviar la solicitud externa. Los cambios que bloquean la filtración de información fueron incluidos en el núcleo de Linux a finales de agosto (la corrección se incluyó en el núcleo 5.15 y en las actualizaciones de septiembre de las ramas LTS del núcleo). La corrección consiste en cambiar a un algoritmo de hash en cachés de red, utilizando SipHash en lugar de Jenkins Hash. El estado de la corrección de la vulnerabilidad en las 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 resolutores abiertos en la red son vulnerables, incluidos servicios DNS populares como OpenDNS y Quad9 (9.9.9.9). En cuanto al software del servidor, el ataque puede llevarse a cabo utilizando en un servidor Linux paquetes como BIND, Unbound y dnsmasq. En los servidores DNS que se ejecutan en sistemas Windows y BSD, el problema no se manifiesta. Para llevar a cabo con éxito el ataque, es necesario utilizar el spoofing de IP, es decir, se requiere que el proveedor del atacante no bloquee los paquetes con una dirección IP de origen falsa.
Recordemos que el ataque SAD DNS permite eludir la protección añadida a los servidores DNS para bloquear el método clásico de envenenamiento de caché DNS, propuesto en 2008 por Dan Kaminsky. El método de Kaminsky manipula el pequeño tamaño del campo de identificación de la solicitud DNS, que es de solo 16 bits. Para encontrar el identificador correcto de la transacción DNS, necesario para suplantar un nombre de host, basta con enviar aproximadamente 7000 solicitudes y simular alrededor de 140,000 respuestas falsas. El ataque consiste en enviar al resolvedor DNS una gran cantidad de paquetes con enlaces falsos a IP y con diferentes identificadores de transacción DNS. Para evitar el almacenamiento en caché de la primera respuesta, en cada respuesta falsa se indica un nombre de dominio ligeramente modificado (1.example.com, 2.example.com, 3.example.com, etc.).
Para protegerse contra este tipo de ataque, los fabricantes de servidores DNS han implementado una distribución aleatoria de los números de puertos de red de origen desde los cuales se envían las solicitudes de resolución, lo que ha compensado el tamaño insuficientemente grande del identificador. Después de implementar esta protección, para enviar una respuesta falsa, además de encontrar un identificador de 16 bits, también es necesario encontrar uno de los 64,000 puertos, lo que aumentó el número de combinaciones posibles a 2^32.
El método SAD DNS permite simplificar drásticamente la determinación del número de puerto de red y reducir el ataque al método clásico de Kaminsky. El atacante puede identificar accesos a puertos UDP inactivos y activos, aprovechando la filtración de información sobre la actividad de los puertos de red durante el manejo de paquetes ICMP de respuesta. Este método permite reducir en 4 órdenes de magnitud las opciones de búsqueda: 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 identificar rápidamente los puertos UDP activos se debe a un error en el código de manejo de paquetes ICMP con solicitudes de fragmentación (bandera ICMP Fragmentation Needed) o redireccionamiento (bandera ICMP Redirect). El envío de tales paquetes altera el estado de la caché en la pila de red, lo que permite, a partir de la reacción del servidor, determinar cuál puerto UDP está activo y cuál no.
Escenario de ataque: Cuando un resolutor DNS intenta determinar un nombre de dominio, envía una consulta UDP al servidor DNS que sirve el dominio. En el momento en que el resolutor espera una respuesta, el atacante puede rápidamente identificar el número del puerto de origen utilizado para enviar la consulta y enviar una respuesta falsa a esa dirección, haciéndose pasar por el servidor DNS que sirve el dominio, utilizando suplantación. IPEl resolutor DNS almacenará en caché los datos transmitidos en la respuesta falsa y durante un tiempo regresará la dirección IP suplantada por el atacante para todas las demás consultas DNS del nombre de dominio.
Fuente: opennet.ru
