DNS Cache Poisoning

Publicado en Artículos, Seguridad,


Tweet about this on TwitterShare on Google+0Share on Facebook0Share on LinkedIn0

El DNS cache poisoning, DNS Poisoning y/o Pharming es una situación 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 diseño inapropiado de software, falta de configuración de nombres de servidores y escenarios maliciosamente diseñados 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, 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.

¿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.google.com se refiere sin duda al nodo WEB de la compañía Google donde podemos obtener información en formato básicamente conocido como HTML; el nombre mail.google.com, hace referencia al servicio de correo de la compañía Google; 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).

¿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 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.google.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.

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.

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é.

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.

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.

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 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.

Existen 13 servidores raíz 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 múltiples servidores distribuidos a lo largo del globo terráqueo. Estos servidores reciben miles de consultas por segundo, y a pesar de esta carga la resolución 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 dirección IP del servidor atacante.

  1. 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.
  2. Para eso, envía una petición a su DNS preguntando por la IP del sitio www.regalomoto.com.
  3. 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.
  4. 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 a resolver la dirección del dominio www.banco-victima.com
  5. 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.
  6. 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.

Sobre la posibilidad de poder realizar un spoof de la dirección IP (IP Spoofing) 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 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.

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 un banco por ejemplo, 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 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 (ISP’s).

Soluciones

Lo triste es que no hay una solución real. No es un problema de seguridad de sofware que se pueda arreglar con un parche o una actualización. 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 ejecución de los ataques.

Existen algunas recomendaciones para mitigar el problema, en la página 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 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.


Fuentes consultadas: DNS Cache Poisoning | Wikipedia | DNS Spoofing | IETF

Califica esta entrada

Etiquetas: , , ,


Deja un comentario

Cuanto es 15 + 8 ?
Please leave these two fields as-is:
IMPORTANTE! Necesitas resolver la operación matemática para poder continuar.

Newsletter

Redes sociales

Centro de soporte

Centro de recursos