Una mención importante merece "any", que nos pedirá al servidor dns que nos de toda la información que sepa sobre el dominio a consultar. Dicho esto, pongamonos manos a la obra y veamos que podemos hacer. Como ya se ha dicho anteriormente, las consultas "any" nos revelarán toda la información que contenta el DNS sobre el dominio. Veamos una consulta sobre nestle.es
Por lo visto Nestlé.es utiliza 4 servidores DNS (ctrdns1.nestle.com, amsdns1.nestle.com, aoadns1.nestle.com, eurdns1.nestle.com). También hemos obtenido información sobre sus servidores de correo (orhi.sarenet.es, mail.nestle.es).
Si quisiereamos obtener información específica sobre los servidores de correo bastaría con poner este comando:
Muchas veces, un dominio no utiliza un solo DNS, sino que por cuestiones de estabilidad utilizan varios, estableciéndose uno de ellos como el primario y los otros como secundarios. Muchas veces un archivo de zona DNS incluye información sobre nombres que el servidor de nombres almacena sobre un dominio DNS específico, incluyendo información "confidencial" sobre redes privadas. Esto tene una explicación. Siempre que un servidor DNS secundario se inicia, solicita al servidor DNS primario una lista con los ordenadores de los que es responsable. Este proceso se llama Transferencia de Zona.
Para consultar qué servidores de dominio primarios y secundarios utiliza un servidor, haremos uso del siguiente comando:
Puede darse el caso de que un dominio no lleve a cabo transferencias de zona. En este caso hay que llevar a cabo un ataque grinding para enumerar registros y alias relacionados con el dominio y servidores del dominio. Para hacer esto disponemos de dos herramientas que las podéis descargar del menú de la derecha: Txdns (http://www.txdns.net) y Blindcrawl.pl (http://sec.angrypacket.com). Estas herramientas lo que harán será probar diferentes nombres de dominio hasta dar con el correcto. Podéis descargarlas del menú de la derecha. Las dos soportan el uso de un diccionario aunque lo bueno de Blindcrawl es que permite probar sin diccionario aunque las posibilidades que ofrece no son muy amplias pero si funcionales.
En la página de txdns tienes dos diccionarios para descargar. También podéis visualizarlos en esta misma web, accediendo desde el menú de la derecha. Veamos a continuación un ataque realizado a nestle.es para enumerar servidores con Blindcrawl:
Hemos conseguido 3 nombres de servidores con sus respectivas ip's. Si con cada uno de estos nombres aplicamos lo anteriormente explicado y a esto sumamos rastreos WHOIS, obtendremos mucha información sobre la red objetivo.
Una vez hemos obtenido una lista de ip's, podemos realizar un barrido inverso de DNS para obtener información de equipos filtrados o protegidos. Para ello podemos utilizar GHBA y Nmap. Instalar Nmap es muy fácil tanto en Windows como en Linux. Si no sabes como hacerlo encontrarás muchas guías en Google. Para los que no sepáis compilar un archivo en C: si estáis en Windows, descargaros un compilador, como por ejemplo dev-c++, si por el contrario estáis en Linux; descargaos gcc (en sistemas basados en debian lo podéis hacer mediante el comando "sudo apt-get install gcc") y para compilarlo utilizad este comando "gcc ghba.c -o ghba". Vamos a probar GHBA y luego Nmap y esta vez con en CNI :
Bueno, pues ahí tenemos los resultados! creo que con esto ya hay bastante información sobre enumeración de servidores por medio de DNS.
FUENTE:http://n3t-datagrams.net/guias/dns.html
DNS Cache Poisoning/Spoof
Fecha: 13/08/2008; Versión 1.0 (Manuel Gil)
¿Que hace importante las comunicaciones en Internet?. Ante esta pregunta se nos pueden ocurrir multitud de respuestas meramente técnicas, se nos pueden venir a la cabeza miles de elementos que facilitan la comunicación entre dispositivos en internet, o que incrementan la seguridad o incluso que nos permiten transmitir información entre usuarios.
Principalmente creo que la respuesta está en la sencillez. Sencillez basada principalmente en la idea de que para conectar con un sitio o para ejecutar un servicio concreto, solo tengo que conocer el nombre del nodo destino al que me tengo que conectar. A partir de aquí, podemos hablar de las diferentes nomenclaturas que permiten entender mejor la funcionalidad o servicio de cada nombre; por ejemplo, www.sun.com se refiere sin duda al nodo WEB de la compañía SUN donde podemos obtener información en formato básicamente conocido como HTML; el nombre mail.sun.com, hace referencia al servidor de correo de la compañía SUN encargado de recibir y enviar correo; y así podíamos continuar con una lista enorme de nombres utilizados de forma estándar para, en resumidas cuentas, “facilitarnos la vida en internet”.
Podemos decir por tanto que la sencillez de Internet se basa en los nombres, nombres gestionados por un elemento principal en el funcionamiento de la gran red, el servicio DNS (Domain Name Server).
Pero ¿Que hace tan Importante al DNS?, el DNS permite no tener que memorizar que 72.5.124.61 es el sitio WEB de SUN Microsystems para poder acceder a el, o que 129.145.155.6 es uno de sus servidores de correo, nos basta con recordar SUN.com y si queremos acceder a su WEB añadimos www y si queremos enviar/recibir ficheros añadimos ftp.
Realmente Internet funciona en base a números, no con nombres, pero a las mentes humanas se nos da mejor recordar nombres en lugar de números, por eso nace el servicio DNS que permite traducir nombres a direcciones y viceversa. Realmente, nadie se para a pensar que al escribir www.sun.com, se deben de realizar una serie de tareas previas a la presentación de la página WEB, como es encontrar la dirección IP que se encuentra asociada a dicho nombre.
La estructura del DNS es una estructura totalmente jerarquizada en forma de árbol inverso que parte de unos puntos principales llamados Root Servers que son el punto principal en la búsqueda de cualquier nombre.
Como vemos en este esquema, antes de comenzar a navegar por la WEB del sitio www.sun.com, debemos de obtener su dirección IP. Existen 5 pasos a seguir para una primera conexión, tal como podemos ver en el esquema.
-
El cliente realiza una petición al DNS server preguntándole la dirección IP de www.sun.com.
-
El servidor DNS en caso de no conocerla, debe de consultar en primer lugar al root server, conocido como “.” en la jerarquía, o raiz, ¿quien gestiona los dominios “.com”?, el root server le contesta con las IP's que gestionan el dominio “.com”.
-
Posteriormente, el DNS consulta con el gestor de dominios “.com”, para que le diga ¿quien gestiona el dominio “.sun.com”?, este le da la dirección IP del servidor DNS del dominio “.sun.com”.
-
Por último, se hace una pregunta al DNS del dominio “.sun.com” preguntando por la IP del nodo “www” dentro de su dominio, este le responde con la IP final del nodo “www.sun.com”.
-
Finalmente, el servidor DNS envía la respuesta al cliente que finalmente puede acceder a la página WEB del sitio “www.sun.com”.
Como se puede comprobar, se requiere mucha información previa para poder llegar a un sitio cualquiera de internet, dicha información es fácil de obtener, pero costosa si por cada conexión debemos de realizar los mismos pasos, por lo tanto nace un segundo concepto en el servicio de DNS conocido como cache, la cual almacena los resultados para posteriores búsquedas durante un tiempo limitado y establecido por el propietario de la zona. De esta forma, obtenemos un modelo distribuido y totalmente dinámico de conversión de nombres a direcciones IP y viceversa. Esto hace que posteriores consultas no tengan que realizar toda esta labor.
Las dudas que se nos plantean ante el modelo del servicio DNS pueden ser varias ¿que problemas podrían surgir de este modelo de distribución de nombres?, ¿cuales son las dependencias y los costes de este modelo?, ¿son seguras las respuestas obtenidas?.
Aspectos Generales del DNS
La forma de trabajar habitual de un sistema DNS es en modo recursivo, es decir, todas las peticiones realizadas por cualquier cliente son enviadas a un servidor de jerarquía mayor en caso de que:
-
La petición no se encuentre entre las bases de datos de dominio de la que el servidor es autoritario.
-
La respuesta no se encuentre en la caché.
Todas las peticiones son realizadas sobre el resolver. El resolver puede conocer el dominio por que es autoritario para la zona o debe de dirigir la búsqueda hacia Internet comenzando por la parte más alta del árbol, tal como hemos visto en la figura anterior.
Como se puede observar, por cada dominio del tipo www.dominio.organismo, en el mejor de los casos, se estarán abriendo tres conexiones diferentes consecutivas no en paralelo. Por lo tanto, en casos de máxima utilización del servicio DNS, las peticiones estarán siendo dirigidas de tres en tres como poco. Esta situación podría ser peor si nos encontramos con sistemas con subdominios como www.subdominio1.subdominio2.dominio.com.
Es en este punto donde entran en juego las caches de DNS que almacenan en memoria los datos obtenidos en búsquedas anteriores. En este caso, rebotar el servicio o re-iniciar los sistemas provocan la pérdida de la caché, por lo que la eficacia se observa con el paso del tiempo. Una vez que las referencias se encuentran en la caché, permanecerán en ella el tiempo determinado por el campo TTL de la configuración del servicio. Podemos ver en el esquema siguiente tres casos de caché de nombres de dominio DNS.
Obviamente cuantos más datos tengamos en la caché y cuanto mayores sean los tiempos TTL definidos por cada entrada en la caché, menos recursos se consumen. Esto puede llevar al error de algunos administradores, de falsear datos de la caché saltándose las normas establecidas en el RFC1035 y otorgando manualmente mayores tiempos de vida de los datos (campos TTL) en la caché.
Esta práctica, puede provocar la denegación de servicio de la entrada falseada. Un servicio puede haber cambiado de direccionamiento IP sin cambiar el nombre, y si no se han respetado las entradas TTL definidas por el propietario del dominio, podríamos tener un tiempo de validez de una entrada durante un tiempo mayor que el indicado y por tanto podríamos no enterarnos de dicho cambio de IP y denegar el acceso a dicho servicio a nuestros propios usuarios.
Las peticiones inversas son las que presentan mayor complejidad, son más costosas de realizar y cada vez son más utilizadas para la generación de informes, reglas de filtrado (control URL) y análisis de logs de firewalls, servidores, servicios, etc. Es lo que conocemos como el dominio in.addr.arpa.
Dicho dominio tiene 256 sub-dominios y cada uno corresponderá a el valor dentro del primer octeto de la dirección IP y cada uno de estos dominios tendrá otros 256 sub-dominios bajo el correspondientes al valor del segundo octeto de la dirección IP.
Al final, en el cuarto octeto, el último nivel posible, existen RR's asociados a el con el nombre completo del nodo o red en esa dirección IP en concreto.
Como podemos ver, cualquier ataque sobre los DNS's para realizar peticiones inversas de forma exhaustiva conlleva un gran esfuerzo por parte de los servidores y la perdida de muchos recursos del sistema.
Seguridad del DNS Una de las recomendaciones en cuanto al establecimiento de un servicio DNS es la de evitar en la medida de lo posible acciones recursivas. Es decir, permitir que usuarios finales puedan realizar búsquedas de dominio sobre el DNS puede resultar nefasto para el mismo. Muchas de las técnicas de ataques de denegación de servicio sobre servicios DNS, se basan precisamente en el envío masivo de peticiones DNS sobre zonas de dominio directo o inverso.
También se pueden utilizar las búsquedas recursivas para realizar spoof de DNS y envenenamiento de la caché sobre los servidores DNS. Esto puede causar que mucha información sensible de usuarios pueda ser enviada a servidores falsos o navegación sobre WEB's suplantadas.
Para el funcionamiento de Internet, es necesario la total funcionalidad de los Root Servers, cualquier petición, cualquier servicio y cualquier comunicación entre diferentes sistemas en la red, se realiza en base a resoluciones DNS. Es por tanto vital el funcionamiento del servicio, sin Root Servers, no existirían comunicaciones entre usuarios/sistemas.
Paul Mockapetris, inventor del sistema de gestión de nombres, avisa del peligro que pueden correr las comunicaciones a nivel mundial en caso de que los Root Servers sufran algún tipo de problema (ataques), http://www.zdnetindia.com/print.html?iElementId=73777.
Podemos ver unos ejemplos en dos casos sucedidos recientemente sobre los servidores root de DNS.
-
El 11 de Septiembre de 2001 (atentado Torres Gemelas), se produjo una caída del rendimiento en Internet en gran parte del mundo principalmente debido a los problemas existentes en las comunicaciones dentro de Estados Unidos.
-
Hay que tener en cuenta que 10 de los 13 Root Servers se encuentran en Estados Unidos y por tanto, un problema en las comunicaciones trans-oceánicas obliga a que todas las resoluciones se tengan que hacer sobre los 3 Root Servers restantes (Japón, Suecia y Reino Unido). Estos últimos se vieron al límite del colapso tras los atentados ante el aumento del número de resoluciones solicitadas
-
En Octubre del 2002, Se realizó un ataque de denegación de servicio distribuido (DdoS) sobre los 13 Root Servers existentes en Internet. Según se puede ver en la noticia referida, el ataque no causo más daño por que no duró el tiempo suficiente, pero durante el tiempo que duró se comprobó precisamente la vulnerabilidad de los sistemas. Para más información, consultar las siguientes URLs:
-
Enero 2003, justo cuatro meses después del ataque anterior, se produce una nueva caída de los servidores Root Servers provocada esta vez por un virus (Slammer), que afectó visiblemente a los Root Servers. El ataque no tenía nada que ver con el DNS, pero la rapidez con la que se extendió el virus, así como la forma de afectar a otros sistemas hicieron que los servidores Root Servers se vieran afectados.
-
El 15 de Junio 2004, un ataque de denegación de servicios sobre los servidores DNS de Akamai consiguieron parar grandes sitios WEB de Internet como Microsoft, Google y Yahoo. El ataque dejó fuera de servicio durante dos horas los servidores DNS de Akamai que son los que dan servicio de contenidos a dichas WEB's haciendo una especie de proxy reverse, de modo que las direcciones IP de los sitios www.microsoft.com, www.google.com y www.yahoo.com, pertenecen a servidores Proxy de Akamai. Más información al respecto puede encontrarse en:
DNS Cache Poisoning/Spoofing El concepto de envenenamiento de la cache DNS es muy simple. El servidor DNS del usuario, envía una petición a un DNS autoritativo preguntando por la IP que coincida con el nombre solicitado. Pero ¿qué sucede si un atacante contesta suplantando al DNS autoritativo y devuelve una IP falsa?.
Si esto sucede, el DNS del usuario devolverá al mismo una dirección IP falsa asociada al nombre que el usuario solicita, dirigiendo su petición a un servidor que no es el que el usuario quiere acceder, es más, la entrada falsa obtenida permanecerá en la cache del servidor DNS durante un tiempo determinado en el campo TTL enviado por el atacante, para ofrecer la misma respuesta a todos aquellos usuarios que quieran acceder al mismo nombre.
Esto es lo que se conoce como envenenamiento de la cache de los servidores DNS. Este ataque ha podido ser realizado tiempo atrás, debido a que el servicio DNS era implementado mediante UDP (User Datagram Protocol), el cual es un protocolo ligero pero con muy pocos mecanismos de autenticación de los paquetes recibidos, de modo que era bastante simple realizar respuestas falsas y enviárselas al servidor DNS.
En este ejemplo, el atacante pretende envenenar la cache de los servidores DNS de modo que cuando un usuario se conecte al dominio www.banco-victima.com, acceda realmente a la dirección IP del servidor atacante.
-
El atacante envía un correo SPAM a diversos usuarios con un enlace a un sitio que pueda parecer interesante (www.regalomoto.com). Cuando alguno de los usuarios victima, lea el correo e intente acceder al sitio WEB pinchando en en el enlace del correo, lo primero que hará será resolver el nombre en IP para poder acceder al sitio.
-
Para eso, envía una petición a su DNS preguntando por la IP del sitio www.regalomoto.com.
-
El servidor DNS, tras pasar por los servidores autoritativos superiores en la jerarquía, llega finalmente al servidor autoritativo para el dominio regalomoto.com que pertenece al atacante, y pregunta por la IP del nodo www.regalomoto.com.
-
El servidor DNS atacante, responde con respuestas de re-dirección DNS mediante entradas CNAME (alias), obligando al servidor DNS a realizar nuevas preguntas al DNS de atacante, obligando finalmente al servidor DNS del usuario victima resolver la dirección del dominio www.banco-victima.com
-
El servidor DNS de la victima, se conecta al servidor DNS autoritativo del dominio banco-victima.com, preguntando por la dirección IP del nodo www.banco-victima.com.
-
Simultáneamente a la respuesta del servidor autoritativo DNS del dominio banco-victima.com, el atacante envía respuestas spoofeadas al servidor DNS del usuario victima al mismo tiempo y muchas veces para asegurarse de que el DNS victima guarde en la cache su respuesta en lugar de la del DNS autoritativo.
A partir de este momento, el servidor DNS tiene una entrada envenenada que hará que todos los usuarios de ese DNS que quieran acceder al site www.banco-victima.com, sean re-dirigidos al servidor del atacante, el cual podrá suplantar al nodo banco-victima real para obtener usuarios y claves de acceso.
Para evitar este problema, se definió dentro del protocolo DNS un campo de 16 bits llamado Transaction ID, de modo que cuando el DNS del usuario envía una consulta al servidor DNS autoritativo del dominio solicitado, éste recoge el Transaction ID y lo devuelve dentro de la respuesta. El Transaction ID debe de ser el mismo en la consulta y en la respuesta, de otra forma, es ignorado.
Debido a que existen 65536 opciones posibles para establecer el Transaction ID, las posibilidades de obtener este número mediante mecanismos de fuerza bruta es complicado, a menos que el Transaction ID no sea seleccionado realmente de forma aleatoria y pueda ser obtenido fácilmente.
El Transaction ID es un número de 16 bits, con lo que teóricamente se requiere una media de 32768 intentos para obtenerlo por fuerza bruta. Como evidencia anecdótica, se intuye que existen implementaciones que solo utilizan 14 bits, con lo que el número de intentos se reduce a 8192.
IP Spoofing Sobre la posibilidad de poder realizar un spoof de la dirección IP del servidor DNS autoritativo, este es un grave problema que no resuelven muchos ISP's que dan acceso a la red. El MIT mantiene una página WEB (http://spoofer.csail.mit.edu/summary.php) con la estadística de pruebas de suplantación IP generada por 13109 sensores dispersos en Internet. El resultado es que, casi el 20% de las direcciones IP de Internet pueden ser suplantadas.
DNS Cache Poisoning/Spoofing (Actual Se ha descubierto que tanto BIND 8 y 9, así como otras versiones de DNS (Microsoft, Cisco, ...), usan un Transaction ID muy predecible para las preguntas DNS. Esto significa que un atacante puede fácilmente envenenar la cache de estos servidores DNS.
El atacante necesita un servidor WEB así como un servidor DNS, que pueden alojarse en el mismo sistema. Utilizando el mismo dominio de antes, regalomoto.com, el atacante configura su propio DNS autoritativo y el proceso es muy similar al método anterior.
-
Se envía un mensaje SPAM a una o varias victimas, incluyendo un enlace al sitio www.regalomoto.com.
-
Cuando se pincha el enlace, el usuario realiza una consulta a su propio DNS para poder acceder al sitio www.regalomoto.com.
-
El servidor DNS victima envía una petición de consulta al servidor DNS autoritativo del atacante, el cual guarda el campo Transaction ID y responde al servidor DNS victima con una respuesta que puede ser un campo CNAME apuntando a www2.regalomoto.com, el cual obliga al DNS victima a solicitar de nuevo una consulta al DNS autoritativo del atacante. De nuevo, el DNS atacante, guarda el campo Transaction ID y vuelve a enviar como respuesta otro CNAME apuntando de nuevo al mismo sitio. Esta situación puede repetirse típicamente entre 8 y 16 veces hasta que el sistema atacante ha recolectado los suficientes Transaction ID como para poder predecir el siguiente Transaction ID.
-
Es en este punto, cuando el atacante responde con un CNAME final apuntando al dominio victima www.banco-victima.com, obligando al DNS victima a realizar una petición al DNS autoritativo del dominio banco-victima.com.
-
Se realiza la consulta del sitio www.banco-victima.com al DNS autoritativo del dominio banco-victima.com desde el DNS victima.
-
Como el atacante ha averiguado cual va a ser el nuevo Transaction ID, simultáneamente a la respuesta original del servidor DNS autoritativo de banco-victima.com, el atacante comienza a enviar paquetes spoofed al mismo tiempo que el servidor DNS autoritativo de banco-victima.com, inundando de respuestas al DNS victima, y dado que el campo Transaction ID es el correcto, almacena la entrada falsa en su cache.
A partir de este momento, la cache ya está envenenada y cualquier otro usuario que quiera acceder al sitio www.banco-victima.com será re-dirigido al sitio WEB del atacante. Hay que hacer notar, que aunque suceden muchas cosas detrás de la escena, la única acción realizada por el usuario ha sido pulsar un único enlace.
Aunque la situación se represente de forma simple, la probabilidad de que los paquetes de respuesta falsos sean aceptados por el servidor final, depende de muchos factores como explicaremos más adelante en el documento.
Fraude en Servicios Financieros El método de envenenamiento de datos en las caches DNS, es una forma muy efectiva de realizar ataques tipo “pharming”. Un ataque “pharming” es una potente variedad del típico “phising scam”, en el cual la victima (consumidor), visita el sitio WEB del banco, y es alimentado con contenido malicioso en lugar de la página original del banco. Esto sucede debido a que el atacante sustituye la entrada de la dirección IP DNS original del banco por una dirección IP falsa que apunta al sitio WEB del atacante.
Una vez que una cache ha sido envenenada por un atacante, todos los usuarios de dicho servicio cache DNS, se verán afectados, creando de esta forma un gran agujero de seguridad. Al contrario que PC's infectados, troyanos y ataques similares, el envenenamiento de la cache se realiza de forma muy transparente y no es detectado por productos antivirus/spyware/malware.
Phising a escala masiva es uno de los posibles objetivos de un envenenamiento de entradas DNS en la cache, pero otro tipo de problemas pueden surgir de este tipo de ataques, infecciones masivas, ataques “man-in-the-middle”, así como sustitución de entidades y decepción por parte de usuarios y clientes.
El impacto producido en las instituciones financieras es claramente visible. Por un lado, existe una amenaza seria a la integridad de los servicios ofrecidos por la entidad y cuentas privadas de los usuarios, y por otro, no hay forma de poder controlar el origen de la amenaza. La entidad financiera no puede hacer nada para evitar que alguna cache de Internet sea infectada, incluso, el propio cliente que mantiene cuentas en dicha entidad financiera, tampoco puede controlar la integridad de su servicio cache DNS, ya que normalmente es un servicio ofrecido por terceros (ISP's).
Soluciones / Recomendaciones Existen algunas recomendaciones/soluciones para mitigar el problema, en la página de Dan Kaminsky, el descubridor de esta nueva vulnerabilidad (http://www.doxpara.com/), podemos encontrar un script que permite saber si el DNS Cache que estamos utilizando es vulnerable o no a un posible envenenamiento de sus entradas.
La única solución válida es DNSSec, los parches añadidos, como muchos parches de seguridad, no corrigen el problema, sino que simplemente son medidas disuasorias. En este caso, se añade una capa de aletoriedad a cada consulta, que es introducida en el número de puerto usado en cada consulta, es por tanto, un arreglo temporal hasta el uso de alguna otra técnica que solucione realmente el envenenamiento de la cache.
Las versiones de SUN Solaris que están afectadas por esta vulnerabilidad, son:
- SPARC Platform
- Solaris 8
- Solaris 9
- Solaris 10 without patch 119783-06
- OpenSolaris based upon builds snv_01 through snv_95
-
x86 Platform
- Solaris 8
- Solaris 9
- Solaris 10 without patch 119784-06
- OpenSolaris based upon builds snv_01 through snv_95
Parches Antes de la aparición de la vulnerabilidad, Solaris 8, 9 y 10 con los últimos parches ofrecían las siguientes versiones de BIND.
- Solaris 8 BIND 8.2.4
- Solaris 9 BIND 8.3.3
- Solaris 10 BIND 9.3.4-P1
Por lo tanto eran vulnerables, consultar en http://sunsolve.sun.com/search/document.do?assetkey=1-66-240048-1 para obtener los parches adecuados. Las versiones de BIND DNS seguras bajo SUN Solaris son:
- BIND 9.3.5-P1
- BIND 9.4.2-P1
Aunque SUN oficialmente, solamente soporta la versión BIND 9.3.5-P1. Recomendaciones Existen algunas maneras de mitigar la exposición a ataques de envenenamiento de la cache siguiendo ciertas recomendaciones, de las cuales, excepto el uso de firmas en las zonas mediante certificados (DNSSec), el resto no aseguran que la vulnerabilidad pueda ser erradicada.
Filtrar el Tráfico en el Perímetro de la Red Debido a la posibilidad de suplantar direcciones IP, tal como hemos visto anteriormente, es necesario implementar los filtros anti-spoof en el perímetro de la red para evitar suplantación de identidad IP, comprobar las medidas a realizar en los documentos RFC2827, RFC3704 y RFC3013, los cuales describen las mejores prácticas para implementar este tipo de defensa.
Consultar también la documentación incluida en las conferencias realizadas por USENIX (Steps for Reduction Unwanted Traffic).
http://www.usenix.org/publications/library/proceedings/sruti05/tech/Restricción de Acceso Los administradores que no puedan o no estén en condiciones de aplicar parches, pueden limitar los riesgos de exposición a ataques de envenenamiento de cache, restringiendo el acceso de los sistemas que pueden solicitar el uso de recursión en sus consultas.
El siguiente documento contiene información para evitar o restringir la recursión en ISC BIND.
http://www.cert.org/archive/pdf/dns.pdf Evitar DNS Spoofing Al realizar cierto tipo de acciones maliciosas, un servidor DNS cache puede ser “spoofed”, una vez “spoofed” con una entrada no valida, el servidor cache repetirá esa respuesta falsa a todos los clientes que se lo pregunten.
Es importante conocer que hace a un resolver (DNS cache) aceptar una respuesta. Por lo tanto la información enviada a un resolver es aceptada solo y solo si, se cumplen estas cuatro condiciones:
- La sección de la pregunta del paquete de respuesta es equivalente a aquella que está esperando una respuesta.
- El Transaction ID del paquete de respuesta, coincide con el enviado.
- La respuesta viene de la misma dirección de red a la que se envió.
- La respuesta entra por la misma dirección de red desde la que se envió la pregunta, incluyendo el mismo número de puerto.
La primera respuesta que coincida con estas cuatro condiciones será aceptada. Si un elemento tercero que no tiene nada que ver entre la pregunta y la respuesta envía la información con estas cuatro condiciones podrá envenenar la cache con información falsa.
Describimos a continuación las posibilidades e impacto de trabajo que un atacante debería de realizar para conseguir cumplir las cuatro condiciones anteriores.
Forzar una Consulta Se debe de forzar al DNS victima a realizar consultas al DNS autoritativo al que queramos suplantar la identidad. Como ya hemos visto anteriormente, no hace falta hacerlo de forma directa, ya que puede que la dirección IP del atacante no tenga permisos para utilizar el DNS cache como resolver, pero se pueden realizar consultas DNS de forma indirecta, mediante enlaces enviados de forma SPAM por correo, o forzando a un servidor de correo a realizar consultas a un dominio concreto, etc.
El uso de formas indirectas de forzar consultas a un dominio, no nos permite conocer exactamente cuando se va a realizar dicha consulta, pero podemos apoyarnos en la información TTL de la cache para predecir con bastante exactitud el momento exacto en el que la realizará.
[mgil@localhost ~]$ dig www.ftp.com +noauthority +nostats
; <<>> DiG 9.5.0-P1 <<>> www.ftp.com +noauthority +nostats
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18221
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION:
;www.ftp.com. IN A
;; ANSWER SECTION:
www.ftp.com. 6113 IN A 156.27.8.202
[mgil@localhost ~]$ dig www.ftp.com +noauthority +nostats
; <<>> DiG 9.5.0-P1 <<>> www.ftp.com +noauthority +nostats
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64333
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION:
;www.ftp.com. IN A
;; ANSWER SECTION:
www.ftp.com. 6084 IN A 156.27.8.202
Como vemos entre estas dos consultas, vemos como el TTL del registro en la cache utilizada ha disminuido en segundos, por lo que una vez ejecutado el comando y tomando tiempos, sabremos con bastante exactitud cuando ha expirado la entrada en la cache. Consultas sobre un autoritativo siempre muestran valores fijos.Hacer Coincidir la Sección de la Pregunta Sabiendo la pregunta que se ha hecho, ya que hemos sido nosotros los que la hemos forzado, es relativamente fácil utilizar una respuesta que contenga dicha sección.
Hacer Coincidir el Transaction ID Como ya hemos visto anteriormente, el Transaction ID es de 16 bits, con lo que teóricamente se requiere una media de 32768 intentos para obtenerlo por fuerza bruta. Como evidencia anecdótica, se intuye que existen implementaciones que solo utilizan 14 bits, con lo que el número de intentos se reduce a 8192. Se ha comprobado que obteniendo entre 8 y 16 Transaction ID, se puede predecir cual será el siguiente.
Hacer Coincidir la IP Origen de la Respuesta Auténtica Poder cumplir esta condición, implica que el atacante se encuentra en una de esas redes (20 % del total en Internet), cuyos routers permiten la suplantación de direccionamiento IP, y permiten la salida de paquetes con direcciones IP que no pertenecen a sus redes internas. Es decir se permite el “spoof IP”.
Hacer Coincidir la IP Destino y el Puerto de la Respuesta Auténtica La dirección IP destino de la respuesta auténtica será siempre la dirección IP origen de la pregunta, por lo que la IP destino es conocida. En cuanto a la obtención del puerto origen empleado para realizar la consulta, se comenta más en profundidad en el siguiente apartado.
Simplemente saber que; actuales implementaciones seleccionan el puerto para realizar consultas externas de forma aleatoria al arranque del sistema, mientras que la mayoría de las implementaciones usan el puerto estándar UDP/53 para realizar las consultas.
Si el puerto escogido es aleatorio pero estático, significa que bajo observación, obligando a realizar consultas a dominios propios del atacante se puede obtener fácilmente.
En otras ocasiones, se utilizan múltiples puertos, pero prefijados con anteriordad de forma aleatoria, se amplia el espacio efectivo para el uso de Transaction ID por un factor igual al número de puertos utilizados, es decir, multiplicamos los posibles Transaction ID por el número de puertos empleados (tres, cuatro, cinco, ... los que se hayan fijado).
En la menor de las veces, los resolvers utilizan puertos aleatorios para cada pregunta, esto agrega un nuevo campo de identificación prácticamente de 16 bits, junto al tradicional Transaction ID. Ya que excepto los 1023 primeros, disponemos de aproximadamente 64000 puertos para poder elegir. Se habla de esto en el apartado de Port Randomization.Hacer que la Respuesta Llegue Antes que la Respuesta Auténtica Una vez que un paquete ha coincidido en las cuatro premisas iniciales para que se acepte la respuesta, es aceptado por el servidor resolver mientras que el resto de paquetes son rechazados. Esto significa que el atacante tiene un tiempo muy limitado para realizar el “spoof” de su respuesta. Se ha calculado que dispone de una ventana de tiempo aproximada a 100ms, dependiendo de la distancia entre el atacante y el resolver
Este tiempo puede ser mayor si el DNS autoritativo auténtico esta sobrecargado debido a consultas, quizá realizadas por el propio atacante. Cálculos de Probabilidad de Spoof Los cálculos realizados para determinar la probabilidad de que un paquete pueda ser “spoofed” con éxito dependen de varios factores como son, el TTL de la entrada, el ancho de banda disponible por el atacante, el número de servidores autoritativos del dominio, ventana de oportunidad de envío de paquetes “spoofed”, etc...
En base a dichas variables, se ha estimado que una entrada de dominio con un TTL fijado en 3600 segundos, tiene un 10% de posibilidades de ser “spoofed” en 24 horas por un atacante que sea capaz de enviar unos 700 paquetes/segundo (aproximadamente 4.5Mbps), probabilidad que puede ampliarse a un 50% en caso de estar intentándolo durante una semana.
Para dominios con un TTL de 60 segundos, el porcentaje de probabilidad de éxito es de un 10% después de 24 minutos, 50% después de 3 horas y un 90% después de 9 horas aproximadamente.
Estos cálculos se han realizado utilizando un único puerto estático origen. En caso de que el puerto sea desconocido y tenga que ser obtenido, la probabilidad de ser “spoofed” se expande con un factor de 64000, obligando al atacante a mantener un flujo de tráfico de 285Gbps para mantener los ratios anteriores.Uso de Múltiples Puertos Aleatorios (Port Randomization) Una de las acciones realizadas en los parches ofrecidos por todos los fabricantes, es el uso aleatorio de puertos para iniciar las consultas DNS. Como ya se ha comentado anteriormente, esto no es una solución al problema sino un parche temporal, tal como dice el propio draft de la IETF.
“While this is not a replacement for cryptographic methods, the described port number randomization algorithms provide improved security/obfuscation with very little effort and without any key management overhead."
Actuales implementaciones seleccionan el puerto para realizar consultas externas de forma aleatoria al arranque del sistema, mientras que la mayoría de las implementaciones usan el puerto estándar UDP/53 para realizar las consultas.
Si el puerto escogido es aleatorio pero estático, significa que bajo observación, obligando a realizar consultas a dominios propios del atacante es obtenido fácilmente.
En otras ocasiones, se utilizan múltiples pero prefijados puertos, se amplia el espacio efectivo para el uso de Transaction ID por un factor igual al número de puertos utilizados
En la menor de las veces, los resolvers utilizan puertos aleatorios para cada pregunta, esto agrega un nuevo campo de identificación de 16 bits, junto al tradicional Transaction ID.
El organismo encargado en la gestión de los 16-bit números posibles de puertos 0-65535, IANA,los ha dividido en tres apartados.
- Well Known Ports, que van del 0 al 1023.
- Registered Ports, que van del 1024 al 49151.
- Dynamic and/or Private Ports, que van del 49152 al 65535
Esta última categoría es lo que se conoce como los puertos efímeros, que son los puertos utilizados por las aplicaciones para realizar conexiones dinámicas y privadas, suelen ser puertos escogidos de forma aleatoria en el sistema.
Existen diversos algoritmos de selección de puertos efímeros, tal cual se describen en el draft de IETF. El problema de la mayoría de ellos es la predicción del siguiente número de puerto a ser utilizado. Se han elaborado diferentes algoritmos de selección aleatoria de puertos, en el que el rango de puertos dinámicos se ha aumentado comprendiendo entre el 1024 y el 65535, de forma que se establece una matriz con todos los valores de puertos posibles y se asigna un 0 si el puerto puede ser utilizado o un 1 en caso de que el puerto ya esté siendo utilizado por alguna aplicación local.
Hay que tener en cuenta que muchos firewalls deberán de ser reconfigurados para permitir la salida de paquetes origen de consultas DNS con puertos aleatorios y mayores de 1023.Uso de Firmas Mediante DNSSec DNSSec (Domain Name Server Security Extensions), añade unas cabeceras de firmas digitales a los servidores autoritativos entre sus Resource Records (RR) para verificar que los datos solicitados coinciden con los que el administrador de la zona ha incorporado. DNSSec no provee de un túnel seguro, no cifra ningún tipo de información o esconde los datos DNS, sino que, ha sido diseñado para mantener la compatibilidad con versiones anteriores.
DNSSec, incluye unos nuevos Resource Records llamados RRSIG (firmas digitales), DNSKEY (la clave pública), DS (Firmante de la Zona) y NSEC (Puntero a la siguiente entrada segura). Las nuevas cabeceras incluidas son AD (dato autenticado) y CD (deshabilitar checking).
Un resolver validando mediante DNSSEC, utiliza estas entradas y la clave pública (asimétrica) para proveer de integridad en los datos DNS.
Los clientes que utilizan resolvers con DNSSec habilitado, garantizan una información valida de la información recibida, el dato que no sea validado es considerado “SERVFAIL” y rechazado. - DJBDNS (http://cr.yp.to/djbdns.html)
- PowerDNS (http://www.powerdns.com/)
- Unbound (http://www.docunext.com/blog/2008/07/09/unbound-dns-server/)
Detección de Ataques DNS Cache Poisoning Aunque existe mucha información acerca de como se producen los fallos y a qué es debido un envenenamiento de la cache DNS, existe poca información acerca de como prevenir o informar ante ataques de envenenamiento de cache o spoof DNS. Los dos posibles escenarios son:
- Alguien ataca un DNS resolver/forwarder que utiliza tu cliente.
- Alguien ataca un resolver/forwarder remoto para envenenar un dominio que te pertenece.
En el primer escenario, cualquier sitio que visites que haya sido envenenado dentro del resolver que utilizas, será usurpado por un sitio fraudulento. En el segundo caso, son tus usuarios/clientes quienes no podrán acceder a tus servicios o serán re-dirigidos a otros nodos utilizados para obtener sus claves y hacer un uso fraudulento de tus servicios.
En el primer caso, se deben de parchear los sistemas resolver y seguir las recomendaciones anteriores, en el segundo caso, es mucho más difícil solucionar el problema, no puedes hacer nada, no puedes obligar a parchear a todos los DNS resolver del mundo, y cualquiera de ellos puede ser utilizado por alguno de tus clientes para acceder a tus servicios.
Para saber si tu dominio está sufriendo algún tipo de ataque de envenenamiento, se observará un incremento muy alto de peticiones con nombres falsos dentro de tu dominio. El DNS autoritativo responderá con respuestas “NXDOMAIN” (No such domain) a todas esas peticiones. Sabiendo además, que posiblemente, por cada una de esas consultas invalidas, se está proporcionando al atacante una oportunidad para inyectar una respuesta falsa al resolver que está realizando todas esas consultas sobre tu servidor autoritativo, y que obviamente, puede ser un resolver utilizado por muchos de tus clientes. Uso de Snort Existen firmas SNORT disponibles para la detección de intentos de envenenamiento de la cache, que detectan un excesivo número de respuestas “NXDOMAIN” recibidas por un resolver. Mediante las firmas de Emergingthreads.net (SID: 2008470), y las firmas VRT (SID:13948 y SID:13949).
Esto cubre el escenario 1.Para el escenario 2, se requiere algún tipo de herramienta que pueda observar un número elevado de consultas “NXDOMAIN” enviadas por el DNS autoritativo. BIND no ofrece una manera simple de obtener y almacenar trazas de actividad “NXDOMAIN” excepto habilitando el modo debug.Herramienta DSC (DNS Statistic Collector) La Measurement Factory (http://dns.measurement-factory.com/tools), tiene una herramienta de estadísticas DNS que permite guardar en formato PCAP la información recibida en los servidores DNS para luego realizar estadísticas. Esa información puede ser tratada mediante “tcpdump” para obtener las respuestas “NXDOMAIN”.
# tcpdump -s1514 -nX 'udp and port 53 and (udp[10] & 128 = 128) and (udp[11] & 3 = 3)'
Mediante esta instrucción estamos capturando los paquetes que son respuesta (QR=1 --> QueryResponse), y que tienen el código de respuesta (RCODE=3) que implica respuesta desde un autoritativo indicando que el nombre de dominio referenciado en la consulta no existe (RFC1035).Uso de "tshark" Otra forma de analizar información DNS desde un fichero PCAP o en tiempo real es mediante el uso de las utilidades “tshark”.
# tshark -t ad -e ip.dst -e dns.qry.name -E separator=, -T fields -nr new.pcap dns.flags.rcode == 3
Observación de la Red Según lo que hemos comentado, los ataques spoof DNS pueden ser detectados mediante inesperados streams de datos sostenidos de aproximadamente 4.5Mbps o más durante un gran tiempo. Esto quiere decir, que recepción de tráfico constante con un gran consumo de ancho de banda desde una IP concreta, puede significar un intento de envenenamiento de la cache.
Resumen de Recomendaciones Las implementaciones de resolvers (DNS Cache), deben de tener la posibilidad de cumplir los siguientes requisitos:
- Utilizar puertos origen para realizar las consultas de forma aleatoria. Para ello se debe de modificar la entrada “query-source” del fichero de configuración “/etc/named.conf”.
query-source address * port *;
- Uso de las últimas versiones de BIND recomendadas que solucionan el problema del “Transaction ID”, de modo que ahora utiliza el rango completo disponible (0-65535).
- Uso de múltiples interfaces de red o alias IP sobre el mismo interface para poder realizar las consultas utilizando múltiples direcciones IP origen. Esto hace que la dificultad de obtener la tupla “IP Origen, IP Destino, Puerto Origen, Puerto Destino” se complique multiplicando el número de interfaces de red por 65535 que es el número de posibles Transactions ID.
Obtención de Exploits Se puede obtener un explot que se aproveche de esta vulnerabilidad en:
http://www.metasploit.com/home/
FUENTE:http://blogs.sun.com/mgil/entry/font_id_s03t_size_5
Para saber si estamos bajo un ataque dns poison aqui en el blog hay un articulo sobre eso
saludos
Entradas
