Ataque DNS Spoofing.

Introducción.

DNS Spoofing se describe como un servidor DNS que hace uso de información falsa recibida desde un host que no es autoridad para la información. Es una amenaza significativa para la seguridad de las organizaciones que no han tomado medidas para protegerse de ella. El DNS Spoofing puede permitir a los atacantes acceder al correo de un sitio, y puede hacer que los usuarios sean redirigidos a sitios Web incorrectos incluso proporcionando una abertura para un ataque de Negación de Servicio.

Alcance.

Este documento procura:

• Describir dos tipos de ataques de DNS Spoofing.
• Describir los posibles resultados del malicioso Spoofing.
• Lista las soluciones recomendadas para el DNS de Unix y Microsoft.
• Lista ligas informativas para más información específica.

Método.

Escenario: La compañía, TAMJTeK Inc., está compitiendo para acabar el desarrollo del último software de juegos antes de que el capital de la empresa salga. Se comienza a anunciar el aviso pendiente de una brecha en tecnología de este juego en el sitio Web de Internet. Usted tiene una llamada de uno de los socios de la empresa. Ella desea saber por que termina llegando a www.hackncrack.net cuando intenta llegar a www.tamjtek.com. Usted intenta conectarse al sitio Web y, seguro, termina llegando a www.hackncrac.net. Usted prueba algunos otros sitios y todo parece muy bien excepto, que encuentra que su competidor más fuerte ha anunciado una brecha en el mismo juego. Su sitio Web demuestra una imagen de su juego, la cual parece notablemente similar a la suya con aspectos virtualmente idénticos. ¿Coincidencia? Quizás no.

En este año una aplicación desarrollada descubre que un número substancial de compañías en línea son vulnerables a DNS Spoofing. Esta vulnerabilidad hace que el escenario de TAMJTeK Inc. sea posible. Un ejemplo muy conocido de DNS Spoofing ocurrió en 1997 cuando Eugene Kashpureff redirigió a los que intentaban conectarse al registrar de dominios InterNIC y los llevaba a su propio sitio Web AlterNIC. EL señor Kashpureff utilizó el método de agregar un registro de datos falso en la respuesta de la consulta. Más recientemente, el DNS Spoofing y el secuestro de dominios fueron logrados usando solamente correo electrónico y un fax.

Ejemplo 1: Asume los siguientes dos dominios, hackncrack.net y tamjtek.com con las siguientes configuraciones:

  Hackncrack.net  (10.0.0.0)          Tamjtek.com (11.0.0.0)
 Ns1.hackncrack.net (10.0.0.5)       ns1.tamjtek.com (11.0.0.5)
 www.hackncrack.net(10.0.0.6)        www.tamjtek.com(11.0.0.6)

El atacante ha modificado el servidor de nombres Hackncrack para responder a una consulta recursiva para los registros DNS Hackncrack con un falso registro autoritario, mapeando www.tamjtek.com a la dirección IP 10.0.0.6. El atacante entonces dirige una consulta al servidor de nombres TAMJTeK preguntando por los registros DNS sobre el sitio del atacante. El servidor de nombres TAMJTeK resuelve la consulta yendo al servidor de nombres Hackncrack. Desde que el servidor de nombres TAMJTeK no esta protegido contra DNS Spoofing, acepta y almacena el registro falso que incluye la respuesta. Siempre que una consulta se haga al sitio Web de TAMJTeK, el registro para el sitio Web Hacncrack será regresado y todo será redireccionado a www.hacckncrack.net. El atacante en Hackncrack puede también engañar un registro MX para dirigir el correo de TAMJTeK a su servidor de correo. Un registro falso MX puede desapercibir una cantidad de tiempo significativa si el atacante esta bien informado.

Ejemplo 2: Prediciendo el número de consulta ID, un atacante puede realizar otra adaptación de DNS Spoofing personificando un servidor de nombres. El protocolo DNS usa el protocolo UDP para comunicarse. Dada la naturaleza sin conexión de UDP, DNS es diseñado para establecer comunicaciones ordenadas entre equipos. Esto es logrado identificando datagramas con un número de consulta ID. El host que inicia la consulta asigna este número. En las versiones anteriores de BIND, este se incrementaba secuencialmente para cada nueva consulta. Con este ejemplo, podra observar como el atacante engaña a los usuarios de TAMJTeK.com haciendo parecer que ellos van a www.AnyBank.com cuando, en realidad, se están conectando a www.Hackncrack.net. El atacante en Hackncrack.net consulta TAMJTeK.com para la información que los atacantes poseen del dominio. El servidor de nombres TAMJTeK resuelve las consultas referidas a Hackncrack.net El servidor de nombres del atacante regresa la información correcta sobre sí mismo a TAMJTeK.com y el servidor de nombres de la víctima lo reenvía al host del atacante que inició la consulta. Para montar este ataque, el intruso tiene que, primero, aprender cual es el número ID de la consulta. Escuchando los datos durante la consulta se puede obtener éste. Una vez que el número ID sea disponible, el atacante hace un datagrama de la respuesta del DNS con información falsa: www.AnyBank.com = 10.0.0.6 y lo configura como si la fuente fuera ns.AnyBank.com. El atacante inicia una consulta para TAMJTaK.com preguntando por información sobre AnyBank.com e inserta el datagrama modificado en la línea como la respuesta. De nuevo, el servidor de nombres inseguro TAMJTeK.com acepta y almacena los datos. Cuando los usuarios de TAMJTeK intentan conectarse a www.AnyBank.com, ellos son redirigidos a una página Web específica en el servidor Web Hackncrack que contiene exactamente la información de la página de la cuenta AnyBank.com. En este punto, el atacante puede recolectar cuentas de usuarios y números de PIN a voluntad.

Ejemplo 3: Este ejemplo no describe un ataque DNS Spoofing en el sentido técnico más estricto del término pero, los resultados al final son los mismos y se puede decir que este estilo de ataque tiene el potencial para “envenenar” la caché de cada servidor de nombres en el Internet. Network Solutions Inc. fue el primero y sigue siendo uno de los primeros en registrar nombres de dominio. Durante el proceso de registro, NSI ofrece tres métodos de autorización y autenticación para proteger los registros contra actualizaciones no autorizadas. Estos métodos son colectivamente referidos por NSI como “Guardian”. El contacto personal que esta listado en el registro de nombre de dominio, también es conocido como un Guardian. Estos métodos son:

1. Mail-Form (Mínima Seguridad): El contacto somete una dirección de correo electrónico de la cual toda la administración de registro origine. Cuando un cambio de registro se somete a la NSI vía correo electrónico, la dirección de correo electrónico fuente es comprada con la dirección de correo sometida durante el inicio del dominio original.
2. Cryp-Password (Un poco de Seguridad): Durante la disposición inicial, el contacto escoge una contraseña. Esta contraseña es cifrada y almacenada en la base de datos del NSI. Cuando el administrador somete un cambio de registro, la versión en texto plano de la contraseña es incluida. NSI cifra el texto plano de la contraseña que acompaña la petición de cambio y la compara con la original.
3. PGP (Más Seguridad): NSI soporta mensajes cifrados con PGP si se originaron desde una plataforma Unix. Ninguna otra plataforma es soportada en este momento.
   

Los nombres conocidos como Nike, Net Media, Web Networks, Exodus y el Consorcio World Wide Web han sido afectados por la trampa del proceso de autentificación de la actualización de registros DNS. Durante un incidente, las pertenencias de Internet.com y otros 1300 dominios fueron transferidos lejos de Net Media cuando NSI recibió un fax que consistía en documentos falsos. Llevó varios días para que el dueño legal de los documentos retomara el control de los mismos. Imagine el estrago de algunos que justo al inicio de leer el correo electrónico corporativo, fueron redirigidos durante la confusión. Obviamente, cuanto más seguro el proceso de autentificación, más seguros los registros del dominio.

Asegurando el DNS.

Una discusión a fondo de este tópico esta fuera del alcance de este documento pero una lista de ligas relevantes para registros se incluye al final. La siguiente lista ha sido incluida como una referencia general que puede ser de ayuda para asegurar la configuración particular de tu DNS:

Conclusión.

EL artículo http://www.infosec.com/internet/99/internet_011199a_j.shtml en el sitio Web Info-Sec.com, asegura que una de cada tres organizaciones con presencia en Internet es vulnerable al DNS Spoofing. Este tipo de ataques puede causar que el correo electrónico sea redirigido así como los usuarios y clientes cuando procuren conectarse al sitio Web afectando negativamente la confianza del consumidor en la compañía. El simple acto de incrementar el nivel de seguridad que se usa para autentificar la actualización de registros con los registros del dominio puede incrementar enormemente la seguridad del DNS. En el 11 de Enero del 2000 un artículo en Wired.com http://www.wired.com/news/business/0,1367,36797,00.html por Chris Oakes, el portavoz de Network Solutions, Brian O’Shaughnessy es citado diciendo “… las herramientas -desde 1996- has estado disponibles para nuestros clientes para protegerse,…”. En el mismo artículo el señor O’Shaughnessy indico que “… la responsabilidad esta en el mismo registrant para considerar que su dominio es seguro”. Puntos a considerar:

---

Recursos.

1. Listas de correo BIND, Grupos de noticias y otros recursos:
   http://www.isc.org/products/BIND/
2. Página de suscripción a los Boletines del Instituto SANS:
   http://www.sans.org/newsletters/sac/ bind-users@isc.org
3. Enviando un correo a bind-users-request@isc.org Lista de correo del CERT. Enviando un correo a cert-advisory-request@cert.org Servidor de Recursos DNS MS:
   
4. Servicio de notificación de productos de seguridad MS. Suscripción por correo electrónico a:
   Microsoft_security-subscribe-request@announce.microsoft.com
   

---

Fuentes.

1. Microsoft Inc. “How to Prevent DNS Cache Pollution”:
   http://support.microsoft.com/kb/q241352/
2. Microsoft Inc. “Microsoft DNS Registry Parameters, Part 2 of 3”:
   http://support.microsoft.com/kb/q198409/
3. Underground Security Systems Research. “DNS Abuse”:
   http://www.ussrback.com/docs/papers/protocols/mi004en.htm
4. Bicknell, Craig. “NSI’s Webjacking Epidemic”. 8 June 2000:
   http://www.wired.com/news/business/0,1367,36797,00.html
5. Wired News Report. “Webjackers Do it to Nike”. 21 June 2000:
   http://www.wired.com/news/business/0,1367,37146,00.html
6. Seifried, Kurt. “DSN spoofing/registering/etc”, BUGTRAQ Archive Message ID
   001901bf53c91e00010a@edmontonint.seifried.org. 31 December 1999. URL:
   http://www.securityfocus.com/

Fuente: seguridad.unam.mx