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.
 |
| Fuente: 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 hay 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 actundo 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
