DNS poisoning gracias a los sistemas de protección anti-DDoSElevenPaths 17 octubre, 2013 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 How to take advantage of Chrome autofill feature to get sensitive informationHow to use Metashield protector for Client and why using it
