Ataque DNS Caché Poisoning.

Siempre que un servidor DNS no tenga la respuesta a una consulta dentro de su caché, el servidor DNS puede pasar la consulta a otro servidor DNS a nombre del cliente. Si el servidor pasa la consulta a otro servidor DNS que tenga información incorrecta, estará colocándola intencionalmente o no intencionalmente, pudiendo ocurrir entonces un caché poisoning. EL Caché Poisoning es comúnmente referido como DNS Spoofing.

Métodos de Caché Poisoning.

Versiones anteriores de BIND en la implementación del DNS eran altamente susceptibles al caché poisoning. Como medios de dar una indicación provechosa, un servidor DNS que responde a una consulta, pero no necesariamente con una respuesta, llenando la sección adicional de los registros del mensaje de respuesta del DNS con información que no se relacionó necesariamente con la respuesta. Un servidor DNS que aceptaba esta respuesta no realizaba ningún chequeo necesario para asegurar que la información adicional era correcta o aún relacionada de una cierta manera a la respuesta (es decir, que el servidor que respondía tenía autoridad apropiada sobre esos registros).

Otro problema con versiones anteriores de BIND es que no había un mecanismo en el lugar para asegurarse de que la respuesta recibida fuera relacionada con la pregunta original. El servidor DNS que recibía la respuesta de la caché, contribuía otra vez al problema de la corrupción de la caché. Observe que aunque se documente bien que la implementación BIND ha experimentado problemas, otras implementaciones en práctica pudieron haber tenido, y todavía puede tener problemas similares.

Por ejemplo, suponga que hay un servidor de nombres, conocido como dnsobjetivo.com, manteniendo una red de computadoras, como se muestra en la Figura 1. Estas computadoras son en esencia clientes DNS. Una aplicación en un sistema cliente, host1, hace una consulta DNS que es enviada a dnsobjetivo.ejemplo.com. Entonces dnsobjetivo.ejemplo.com examina su caché para ver si tiene la respuesta a la consulta. Para propósito del ejemplo, dnsobjetivo.ejemplo.com no es autoritario para el nombre DNS en la consulta ni tiene la respuesta para la consulta en su caché. Debe enviar la consulta a otro servidor, llamado dnsinfectado.ejemplo.org. La información en dnsinfectado.ejemplo.org sucede que es incorrecta, comúnmente debido a la mala configuración, y la respuesta enviada de regreso a dnsobjetivo.ejemplo.com contiene información engañosa. Puesto que dnsobjetivo.ejemplo.com esta almacenando las respuestas, almacena esta información engañosa y envía la respuesta de regreso a host1. Mientras esta información exista en la caché de dnsobjetivo.ejemplo.com, todos los clientes, no solo host1, son ahora susceptibles para recibir esta falsa información.

Servidores del Atacante.

Los servidores DNS del atacante plantean una amenaza a la comunidad de Internet por que la información que estos servidores contienen puede no ser digna de confianza. Estos facilitan técnicas de ataque como host name spoofing y DNS Spoofing. Host name Spoofing es una técnica específica usada con registro PTR. Se diferencia levemente de las técnicas de DNS Spoofing en que todas las transacciones que transpiran son legítimas de acuerdo al protocolo DNS mientras que esto no es necesariamente el caso para otros tipos de DNS Spoofing.

Con host name Spoofing el servidor DNS legítimamente procura resolver una consulta PTR usando un DNS legítimo para la zona que pertenece a esa PTR. Es el registro PTR en el archivo de datos de la zona en el servidor primario que se configura adrede para señalar en alguna parte, típicamente un host confiado para otro sitio. Host name Spoofing puede tener un TTL de 0 dando como resultado no almacenar la información engañosa, aunque el host name esta siendo Spoofed. Un ejemplo más detallado sigue más adelante, el cual demuestra las amenazas que tales servidores plantean a la comunidad del Internet.

Ataques Cache Poisoning.

Un atacante puede aprovecharse de la vulnerabilidad de Cache Poisoning usando un servidor de nombres del atacante y formular información engañosa intencionadamente. Esta información engañosa es enviada como cualquier respuesta o justamente como una indicación provechosa y consigue depositarla por el servidor DNS insospechado. Una forma para forzar un servidor susceptible en la obtención de información falsa es que el atacante envíe una consulta para que un servidor DNS remoto responda información que pertenece a una zona del DNS para la cual el servidor DNS del atacante es autoritativo. Teniendo almacenada esta información, el servidor DNS remoto es probable que dirija equivocadamente a los clientes legítimos de este servidor.

Con versiones anteriores de la implementación de BIND, un atacante puede inyectar información engañosa en la caché del DNS sin la necesidad de preocuparse sobre si la consulta fue generada o no para invocar tal respuesta. Esta buena voluntad de aceptar y almacenar cualquier mensaje de respuesta permite a un atacante manipular cosas como el nombre del host para mapear la dirección IP, mapear el registro NS, etc. En Febrero de 1999 una encuesta revelaba que aproximadamente el 33% de servidores DNS en la Internet son todavía susceptibles al Cache Poisoning.

Esta es la metodología usada por Eugene Kashpureff. Kashpureff inyectó información engañosa en las caches del DNS alrededor del mundo referente a la información del DNS que pertenecía al Network Solutions Inc.’s (NSI) el Internet’s Network Information Center (InterNIC). La información volvía a dirigir a clientes legítimos que deseaban comunicarse con el servidor Web en el InterNIC al servidor Web de AlterNIC de Kashpureff. Kashpureff hizo esto como truco político que protestaba el control del InterNIC sobre dominios DNS. Cuando el ataque ocurrió en Julio de 1997, muchos servidores DNS fueron inyectados con esta información falsa y el tráfico del InterNIC fue dirigido a AlterNIC donde la página Web de Kashpureff fue llenada con la propaganda que rodeaba sus motivos y objeciones al control del InterNIc sobre el DNS.

Objetivos del Ataque.

Un atacante hace uso del Cache Poisoning para una de dos razones. La primera es una Negación de Servicio (DoS) y la otra es enmascararse como una entidad de confianza.

Negación de Servicio.

El DoS se logra de varias maneras. Uno se aprovecha de respuestas negativas (es decir, las respuestas que indican el nombre del DNS en la consulta no se puede resolver). Enviando de regreso la respuesta negativa para un nombre de DNS que podría ser resuelto, provocando un DoS para el cliente el desear comunicarse de alguna manera con el nombre DNS en la consulta. La otra manera de lograr el DoS es que el servidor del atacante envíe una respuesta que redirija el cliente a un sistema diferente que no contiene el servicio que el cliente desea.

Otro DoS asociado con el Cache Poisoning implica inserciones al registro CNAME en una caché que se refiera como un nombre canónico.

  empresa.ejemplo.org

En este ejemplo, un servidor de nombre recursivo puede terminar con este RR en su caché. Este tipo de registro CNAME es comúnmente referido como una misma referencia RR. Un atacante, después de insertar este registro de recurso en la caché del servidor puede causar que el servidor de nombres se caiga simplemente solicitando una transferencia de zonas para empresa.ejemplo.org.

Enmascarando.

La segunda razón, y potencialmente la más peligrosa es la de envenenar las cachés del DNS para redirigir las comunicaciones para enmascararlas como entidades de confianza. Si esto se logra, un atacante puede interceptar, analizar, y/o intencionalmente corromper las comunicaciones. La mala dirección del tráfico entre dos comunicaciones del sistema facilita ataques como espionaje industrial y puede hacerse virtualmente indetectable. Un atacante puede dar a la caché inyectada un corto tiempo de vida que lo hace aparecer y desaparecer lo bastante rápido para evadir la detección.

Los ataques enmascarados son simplemente posibles debido al hecho de que absolutamente un número de IP basado en aplicaciones usa nombres host y/o direcciones IP como un mecanismo para proveer autenticación basado en host. Esto carga el DNS con la responsabilidad de mantener la información actualizada y exacta, ninguna de las cuales el DNS solamente puede asegurar. Un atacante puede hacer uso de estos defectos dentro del DNS al enmascararse como un host confiado. La autenticación basada en host es vulnerable al host name Spoofing.

Este problema se muestra en la Figura 2. En este ejemplo, un atacante se aprovecha de la dependencia del programa del rshd en el contenido de los archivos “rhosts” como una forma de autenticación basada en host.

El servidor DNS del atacante, dnsmalo.ejemplo.com, es autoritario para 0.6.172.in-addr.arpa y el atacante tiene la entrada siguiente en los datos autoritarios de la zona, aunque no tiene autoridad sobre plan.org:

  8.0.16.172.in-addr.arpa.  IN      PTR   confiado.plan.org.

El equipo, confiado.plan.org, es confiado por victima.ejemplo.edu simplemente por que confiado.plan.org esta correctamente listado en el archivo rhosts del estudiante en victima.ejemplo.edu. Para el propósito de este ejemplo, el host, victima.ejemplo.edu, no es protegido por un firewall y no es empleado cualquier tipo de sensatez del DNS que compruebe por ejemplo el modo PARANOID en tcp_wrappers. Se fija la etapa donde el atacante puede ahora venir de la dirección IP 172.16.0.8 y del registro en victima.ejemplo.edu como el estudiante sin una contraseña y parecer como si la conexión viniera realmente del nombre del nombre del host confiado.

Para corregir esta vulnerabilidad, las aplicaciones tales como rlogind se han modificado para realizar una revisión del DNS. Después de recuperar el registro PTR, otra consulta es enviada al registro “A” usando el FQDN especificado en la sección de la respuesta del registro PTR regresado. En vez de cargar cada aplicación para realizar una revisión cruzada del DNS, muchos sistemas operativos Unix ahora vienen con una capacidad similar que permita que el DNS compruebe la ocurrencia durante una llamada a la función gethostbyaddr() en la biblioteca del resolver.

Esta función típicamente es usada para encontrar un nombre de host DNS usando una dirección de IP conocida (es decir, envían un consulta PTR). La versión actualizada de esta función hace operaciones de búsqueda gratuitas para el registro correspondiente “A” y entonces asegurarse de que los datos en los registros RR’s recuperados son verificados correctamente cada uno. Un ejemplo de la comprobación cruzada del DNS se muestra en la Figura 3.

Puesto que muchas librerías del resolver tienen los pasos necesariamente para prevenir el host name Spoofing, las estacas han sido elevadas para un ataque acertado usando esta metodología. Los atacantes pueden hacer uso del DNS Spoofing conjuntamente con el host name Spoofing. El atacante configura el registro PTR con el nombre del host confiado según lo explicado arriba y después intenta inyectar en la caché del servidor del DNS víctima el registro correspondiente “A” que mapea los nombres de los host confiados de nuevo en la dirección IP del atacante.

Según lo mencionado previamente, la versión anterior de BIND es altamente susceptible a este ataque, mientras que las versiones más recientes hacen el éxito de tal ataque más difícil, pero no absolutamente imposible. Así, la integridad de la información contenida dentro de la caché de un servidor del DNS debe seguir siendo sospechada hasta que capacidades más fuertes de la validación están disponibles.

Fuente: seguridad.unam.mx