DNS: el servicio más preciado … – Administración e Instalación de Redes de Computadores

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.

Ejemplos de modus operandi:
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 http://www.hackncrack.net cuando intenta llegar a http://www.tamjtek.com. Usted intenta conectarse al sitio Web y, seguro, termina llegando a http://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)
http://www.hackncrack.net(10.0.0.6) http://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 http://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 http://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 http://www.AnyBank.com cuando, en realidad, se están conectando a http://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: http://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 http://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.

Una posible solución sería eliminar las relaciones de confianza basadas en la dirección IP o el nombre de las máquinas, sustituyéndolas por relaciones basadas en claves criptográficas; el cifrado y el filtrado de las conexiones que pueden aceptar nuestras máquinas también son unas medidas de seguridad importantes de cara a evitar el spoofing.

Fuentes:
http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-unixsec/unixsec-html/node274.html
http://www.seguridad.unam.mx/labsec/tuto/?id=135&ap=articulo&cabecera=2

DNS Inject
Con esta técnica conseguimos spoofear nuestro hostname, es decir, que un servidor nos asocie el nombre de host que queramos (y no el que tiene realmente, que es único) (en realidad, puede haber más de uno, pero sólo uno es el real, lo que se conoce como “canonical name” mientras que los demás son simples “aliases”).

Modus operandi:
Como se puede intuir el truco está en forzar al NS a que de una respuesta falsa (siempre en favor nuestro :-)). Digamos que modificamos los datos del NS para que responda a nuestra IP con el hostname que nosotros queremos y no con el que debería hacerlo realmente. Se dice que hemos “inyectado” (injectado, en inglés :-P) el NS.

Una solución que se me ocurre es la de llevar un control más preventivo de las respuestas que nos da el NS verificando periódicamente que sean las verdaderas, con alguna copia de seguridad encriptada que no sea modificable por cualquiera.

Fuentes:
http://www.um.es/docencia/barzana/DIVULGACION/INFORMATICA/irc01.html

Hola,

Abro esta sección (ventajas de tener el blog sindicado) con un bug en el servicio DNS que ha dado varios quebraderos de cabeza, mi idea, excepto si me quitan todas las ideas es postear algún otro post para no escribir ahora un post enorme que nadie lea.

DNS Cache Poisoning [1] [2] [3]

Esta técnica se remonta a los orígenes de los servidores DNS.
Se trata de someter al servidor de DNS a un engaño haciendole creer que ha recibido información correcta. cuando realmente es información envenenada (algo parecido puede suceder en ARP.. otro protocolo de traducción de direcciones), y esta información se distribuya durante el tiempo que quede cacheada a los clientes que realizen peticiones DNS.

Normalmente se aprovecha un fallo de seguridad en el servidor, para poder ‘inyectar’ y que el servidor acepte información envenenada, por ejemplo, cuando el servidor no puede determinar la veracidad de la información de origen y hace que acepte cualquier petición.

Esto puede aprovecharlo un atacante para tomar el control de las acciones del servidor, pudiendo redirigirlo a otro que este bajo su control.

Este tipo de envenenamiento se produce en el servidor, cuando hablamos de envenamiento en el cliente se denomina Pharming [4].

Las razones que suelen mover este tipos de ataques son robos de identidad, distribución de malware y la distribución de información falsa, también para aprovecharse de ataqutes MITM (man-in-the-middle).

Una solución es usar servidores DNS seguros, DNSSEC [5]

No quiero extenderlo mucho más aunque se podrían dar más detalles, os dejo unas referencias muy interesantes, en concreto el pdf de [3] que además de definir este concepto da medidas con el objetivo de prevenior estos ataques, aqui mas abajo:

[1] http://en.wikipedia.org/wiki/DNS_cache_poisoning
[2] http://www.sahw.com/wp/archivos/2006/03/28/envenanamiento-dns-definicion-y-metodos-de-prevencion/
[3] http://www.infosecwriters.com/text_resources/pdf/DNS_TOlzak.pdf
[4] http://es.wikipedia.org/wiki/Pharming
[5] http://en.wikipedia.org/wiki/DNSSEC

Saludos

explota los problemas de los servidores DNS o el de los usuarios. El atacante redirecciona un nombre de dominio a otra máquina distinta. De esta forma el usuario piensa que esta usando el servidor pero esta en otro.

Funcionamiento, dos formas:
1- se puede atacar directamente a los servidores DNS, (esta solución es la menos discreta y más complicada)
2- atacando a los clientes (modificando el fichero hosts) presente en Windows, GNULinus o Unix. Para ello se introduce un troyano en el disco duro de la víctima (lo cual es mucho más sencillo)El propio “troyano”puede tener instrucciones para restaurar la tabla original y autoinmolarse, borrando del disco duro el rastros de su presencia, eliminando casi totalmente las huellas del ataque, la próxima visita al banco no será desviada y el usuario no se dará cuenta del robo de su password.

Posibles soluiciones
-software para ello
“los expertos recomiendan:
Utilizar un software antimalware que combine sistemas de detección proactivos y reactivos, ya que la forma más sencilla de manipular un ordenador para que sea víctima del “pharming” es a través de un código malicioso, generalmente troyanos. Hay que utilizar sistemas de protección proactivos, capaces de adelantarse a las amenazas y bloquearlas.”http://www.belt.es/noticias/2005/abril/01/pahrming.htm

“Instalar un firewall personal: para evitar que un hacker pueda entrar en el ordenador a través de un puerto de comunicaciones desprotegido, y modificar el sistema.

Actualizar regularmente el software instalado en el equipo o tener activados los sistemas de actualización automática, de forma que no existan vulnerabilidades.” http://www.belt.es/noticias/2005/abril/01/pahrming.htm

http://es.wikipedia.org/wiki/Pharming
http://www.belt.es/noticias/2005/abril/01/pahrming.htm
http://www.laflecha.net/canales/seguridad/articulos/pharming/

ATAQUE A DNS MEDIANTE DENIAL OF SERVICE “DoS”
(NEGACIÓN DE SERVICIO)

La negación de servicios contra el DNS es uno de los impactos más peligrosos de ataque al sistema de nombres.

DoS puede ser logrado en diferentes maneras:

– Puede devolver respuestas negativas que nos indican que el nombre DNS no existe.

– También puede redireccionar la petición del cliente a un servidor que no contiene el servicio que el cliente pide.

– Se puede enviar una gran cantidad de peticiones con una dirección IP falsificada al DNS que permite recursión, el DNS procesa las peticiones enviadas y manda una respuesta al sistema ocupando muchísimo espacio lo que provoca que caiga el sistema.

Los ataques DoS en los servidores DNS pueden también alcanzar el mismo objetivo con mayor efecto.
Estos ataques intentan convencer al servidor DNS, por ejemplo:

– Para almacenar direcciones falsas;
Cuando un servidor DNS realiza una búsqueda el atacante puede redireccionar a su propio servidor o bien a un “agujero negro”.
La negación de servicio se utiliza contra los servidores raíz DNS de Internet, lo que produce es que se colapse la red generando tiempos de normalización superiores a las 48 horas.

Los servidores DNS tienen recursión activada.

La mayoria de las veces estos problemas se producen porque el DNS no está bien configurado.

Prevención:

Asegurarnos de que el DNS no tenga recursión, para ello podemos habilitar el BIND, por ejemplo en su última versión BIND9.
BIND es una implementación del sistema de nombres de dominio.

Fuente:

http://ftp.ucv.ve/Documentos/Evento%20de%20Seguridad/Ponencia%2012%20Francisco%20Obispo.ppt

http://www.seguridad.unam.mx/labsec/tuto/?id=181&ap=articulo&cabecera=2

Nombre:pharming

explota los problemas de los servidores DNS o el de los usuarios. El atacante redirecciona un nombre de dominio a otra máquina distinta. De esta forma el usuario piensa que esta usando el servidor pero esta en otro.

Funcionamiento, dos formas:
1- se puede atacar directamente a los servidores DNS, (esta solución es la menos discreta y más complicada)
2- atacando a los clientes (modificando el fichero hosts) presente en Windows, GNULinus o Unix. Para ello se introduce un troyano en el disco duro de la víctima (lo cual es mucho más sencillo)El propio “troyano”puede tener instrucciones para restaurar la tabla original y autoinmolarse, borrando del disco duro el rastros de su presencia, eliminando casi totalmente las huellas del ataque, la próxima visita al banco no será desviada y el usuario no se dará cuenta del robo de su password.

Posibles soluiciones
-software para ello
“los expertos recomiendan:
Utilizar un software antimalware que combine sistemas de detección proactivos y reactivos, ya que la forma más sencilla de manipular un ordenador para que sea víctima del “pharming” es a través de un código malicioso, generalmente troyanos. Hay que utilizar sistemas de protección proactivos, capaces de adelantarse a las amenazas y bloquearlas.”http://www.belt.es/noticias/2005/abril/01/pahrming.htm

“Instalar un firewall personal: con esta precaución se evita que un hacker pueda entrar en el ordenador a través de un puerto de comunicaciones desprotegido, y modificar el sistema.

Actualizar regularmente el software instalado en el equipo o tener activados los sistemas de actualización automática, de forma que no existan vulnerabilidades.” http://www.belt.es/noticias/2005/abril/01/pahrming.htm

http://es.wikipedia.org/wiki/Pharming
http://www.belt.es/noticias/2005/abril/01/pahrming.htm
http://www.laflecha.net/canales/seguridad/articulos/pharming/

– DNS Footprinting –

Con este tipo de ataque los intrusos pueden captar una gran cantidad de información acerca de la infraestructura de la red interceptando los paquetes de DNS para lograr identificar sus objetivos, aprender acerca de su DNS, los nombres de las máquinas, y el esquema IP que se emplea en dicha red. Esta información revela la funcionalidad de ciertas máquinas presentes en la misma, permitiendo al intruso decidir cuáles son los objetivos más fructíferos y otra forma de atacarlos.

En otras palabras, es el proceso de recolectar datos observando el ámbito de una red específica, usualmente con el propósito de encontrar caminos para introducirse dentro del ambiente en el que está inmersa. El footprinting puede revelar vulnerabilidades e incluso mejorar la facilidad con la cual éstas pueden ser explotadas.

Soluciones a este problema y otros como IPSoopfing, DoS, direccionamiento, etc, se comentan a continuación aunque no siempre consiguen abordarlo por completo:

– DNS redundante. Esto significa colocar más de un solo servidor DNS para la resolución de nombres dentro de la red. Esto puede implicar una mayor cantidad de recursos inicialmente pero a la larga es la solución más eficaz y más escalable que se puede representar.

– Doble configuración del cliente. Se recomienda en cada uno de los clientes colocar dos direcciones para DNS, una la del servidor de directorio activo, y otra la de su proveedor de acceso Internet. De esta manera está garantizando que tu servicio de DNS va estar activo 100%, si no de forma local de forma remota a través de el sistema de tu proveedor de acceso a Internet.

– Instalar un servidor en tu red externa de DNS y otro para la red interna. Esta estrategia te permite controlar el acceso a los recursos por separado, es decir, así se van a resolver todos los requerimientos de todos aquellos que sobrepasen el ámbito de su red local, mientras que el sistema de resolución de nombres para la LAN esta respaldado por un servidor interno que permite mantener actualizado y seguro el esquema de direcciones IP’s sin tener que realizar consultas a recursos externos.

– Control de interfaces de red. Limitando el acceso a consultas con esta medida, se consigue la resolución de DNS sólo por una de las interfaces de su servidor. De esta manera la interface de la red interna hacerla que a permitir la resolución de nombres de dicha red mientras que la interfase externa no a permitir resolución de nombres de tipo DNS.

– Uso de directorio activo(Active Directory). Es la implementación de Microsoft del servicio de directorios LDAP para ser utilizado en entornos Windows. El Directorio Activo permite a los administradores establecer políticas a nivel de empresa, desplegar programas en muchos ordenadores y aplicar actualizaciones críticas a una organización entera. Un Directorio Activo almacena información de una organización en una base de datos central, organizada y accesible. Pueden encontrarse desde Directorios Activos con cientos de objetos para una red pequeña hasta Directorios Activos con millones de objetos.

– Limitar el trafico por IP. Una forma de proteger las transferencia de zonas es especificando la IP de los servidores DNS que participan en la transferencia de zonas. De esta manera se puede limitar a dichos servidores el acceso, y un intruso va tener una labor mucho más difícil para lograr dicho acceso.

– Encriptar el trafico DNS. Utilizando el protocolo de IPSec o la implementación de VPN del sistema operativo. ¿Alguno ha usado IPSec?

– Proteger la caché. Consiste en prevenir la corrupción de la caché. No he encontrado como llevar a cabo esta parte, ¿si alguno sabría hacerlo?

– Autorizar las actualizaciones dinámicas de DHCP. Se realiza a través del sistema DHCP, el cual entrega direcciones de configuración inicial a los clientes. Para prevenir las actualizaciones dinámicas no autorizadas se debe autorizar el servidor DHCP dentro del servidor de directorio activo.

Por otra parte se puede cerrar todo el tráfico de su red al mundo exterior denegando todo acceso Internet y creando únicamente un punto de acceso al sistema para el servidor. Estas medidas aseguran el servidor DNS para tomar la mayoría de los tráficos pero pueden comprometer la funcionalidad del mismo en la red impidiendo al usuario el acceso a Internet, o resolver nombres que no pertenezcan al directorio activo o redes externas. Hay ocasiones en las que este tipo de medidas radicales pueden llegar a ser una garantía pero es el usuario el que debe hacer balance entre seguridad y funcionamiento de la red.

Enlaces:
– http://www.creangel.com/
– http://www.microsoft.com/latam/technet/seguridad/
– http://msi.wikispaces.com/mo1_mades

Esta web te indica algunas nociones de como llevar a cabo un ataque de este tipo :O
– http://www.hackersdelocos.com.ar/

Me gustaria matizar lo que dijo el compañero sobre el ataque DoS, muy bien explicado. Existe una variante mas “reciente” del ataque DoS llamada DDoS (Distributed Denial of Service).
La mecanica es similar a la del ataque DoS, por no decir identica. La unica diferencia radica en que el ataque no se realiza desde una sola maquina, ya que eso hoy dia es totalmente inviable dado el enorme ancho de banda que manejan estos servidores.
Una sola maquina enviando paquetes jamás podria saturar un servidor de estas caracteristicas.
Por lo tanto el ataque DDoS se realiza utilizando varias maquinas previamente infectadas, llamadas “zombies”.
Normalmente las maquinas son infectadas con mucha antelacion mediante algun tipo de virus o gusano y programadas para que se ejecute el ataque DoS al mismo tiempo en todas las maquinas contra un mismo servidor.
Esto hace que generalmente el servidor se sature o caiga durante un tiempo indefinido, lo que puede provocar grandes perdidas en segun que empresas. En cuanto a los servidores DNS, pues lo mismo.

Vulnerabilidad de BIND.

El DNS ID Hacking no es una forma usual de hacking/spoofing o cualquier otro. Este método se basa en una vulnerabilidad en protocolo del DNS. Más eficaz, el DNS ID hack/spoof es muy eficiente y muy fuerte porque no hay generación de demonios de DNS que se escape de ella (incluso WinNT).

Breve explicacion del protocolo DNS
El cliente (cliente.prueba.com) envía una petición de resolución del dominio “www.pagina.com”. Para resolver el nombre, cliente.prueba.com utiliza “dns.prueba.com” para el DNS. Ahora que dns.prueba.com ha recibido la petición de la resolución de cliente.prueba.com, dns.prueba.com tendrá que resolver el nombre.
dns.prueba.com pregunta a ns.internic.net quién es el servidor de nombres raíz para la dirección de http://www.pagina.com, y si no la tiene, envía la petición a un servidor de nombres que tenga autoridad en dominios ‘.com’. Aquí podemos ver que ns.internic.net contestó a ns.prueba.com (que es el DNS que tiene autoridad sobre el dominio prueba.com), que el servidor de nombres de otro.com tiene la IP 144.44.44.4 (vamos a llamarlo ns.otro.com). Ahora nuestro ns.prueba.com pedirá a ns.otro.com la dirección de http://www.pagina.com, pero éste no la tiene y transmitirá la petición al DNS de pagina.com el cuál tiene autoridad para pagina.com. hora que conocemos qué dirección IP tiene autoridad en el dominio “pagina.com” (lo llamaremos ns.pagina.com), le preguntamos cuál es la IP de la máquina www (www.pagina.com). Y ahora tenemos por lo menos nuestra respuesta. Teniendo la respuesta, podemos remitirla a nuestro cliente cliente.prueba.com.

Esta es una vulnerabilidad en BIND (descubierta por SNI). De hecho, el DNS es fácilmente predecible, tenemos que escuchar sólamente un DNS en orden para hacer lo que deseemos. El DNS utiliza un ID al azar en el principio pero sólamente aumenta para las preguntas siguientes. Es fácil explotar esta vulnerabilidad. Abajo se muestra la forma:

1. Puede escuchar fácilmente los mensajes que viene a un DNS al azar (ns.ejemplo.com para este ejemplo).

2. Preguntamos NS.victima.com para resolver (aleatorio).ejemplo.com. NS.victima.com pedirá a ns.ejemplo.com resolver (aleatorio).ejemplo.com

ns.victima.com –> [?(aleatorio).ejemplo.com ID = 444 ] –> ns.ejemplo.com

3. Ahora tenemos el ID del mensaje de NS.victima.com, y sabemos qué rango ID tendremos que utilizar. (ID = 444 en este ejemplo).

4. Entonces hacemos una petición de resolución por ejemplo a http://www.microsoft.com para NS.victima.com

(Nosotros) –> [?www.microsoft.com ] –> ns.victima.com
nc.victima.com –> [?www.microsoft.com ID = 446 ] –> ns.microsoft.com

5. Inundamos el servidor de nombres ns.victima.com con el ID (444) que tenemos y entonces lo aumentamos.

ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 444] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 445] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 446] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 447] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 448] –> ns.victima.com
ns.microsoft.com –> [www.microsoft.com = 1.1.1.1 ID = 449] –> ns.victima.com

Ahora sabemos que los ID’s son predecibles, y aumentan solamente. Inundamos ns.victim.com con respuestas engañosas con ID 444+. Para solucionar este problema las versiones de 8.3.4, 4.9.11 y las recientes 8.2.x y 9.x de BIND no son vulnerables a este tipo de ataque.

Se me ha olvidado poner la referencia:

http://www.seguridad.unam.mx/labsec/tuto/?id=134&ap=articulo&cabecera=2

Dentro de los ataques mediante DoS (Negación de Servicio) que ya ha comentado Mª José, tenemos distintas variantes:

– Consumo de ancho de banda: Son los más viejos y elementales y
consisten simplemente en consumir todo el ancho de banda, es relativamente sencillo:

Ejemplo:
Un servidor de Internet pequeño, un ADSL típico, con una entrada de 512 Kb. Desde un equipo malintencionado con un ancho de banda de 2 Mb se realiza el ataque. Equivale al choque frontal de un tren con un triciclo, o bien, y es lo más normal, uniendo multitud de pequeñas máquinas para saturar la conexión de red de la víctima. Con simples modems de 56 Kb se pueden saturar líneas de 60 Mb de una manera sencilla: puede basarse por ejemplo, en que el atacante convenza a los sistemas amplificadores para enviar tráfico de red a la víctima consiguiendo de esa manera con un simple módem el enviar a la víctima flujos de información de hasta 100 Mb (megas!!). No es difícil usar estas técnicas de amplificación. O bien basarse en sistemas “zombies”, miles, capturados previamente y en espera de ser despertados para organizar un ataque conjunto. En Internet se venden listas de miles de equipos conquistados y lo que es peor: alguien las compra, o puede comprarlas, cuando desea realizar uno de estos ataques.

– Inanición de recursos: Esta enfocado, en vez de a agotar el ancho de banda del sistema atacado, al consumo de los recursos del sistema, a la saturación de la CPU, memoria, lo que sea, hasta que la máquina se cae. Este tipo de ataque, generalmente provoca un fallo general del sistema, o que se llene un disco de log, o procesos que se cuelgan porque necesitan CPU que el sistema no le está proporcionando o se lo proporciona escasamente: y alguno de estos procesos puede ser crítico para el sistema.

– Errores de programación: Envío de datos “anormales”, que no cumplen las RFC (normas de definición del protocolo) al sistema objetivo: si la pila TCP/IP no es capaz de manejar estas excepciones y los programadores no han supuesto estos casos, terminará con la caída del sistema al ser en la capa de drivers que se ejecuta en RING 0 o RING 1 de la máquina. A veces no son defectos de programación: son defectos del hardware, defectos de algún chip, o defectos de la propia CPU. No está de más recordar el famoso defecto existente en algún Pentium (no voy a citar modelos presentes o pasados) por el cual un proceso, incluso en modo usuario sin privilegios, podía colgar a la CPU con algo tan simple como enviarle la instrucción 0xf00fc7c8 a la CPU.

– DNS y de enrutamiento. La mayoría de los protocolos de enrutamiento como RIP (Routing Information Protocol) o BGP (Border Gateway Protocol) carecen de autenticación, o tienen una muy sencilla. Se trata por tanto de un escenario perfecto para que cualquier atacante pueda alterar las rutas correctas y, falsificando su IP origen, crear una condición DoS. Las víctimas de estos ataques verán como su tráfico se dirige por ejemplo hacia un agujero negro: a una red que no existe.
Los ataques DoS sobre servidores de nombres de dominios (DNS) son tan problemáticos como los anteriores. Estos ataques intentan convencer al servidor DNS, por ejemplo, para almacenar direcciones falsas: cuando un servidor DNS realiza una búsqueda el atacante puede redireccionar a su propio servidor o bien a un “agujero negro”. En los últimos años se han sufrido varias veces ataques a alguno de los servidores “root” DNS de Internet colapsando media red y con tiempos de normalización superiores a las 48 horas.

Posibles medidas de prevención:

1. Establecimiento de contactos expeditos entre los distintos ISPs y grandes clientes: si bien el correo electrónico es una buena vía, en los momentos en que un ISP o cliente estén bajo ataques, resulta mejor otras vías de comunicación. Teléfonos de emergencia (con sus respectivos contactos) serían de gran utilidad. Una base de datos con los contactos entre los distintos ISPs sería conveniente. Además, como regla de buena práctica, los ISPs deberían proveer a sus clientes de los respectivos contactos de emergencia. Un contacto expedito entre los distintos administradores de DNS dentro del país también resultaría beneficioso.

2. Los ISPs deben filtrar el tráfico saliente (dentro de sus routers), que no provenga efectivamente de sus redes: un ataque DDoS basa su funcionamiento en generar tráfico con un origen falsificado. Si un ISP permite que dicho tráfico se genere dentro de sus clientes (sea por error, virus, gusano, mala intención, etc), se convierte en un proveedor contribuyente al ataque. Simples medidas, como la de filtrar cualquier tráfico que no provenga efectivamente de sus redes registradas, minimiza el riesgo de un DDoS anónimo. Al respecto existen un par de documentos con recomendaciones de seguridad que todo ISP debería tomar en consideración. Dichos documentos son los RFC (Request For Comments, por sus siglas en inglés; son los documentos estándares en la Internet) números 2827 y 3013:

3. Similarmente a lo anterior, los ISPs deben filtrar el tráfico proveniente de la Internet hacia sus clientes, cuando dicho tráfico no esté dirigido específicamente a ninguna de sus redes.

4. Los ISPs deben filtrar el trafico proveniente de la Internet, cuyas direcciones IPs fuentes provengan del rango de numeros IPs privadas.

Fuentes:
http://multingles.net/docs/jmt/ataques.htm
http://www.nic.cl/Board/2002-1/ataques.html

Los métodos más comunes de ataques a Servidores DNS ya han sidos nombrados así que iré a por otro que no daña el servicio o la información que éste proporciona, pero que puede utilizar esta información con fines malignos.

Footprinting mediante consulta de DNS

Los intrusos pueden lograr gran cantidad de información acerca de la infraestructura de la red simplemente interceptando los paquetes de DNS y así identificar sus posibles objetivos dentro de la red. Al capturar paquetes DNS se puede aprender acerca de el sistema de resolución de nombres, nombres de las máquinas de la red, y el esquema IP de la red. Esta información de red revela la funcionalidad de cada máquina, permitiendo decidir cuáles son los objetivos más fructíferos para el atacante y obtiener información sobre la forma de atacarlos.

Por lo tanto esta técnica revela vulnerabilidades o incluso hace más claro al atacante la forma de ser explotadas. Se podría denominar como una técnica de la fase de pre-ataque.

Una posible solución a este problema es encriptar el tráfico DNS mediante IPSec, que puede ser utilizado para proteger protocolos de la capa 4 del modelo OSI, incluyendo UDP que es el que interesa en este caso.

Referencias y ampliaciones:
http://en.wikipedia.org/wiki/Footprinting
http://www.creangel.com/drupal/?q=node/128
http://en.wikipedia.org/wiki/IPsec

Recapitulemos:
#1 (Alfonso) propone DNS Spoofing
#2 (Yolanda) propone DNS Inject
#3 (Juan) propone DNS Cache Poisoning
# 4 )I. Martínez) propone pharming
#5 (María José) propone DoS
#7 (Antonio) proporne DNS Footprinting
#8 (Victor) propone DDoS
#9 (Armando) proporne DNS ID Hacking
#11 (Samuel) los ataques que propones no son típicamente del DNS, aunque sí que le afectan
#12 (Victor M) correspondencia de red más DNS Footprinting
Existen acciones muy fáciles, no se aprovechan de errores del protocolo, pero sí de cómo éste funciona para obtener información de un posible objetivo y después…
Desde el punto de vista de la administración el objetivo es comprender cómo se puede usar esta información y actuemos en consecuencia cuando proporcionamos esta información.
¿A qué me refiero? Los Networks INformation Center (NIC) guardan información muy útil en los WHOIS: Nombres de contacto de la empresa, dominio, correos, teléfono de contacto,…
También, como hemos visto en clase, porque permitimos consultas o transferencias de zona a quien no se debe, con lo que todo esto puede conllevar.
Otro tipos de errores que pueden afectar al DNS son las vulnerabilidades de programación (existen documentadas en función de la versión de BIND)
A partir de ahora, ¿comentemos las propuestas realizadas? ¿Pensáis que con sólo DNSSEC se resuelven todos los problemas? ¿Qué problemas nos encontraríamos en la implantación de DNSSEC?
Intentemos resumir y que las respuestas no sean largas …

Buenas, he encontrado esta noticia sobre un ataque que tiene que ver con el tema del DNS.He copiado lo más importante; dejo el link de la página para mas información.

SAN FRANCISCO.-
La Oficina Federal de Investigaciones (FBI) estadounidense investiga el origen de un ataque a gran escala que afectó hace dos días a nueve de los 13 ordenadores que controlan el tráfico global de Internet, pero que duró sólo una hora y no tuvo graves consecuencias.

Las autoridades estadounidenses que investigan el incidente han descrito este ataque como “el mayor y más sofisticado en la historia de la Red”, a pesar de que la mayoría de los usuarios individuales no se percataron, ya que duró solamente una hora.

Estos 13 súper servidores están diseminados por el mundo, como una precaución contra un desastre físico (entre otros lugares, están en los estados de Maryland, Virginia, California y Texas, y en ciudades como Estocolmo o Tokio), lo que contribuyó a evitar que el incidente fuera a más.

Los expertos informáticos consideran que el Sistema de los Nombres de Dominio (DNS o “Domain Name System” en inglés) y los servidores en los que se apoya este sistema son el talón de Aquiles de la Red.

Unos 4.000 ataques de “denegación de servicio” ocurren cada semana como media, y la mayoría de ellos están dirigidos contra los servidores de DNS.

http://www.elmundo.es/navegante/2002/10/24/seguridad/1035450013.html

Según mencionan en ” http://ww2.grn.es/merce/2002/dns.html ” el problema que tiene dnssec es el mismo que tiene IPv6: el elevado coste que supone la migración de la tecnología convencional a la moderna (DNSSEC y IPv6). En cuanto a vulnerabilidades de DNSSEC no he encontrado nada hasta ahora.
Un saludo.

Buenas para empezar voy a poner un video que he encontrado bastante interesante con respecto a este tema:

Yo voy a hablar de “Ataque DNS ID Hacking”
El DNS ID Hacking no es una forma usual de hacking/spoofing o cualquier otro. Este método se basa en una vulnerabilidad en protocolo del DNS. Más eficaz, el DNS ID hack/spoof es muy eficiente y muy fuerte porque no hay generación de demonios de DNS que se escape de ella (incluso WinNT).
Paquete DNS.

Abajo se muestra el formato de un mensaje DNS:

+———————————+————————————–+
| ID | Banderas |
+———————————+————————————–+
| Número de preguntas | Número de respuestas |
+———————————+————————————–+
| Número de RR autoritarios | Número de RR suplementario |
+———————————+————————————–+
| |
\ \
\ PREGUNTA \
| |
+————————————————————————+
| |
\ \
\ RESPUESTA \
| |
+————————————————————————+
| |
\ \
\ Etc… NO IMPORTA \
| |
+————————————————————————+

1 ID: El ID permite identificar cada paquete DNS.
2 Banderas:[QR | opcode | AA| TC| RD| RA | zero | rcode ] –>QR: Si el bit QR = 0, significa que el paquete es una pregunta, si no es una respuesta.

DNS ID Hack/Spoof.

Ahora vamos a explicar claramente que es DNS ID hacking/spoofing. Como se explicó antes, la única manera para que el demonio DNS reconozca las diferentes preguntas/respuestas es la bandera en el paquete. Obsérvese este ejemplo:

ns.prueba.com;53 —–>[?www.pagina.com] ——> ns.pagina.com:53

Solamente tenemos que engañar la IP de ns.pagina.com y contestar información falsa antes de que ns.pagina.com lo haga a ns.prueba.com

ns.prueba.com > Oct 06 El 05:18:12 ADM named[1913 ]: db_free: DB_F_ACTIVE set – ABORT at this
time named daemon is out of order.

4. O podemos utilizar la vulnerabilidad en las versiones 8.1.x, 4.9.3, 4.9.5 y 4.9.6 de BIND descubierta por SNI (Secure Networks, Inc.) con la predicción del ID.