DNS poisoning gracias a los sistemas de protección anti-DDoS

Un método habitual para mitigar los ataques de denegación de servicio distribuido basados en la amplificación DNS, se sustenta en ignorar ciertos mensajes cuando se sospecha que son consultas destinadas a generar un
ataque. Pero esta técnica destinada a mitigar los ataques DDoS,
pone en riesgo a los servidores que los utilizan, porque facilita a un
atacante envenenar la caché de los servidores DNS que la usan. Vamos a explicarlo en
detalle.

El protocolo DNS en general siempre ha sido el punto débil
en la red. Ataques de spoofing con diferentes técnicas, cachés envenenadas, la vulnerabilidad de Kaminsky (que es un problema de diseño intrínseco al
protocolo), los fallos propios y vulnerabilidades de implementación de BIND… Su importancia, sencillas características y falta de seguridad se prestan a todo tipo de
abusos. Últimamente el protocolo DNS está siendo usado para realizar ataques DDoS
aprovechando la amplificación de tráfico. Pero en ciertos casos, parece que el remedio aplicado es peor que la enfermedad, porque facilita el envenenamiento
de caché. Así lo han demostrado Florian Maury y Mathieu Feuillet en su
investigación “Blocking DNS Messages is Dangerous”.

Amplificación DNS

Hasta hace relativamente poco, para “tumbar”
páginas web importantes bastaba con tener una botnet lo suficientemente grande
como para generar el tráfico necesario. Pero la “globalización” de
servicios y mejora de los sistemas DDoS en general, hacen que cada vez sea más
complejo para un atacante disponer de los bots mínimos para causar daño. Así que
necesitan “amplificar” ese tráfico que generan para poder atacar.
Esto lo conseguían en los 90 con ataques tipo “smurf”, pero
actualmente (el ICMP era fácil de capar) se usa sobre todo el DNS. Tanto ICMP
como UDP permiten falsificar al emisor y sobre todo, generar respuestas
“muy grandes” a consultas muy pequeñas.

Así, lo que los atacantes hacen es:

Envían una petición pequeña (pocos bytes) desde muchas
máquinas, falsificando la dirección de origen y haciendo pensar que las realiza la víctima. Hago así como

dig ANY microsoft.com @195.5.64.2
Las envían a servidores DNS abiertos, que resuelven
cualquier petición. Estos servidores DNS reciben las miles de pequeñas
preguntas y devuelven las miles de respuestas gigantescas (hasta 50 veces más bytes que
la pregunta) a la víctima, que recibe un tráfico muy grande que no ha
solicitado. Algo así como esta respuesta por cada pregunta:

; <<>> DiG 9.7.0-P1 <<>> @195.5.64.2 microsoft.com ANY +norecurse

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2663

;; flags: qr ra; QUERY: 1, ANSWER: 11, AUTHORITY: 5, ADDITIONAL: 7

;; QUESTION SECTION:

;microsoft.com. IN ANY

;; ANSWER SECTION:

microsoft.com. 3591 IN TXT “FbUF6DbkE+Aw1/wi9xgDi8KVrIIZus5v8L6tbIQZkGrQ/rVQKJi8CjQbBtWtE64ey4NJJwj5J65PIggVYNabdQ==”

microsoft.com. 3591 IN TXT “v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30 ip4:205.248.106.32 ~all”

microsoft.com. 3591 IN SOA ns1.msft.net. msnhst.microsoft.com. 2013101607 300 600 2419200 3600

microsoft.com. 2244 IN A 64.4.11.37

microsoft.com. 2244 IN A 65.55.58.201

microsoft.com. 3591 IN MX 10 microsoft-com.mail.protection.outlook.com.

microsoft.com. 172791 IN NS ns3.msft.net.

microsoft.com. 172791 IN NS ns4.msft.net.

microsoft.com. 172791 IN NS ns1.msft.net.

microsoft.com. 172791 IN NS ns5.msft.net.

microsoft.com. 172791 IN NS ns2.msft.net.

;; AUTHORITY SECTION:

microsoft.com. 172791 IN NS ns5.msft.net.

microsoft.com. 172791 IN NS ns1.msft.net.

microsoft.com. 172791 IN NS ns4.msft.net.

microsoft.com. 172791 IN NS ns2.msft.net.

microsoft.com. 172791 IN NS ns3.msft.net.

;; ADDITIONAL SECTION:

ns1.msft.net. 993 IN A 65.55.37.62

ns2.msft.net. 2540 IN A 64.4.59.173

ns3.msft.net. 993 IN A 213.199.180.53

ns4.msft.net. 993 IN A 207.46.75.254

ns4.msft.net. 2629 IN AAAA 2404:f800:2003::1:1

ns5.msft.net. 3124 IN A 65.55.226.140

ns5.msft.net. 943 IN AAAA 2a01:111:200f:1::1:1

;; Query time: 905 msec

;; SERVER: 195.5.64.2#53(195.5.64.2)

;; WHEN: Thu Oct 17 10:34:30 2013

;; MSG SIZE rcvd: 832

Se han encontrado incluso scripts PHP colgados en
páginas comprometidas que facilitan esta labor.

http://www.webroot.com/blog/2013/09/10/web-based-dns-amplification-ddos-attack-mode-supporting-php-script-spotted-wild/

Recursivo e iterativo

Además de la botnet y las peticiones falsificadas, los
atacantes necesitan “resolvedores” que se presten a este juego
amplificando el tráfico. Los servidores configurados como recursivos
públicamente (se estima que existen sobre el millón accesibles en la red) son los nuevos
servidores de correo que permitían el “open relay” de los 90, y contra ellos se está luchando.

Servidor DNS actuando en modo modo iterativo

Un servidor DNS opera en general en dos modos:

Modo iterativo: El usuario pregunta al servidor DNS por un
dominio. Si no lo tiene, lo deriva a otro DNS (un root, por ejemplo) que lo sepa y deja que pregunte
él mismo. En resumen, le envía un “referral” y que sea el cliente el
que trabaje, preguntando varias veces. Ambos comparten el “esfuerzo” de generar y
recibir tráfico.
Modo recursivo: El servidor DNS, si no sabe cómo resolver
un dominio, se ocupa de todo. Pregunta al servidor root, hasta llegar al
autoritativo del dominio, recopilar toda la información, y devolvérsela al
cliente. Así el tráfico está mal repartido. Al cliente le hacen todo el trabajo y, con pocos bytes, consigue que se devuelva una respuesta
enorme. Si además se falsifica la fuente… el DDoS está servido. Desde hace pocos
años BIND cambió su configuración por defecto para intentar mitigarlos.

Esquema de ataque con el servidor DNS actuando en modo recursivo

El modo recursivo tiene su utilidad en redes internas en los que los usuarios solo acceden a un DNS corporativo y no pueden consultar a otros… pero si se administra mal y no se limita para este servidor recursivo solo responda a las
IPs de su LAN… nos encontramos con que los atacantes disponen de servidores de los que abusar.

El ataque

Se basa en buena parte en el problema descubierto por
Kaminsky en 2008, que permitía engañar a la caché de un servidor DNS. Muy
simplificado, se enviaban muchas respuestas falsas a preguntas que nunca hizo
el servidor. Si alguna coincidía en el puerto de origen con una pregunta, el
servidor devolvía la respuesta falsa como verdadera a la víctima. El problema encontrado por Kaminsky se
resolvió introduciendo más entropía al cálculo del puerto fuente en la
respuesta. Desde entonces las probabilidades de que coincidan son tan bajas que
el ataque no resulta práctico.

Lo que pensaron estos investigadores es que, si el problema
es que existe mucha entropía, quizás con más tiempo para probar más posibilidades,
podrían volver a conseguir que el ataque de Kaminsky fuera viable. Y así fue. Si se
ayudan de los mecanismos anti-DDoS, es posible que el ataque de envenenamiento
de caché sea práctico de nuevo. Fundamentalmente, los métodos anti-DDoS abren
una ventana de tiempo que puede ser aprovechada por el atacante. Lo que ocurre
es que:

El atacante, desde cualquier punto, envía una petición de
resolución al servidor DNS del que se va ayudar, y que dispone de un sistema
anti-DDoS.
Este servidor DNS realiza la recursión, preguntando al
servidor autoritativo del dominio que corresponda, porque él no sabe la
respuesta.
La botnet del atacante avisa deliberamente al servidor
autoritativo, diciéndole que ese servidor DNS está siendo usado para
amplificar, y que active sus mecanismos de protección que fundamentalmente
consisten en que ignore a ese servidor DNS que le pregunta: que no le responda
o que lo haga más tarde.
Mientras el servidor espera, el atacante le envía ataques
Kaminsky al servidor (respuestas falsas que cacheará), porque tiene tiempo de
sobra para hacerlo. El servidor cree que vienen del servidor autoritativo y las
cacheará. El ataque de envenenamiento puede ser otro, pero ellos han usado
Kaminsky, por resultar un problema de diseño intrínseco al protocolo DNS.

En resumen, aprovechar ese tiempo de “baneo” para
enviar masivamente respuestas y aumentar las probabilidades de éxito en el envenenamiento de caché.

En realidad, es vulnerable cualquier dispositivo que,
queriendo usar DNS “Response Rate Limiting” para precisamente evitar
ataques, llegue a desestimar peticiones DNS por considerarlas peligrosas.
Incluso ciertos cortafuegos.

La solución a todo problema de DNS es DNSSEC, pero
como no es probable que se instaure a corto plazo… la contramedida ofrecida
es responder a todos los paquetes, incluso si es con un “REFUSED”,
pero nunca dejar esperando al servidor simplemente ignorando sus consultas.

Sergio de los Santos

ssantos@11paths.com

@ssantosv

Cómo aprovechar el autofill de Chrome para obtener información sensibleCómo usar Metashield protector for Client y por qué utilizarlo