Documente Academic
Documente Profesional
Documente Cultură
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
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.
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.
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
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:
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.
1. http://compsec101.antibozo.net/papers/dnssec/dnssec.html
Fuente. 5