DNS CACHE POISONING

El DNS cache poisoning, DNS Poisoning y/o Pharming es una situacin creada de manera maliciosa o no deseada que provee datos de un Servidor de Nombres de Dominio (DNS) que no se origina de fuentes autoritativas DNS. Esto puede pasar debido a diseo inapropiado de software, falta de configuracin de nombres de servidores y escenarios maliciosamente diseados que explotan la arquitectura tradicionalmente abierta de un sistema DNS. El concepto de envenenamiento de la cache DNS es muy simple. El servidor DNS del usuario, enva una peticin 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 direccin IP falsa asociada al nombre que el usuario solicita, dirigiendo su peticin a un servidor que no es el que el usuario quiere acceder, es ms, 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. Que hace importante las comunicaciones en Internet? Ante esta pregunta se nos pueden ocurrir multitud de respuestas meramente tcnicas, se nos pueden venir a la cabeza miles de elementos que facilitan la comunicacin entre dispositivos en internet, o que incrementan la seguridad o incluso que nos permiten transmitir informacin 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.google.com se refiere sin duda al nodo WEB de la compaa Google donde podemos obtener informacin en formato bsicamente conocido como HTML; el nombremail.google.com, hace referencia al servicio de correo de la compaa Google; y as podamos continuar con una lista enorme de nombres utilizados de forma estndar 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). Que hace tan Importante al DNS? El DNS permite no tener que memorizar que 74.125.113.147 es el sitio WEB de Google para poder acceder a el, o que 74.125.229.120 es uno de sus servidores de correo, nos basta con recordar Google.com Realmente Internet funciona en base a nmeros, no con nombres, pero a las mentes humanas se nos da mejor recordar nombres en lugar de nmeros, por eso nace el servicio DNS que permite traducir nombres a direcciones y viceversa. Realmente, nadie se para a pensar que al escribir www.google.com, se deben de realizar una serie de tareas previas a la presentacin de la pgina WEB, como es encontrar la direccin 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 bsqueda de cualquier nombre. Se requiere mucha informacin previa para poder llegar a un sitio cualquiera de internet, dicha informacin es fcil de obtener, pero costosa si por cada conexin 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 bsquedas durante un tiempo limitado y establecido por el propietario de la zona. De esta forma, obtenemos un modelo distribuido y totalmente dinmico de conversin de nombres a direcciones IP y viceversa. Esto hace que posteriores consultas no tengan que realizar toda esta labor.

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 jerarqua mayor en caso de que: La peticin 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. Por cada dominio del tipo www.dominio.organismo, en el mejor de los casos, se estarn abriendo tres conexiones diferentes consecutivas no en paralelo. Por lo tanto, en casos de mxima utilizacin del servicio DNS, las peticiones estarn siendo dirigidas de tres en tres como poco. Esta situacin podra 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 bsquedas anteriores. En este caso, rebotar el servicio o re-iniciar los sistemas provocan la prdida 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, permanecern en ella el tiempo determinado por el campo TTL de la configuracin del servicio. Obviamente cuantos ms 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 saltndose las normas establecidas en el RFC1035 y otorgando manualmente mayores tiempos de vida de los datos (campos TTL) en la cach. Esta prctica, puede provocar la denegacin 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, podramos tener un tiempo de validez de una entrada durante un tiempo mayor que el indicado y por tanto podramos 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 ms costosas de realizar y cada vez son ms utilizadas para la generacin de informes, reglas de filtrado (control URL) y anlisis de logs de firewalls, servidores, servicios, etc. Cualquier ataque sobre los DNS 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 bsquedas de dominio sobre el DNS puede resultar nefasto para el mismo. Muchas de las tcnicas de ataques de denegacin de servicio sobre servicios DNS, se basan precisamente en el envo masivo de peticiones DNS sobre zonas de dominio directo o inverso. Tambin se pueden utilizar las bsquedas recursivas para realizar spoof de DNS y envenenamiento de la cach sobre los servidores DNS. Esto puede causar que mucha informacin sensible de usuarios pueda ser enviada a servidores falsos o navegacin sobre WEBs suplantadas. Para el funcionamiento de Internet, es necesario la total funcionalidad de los Root Servers, cualquier peticin, cualquier servicio y cualquier comunicacin 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 existiran comunicaciones entre usuarios/sistemas. Existen 13 servidores raz en toda Internet, cuyos nombres son de la forma letra.root-servers.org, aunque siete de ellos no son realmente servidores nicos, sino que representan mltiples servidores distribuidos a lo largo del globo terrqueo. Estos servidores reciben miles de consultas por segundo, y a pesar de esta carga la resolucin de nombres trabaja con bastante eficiencia. En el siguiente 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 direccin IP del servidor atacante. 1. El atacante enva 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, enva una peticin a su DNS preguntando por la IP del sitio www.regalomoto.com. El servidor DNS, tras pasar por los servidores autoritativos superiores en la jerarqua, llega finalmente al servidor autoritativo para el dominio regalomoto.com que pertenece al atacante, y pregunta por la IP del nodowww.regalomoto.com. El servidor DNS atacante, responde con respuestas de re-direccin 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 a resolver la direccin 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 direccin IP del nodo www.banco-victima.com. Simultneamente a la respuesta del servidor autoritativo DNS del dominio banco-victima.com, el atacante enva 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 enva una consulta al servidor DNS autoritativo del dominio

2. 3.

4.

5. 6.

solicitado, ste recoge elTransaction 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 nmero mediante mecanismos de fuerza bruta es complicado, a menos que el Transaction ID no sea seleccionado realmente de forma aleatoria y pueda ser obtenido fcilmente. El Transaction ID es un nmero de 16 bits, con lo que tericamente se requiere una media de 32768 intentos para obtenerlo por fuerza bruta. Como evidencia anecdtica, se intuye que existen implementaciones que solo utilizan 14 bits, con lo que el nmero de intentos se reduce a 8192. Sobre la posibilidad de poder realizar un spoof de la direccin IP (IP Spoofing) del servidor DNS autoritativo, este es un grave problema que no resuelven muchos ISPs que dan acceso a la red. El MIT mantiene una pgina WEB con la estadstica de pruebas de suplantacin IP generada por 13109 sensores dispersos en Internet. El resultado es que, casi el 20% de las direcciones IP de Internet pueden ser suplantadas.

FRAUDE EN SERVICIOS FINANCIEROS

El mtodo 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 tpico phising scam, en el cual la victima (consumidor), visita el sitio WEB del un banco por ejemplo, y es alimentado con contenido malicioso en lugar de la pgina original del banco. Esto sucede debido a que el atacante sustituye la entrada de la direccin IP DNS original del banco por una direccin 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 vern afectados, creando de esta forma un gran agujero de seguridad. Al contrario que PCs infectados con troyanos y ataques similares, el envenenamiento de la cache se realiza de forma muy transparente y no es detectado por productos antivirus/antispyware/antimalware. 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 (ISPs).

SOLUCIONES
Lo triste es que no hay una solucin real. No es un problema de seguridad de sofware que se pueda arreglar con un parche o una actualizacin. Es un error de la arquitectura del protocolo DNS. Si bien es cierto que hay parches para el software DNS, no solucionan el problema, lo nico que hacen es dificultar la ejecucin de los ataques. Existen algunas recomendaciones para mitigar el problema, en la pgina de Dan Kaminsky, el descubridor de esta vulnerabilidad, 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 solucin vlida es DNSSec, los parches aadidos, como muchos parches de seguridad, no corrigen el problema, sino que simplemente son medidas disuasorias. En este caso, se aade una capa de aletoriedad a cada consulta, que es introducida en el nmero de puerto usado en cada consulta, es por tanto, un arreglo temporal hasta el uso de alguna otra tcnica que solucione realmente el envenenamiento de la cache.