El miércoles, investigadores de la Universidad de Tsinghua y la Universidad de California en Riverside presentaron una técnica que, una vez más, hace factible el envenenamiento de caché. Su método aprovecha un canal lateral que identifica el número de puerto utilizado en una solicitud de búsqueda. Una vez que los atacantes conocen el número, una vez más tienen una alta probabilidad de adivinar con éxito el ID de la transacción. El canal lateral en este caso es el límite de velocidad para ICMP
DNS cache poisoning
¿Creías que después del fallo de Kamisnky en 2008 se solucionó todo? DNS sigue siendo uno de los protocolos más débiles sobre el que se sustenta (demasiado) internet. Varias universidades han podido envenenar las cachés DNS como ya se hizo entonces. Se llama SAD DNS. Es complejo de explicar, pero vamos por partes.
Para poder falsear una petición DNS y devolverle al cliente una mentira, el atacante debe saber el TxID (transaction ID) y el puerto origen UDP. Esto suponía una entropía de 32 bits (adivinar dos campos de 16 bits). SAD DNS consiste (básicamente, porque el paper es muy complejo) en inferir el puerto UDP a través de un ingenioso método que se vale de los mensajes de vuelta de error ICMP. Esto deja de nuevo una entropía de 16 bits, asumible para un ataque.
¿Cómo deducir el puerto abierto del resolvedor (la víctima a la que se le va a envenenar la caché)? Lo más sencillo es escanear todos los puertos UDP y ver cuál está abierto, pero esto lleva demasiado tiempo. Pero cuando hayas terminado, ya se ha realizado la transacción y el puerto que querías estará obsoleto. Además, si se machaca un servidor consultando puertos UDP él mismo limitará las respuestas ICMP de “error puerto cerrado” para no saturar. Todos los OS implementan este límite global. Y este límite para proteger, paradójicamente, es lo que aprovecha el ataque. El límite global es de 1000 respuestas por segundo en Linux (200 en Windows). Se trata de un contador global compartido por cualquiera que le esté preguntado. Por tanto el atacante debe:
- * Enviar 1000 sondas UDP al resolvedor víctima con IPs de origen falseadas probando 1000 puertos (en realidad son lotes de 50 cada 20 ms para superar otro límite de respuestas por IP).
- * Si los 1000 puertos están cerrados, la víctima devolverá (a las IPs falseadas) 1000 paquetes ICMP de error indicando que no está abierto el puerto. Si está abierto, no pasa nada, lo descarta la aplicación correspondiente en ese puerto.
- * No importa que el atacante no vea los ICMP respuesta (llegan a las IPs falseada). Lo que importa es ver cuánto del límite global de 1000 respuestas por segundo “se gasta” en esa tanda.
- * Antes de dejar pasar ese segundo, el atacante consulta un puerto cualquiera cerrado y si el servidor le devuelve un ICMP de “puerto cerrado”… es que no se había gastado los 1000 ICPM de “error puerto cerrado” y por tanto… en ese rango de 1000 había al menos un puerto abierto. Bingo. Como el límite es global, una respuesta de puerto cerrado significa que no se gastó el límite de 1000 repuestas de “puerto cerrado” por segundo.
- * De esta forma, en tandas de 1000 consultas por segundo y comprobando si gasta o no el límite de paquetes de error “puerto cerrado”, el atacante puede ir deduciendo qué puertos están abiertos. En algo más de 65 segundos (para cubrir 65.536) tendrá mapeados los puertos abiertos del servidor. Ahora adivina el TrID por fuerza bruta, y lanza varios paquetes que confundan al resolvedor.
Hay más variantes del ataque dependiendo de cómo implemente UDP la víctima, de si es un simple forwarder o un resolvedor.
SAD DNS (Side channel AttackeD DNS)
DNS Cache Poisoning Attack Reloaded:
Más información: https://dl.acm.org/doi/pdf/10.1145/3372297.3417280
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.
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.
Fuentes:
https://t.me/cybersecuritypulse/253
No hay comentarios:
Publicar un comentario