SAD DNS: nueva técnica de envenenamiento de caché de DNS

Esta semana, en la ACM CCS 2020 conference, los investigadores de UC Riverside y la Universidad de Tsinghua anunciaron un nuevo ataque contra el Sistema de nombres de dominio (DNS) llamado SAD DNS (Side channel AttackeD DNS). Este ataque aprovecha las características recientes de la pila de redes en los sistemas operativos modernos (como Linux) para permitir que los atacantes revivan una categoría de ataque clásica: envenenamiento de la caché de DNS.

Los investigadores publicaron a fines de octubre de este año un paper en el que demuestran la existencia de una vulnerabilidad presente en el ecosistema DNS que permite realizar ataques de envenenamiento de la caché DNS, un problema que había sido descubierto en 2008 por el investigador Dan Kaminsky y que en principio se creía solucionado. Este hallazgo volvió a demostrar que mediante esta nueva técnica, es posible provocar el envenenamiento de la caché DNS y lograr que tras una consulta para un nombre de dominio en particular el servidor devuelva una IP potencialmente maliciosa que redireccione a la víctima a un sitio controlado por el atacante y no al sitio que corresponde al nombre de dominio legítimo.

Cómo funciona el ecosistema DNS

Antes de entrar en el análisis de SAD DNS, para comprender esta vulnerabilidad es necesario explicar más en detalle cómo funciona la infraestructura global que permite realizar estas traducciones. Para ello veamos la Figura 1. Aquí se muestra el flujo de mensajes completo que se debe realizar, en casos normales, entre distintos servidores públicos para encontrar el registro que contiene la traducción —o resolución— que buscamos.

Figura 1 – Fuente: Cloudflare

Como se observa en la imagen anterior, un cliente realiza una petición a un servidor denominado Resolver, también conocido como resolutor recursivo, que para la mayoría de los usuarios será el que les haya asignado su proveedor de servicios de Internet (ISP), o bien, algún servicio público como 8.8.8.8 de Google.

Cuando el Resolver recibe una consulta por parte del cliente, primero se fija en su caché si ya contiene la resolución buscada, en caso de no contar con ese registro, inicia una serie de consultas a otros servidores, en el orden que se ve en la Figura 1.

Lo siguiente que debemos entender es que las consultas DNS típicamente se realizan utilizando el protocolo de capa de transporte UDP, que no mantiene un estado o sesión entre cliente y servidor y cuyo encabezado puede ser fácilmente modificado para aparentar que la consulta proviene de otro equipo. Si bien este protocolo incorpora algunas debilidades en cuanto a la seguridad, su uso es una elección de diseño, ya que estos servidores manejan un gran volumen de consultas y el UDP requiere una menor cantidad de procesamiento y mensajes que el protocolo TCP para intercambiar datos.

Lo que puede ocurrir es que un atacante modifique el encabezado UDP haciéndose pasar por un Servidor Autoritativo e introduzca una resolución falsa que finalmente el Resolver almacene en su caché, provocando su contaminación o "envenenándolo". A partir de este momento, cualquier cliente que solicite la resolución de un determinado nombre de dominio al Resolver envenenado, recibirá una IP potencialmente maliciosa que lo redireccione al sitio del atacante o a su casilla de email, dependiendo del tipo de registro DNS que se modifique.

Si tengo un resolvedor recursivo propio, ¿qué mitigaciones debería implementar?

Este nuevo fallo afecta a los sistemas operativos Linux (kernel 3.18-5.10), Windows Server 2019 (versión 1809) y posteriores, macOS 10.15 y posteriores, y FreeBSD 12.1.0 y posteriores. Se estima que el 34% de los resolvers abiertos en Internet son vulnerables, 85% de los cuales forman parte de servicios DNS tan populares como los de Google y Cloudflare.

Para mitigar este ataque se recomienda deshabilitar las respuestas ICMP salientes y configurar el tiempo de espera de las consultas de DNS de manera más agresiva. Por otro lado, el parche del kernel lo que hace es que no haya un valor fijo de 1000 respuestas por segundo, sino de un valor aleatorio de entre 500 y 2000.

Este ataque puede tener un impacto severo, por lo que se recomienda a aquellos administradores de red que operen servidores DNS de este tipo que adopten las siguientes recomendaciones lo antes posible:

Recomendaciones:

• Actualizar el kernel de Linux y Windows a su versión más reciente. Esta vulnerabilidad ya fue corregida mediante la randomización del RRL para agregar aún mayor entropía y efectivamente volver a este ataque impracticable.
• Bloquear los mensajes de error ICMP "port unreachable" en el firewall.
• Mantener el software DNS que se utilice al día.

Detección de un ataque:

• Detectar el timing de los ataques, por ejemplo, si se envían tandas de 50 paquetes cada 20ms, seguramente se trate de un ataque.
• Detectar ID DNS incorrectos en las respuestas que recibe el servidor, es poco habitual que el tráfico legítimo contenga ID incorrectos.