Archivo de la etiqueta: DNS

Evitar vulnerabilidad de Open DNS Resolver en nuestros servidores DNS

Se denomina como Open DNS Resolver a aquel servidor que resolverá cualquier petición recursiva de información sin importar el origen de la misma.

DNS logo

Fuente imagen: bleepingtech.com

El funcionamiento normal del protocolo DNS indica que si recibe una petición de un dominio que desconozca buscará dicha información (pidiéndosela a sus servidores DNS de referencia) y la entrega al cliente que la ha solicitado. Esto permite que cualquier ordenador pueda conectarse a cualquier sitio del mundo aunque no lo conozca previamente. El problema del Open DNS Resolver es que un tercero, que no tiene nada que ver con nuestra empresa, puede utilizar los recursos de nuestro servidor y nuestro ancho de banda para su propio beneficio. Ya no es sólo el mero hecho de asegurar la eficiencia del servicio al eliminar un uso externo ni previsto ni autorizado, sino que pueden utilizar nuestra infraestructura como parte de un ataque a un tercero e involucrarnos sin ni siquiera tener constancia de él.

Comparativa del tamaño relativo de una petición DNS válida y su respuesta

Comparativa del tamaño relativo de una petición DNS válida y la respuesta originada, que se envía a la víctima del ataque espejo. Fuente imagen: ArsTechnica

Los ataques de denegación de servicio mediante técnicas de espejo se basan en localizar la mayor cantidad de servicios no protegidos, a los que realizar peticiones aparentemente legítimas pero con la dirección IP originaría falseada por la de la víctima que quieren atacar. En nuestro caso un atacante solicitará la resolución de un nombre de dominio extraño, solicitando el máximo de información posible, de tal manera que la respuesta se envíe a la víctima. Este equipo víctima recibiría una gran cantidad de información desde diferentes fuentes de tal forma que sufriría un ataque DDoS. Si la víctima investiga el origen del atacante únicamente encontrará a los servidores DNS utilizados pero no el causante primario del ataque.

Cómo evitar tener un servidor Open DNS Resolver

Diagrama de un ataque de espejo

Diagrama de un ataque de espejo. Fuente imagen: Wikimedia

A continuación indicaremos las principales medidas de protección para que no nuestro sistema DNS no tenga esta debilidad y evitar así que se convierta en parte de un ataque DDoS en espejo:

  1. Deshabilitar la búsqueda recursiva. Tal cómo hemos indicado el propio funcionamiento del protocolo DNS hace que las búsquedas recursivas sean necesarias por lo que deshabilitarla no parece una opción práctica en la mayoría de situaciones. Quizás sí sea interesante si los servidores DNS públicos (aquellos que dan servicios a nuestras páginas web, sitios FTP, etc.) no son utilizados por nuestros trabajadores.
  2. Bloquear las peticiones externas. Al igual que en el caso anterior bloquear las peticiones externas, vía firewall o sistema similar, sólo sería útil si los servidores DNS son de uso interno exclusivo y son diferentes a los que dan servicio público.
  3. Limitar las peticiones de resolución con recursividad. La mayoría de sistemas DNS modernos permiten limitar desde qué redes es aceptable generar peticiones que incluyan resoluciones con recursividad. Así podemos configurar nuestro sistema DNS para que acepte las peticiones de las redes internas (las generadas por nuestros usuarios) mientras que descarte aquellas que provengan de redes externas que no controlemos. En la mayoría de empresas sería suficiente con indicar que sólo se permitan las direcciones IP de rangos privados.

Si bien las dos primeras opciones evitarían el uso de nuestros sistemas (tanto servidores, como anchos de banda, confiabilidad de nuestras direcciones IP, etc.) para formar parte de estos ataques es preferible configurar siempre las redes de confianza para realizar resoluciones con recursividad de tal forma que aunque debido a un fallo de configuración los servidores DNS quedarán expuestos a Internet tampoco pudieran usarse.

Exfiltración de información usando el protocolo DNS

Uno de los problemas con lo que se encuentra un usuario malintencionado (ya sea interno o un atacante externo) cuando obtiene información deseada es cómo sacarla sin que le descubran. En este artículo veremos algunas opciones para extraer esta información usando el servicio DNS, el cuál casi siempre está operativo en casi cualquier sistema.

Extracción de información mediante peticiones DNS

DNS logo

Fuente imagen: bleepingtech.com

Este sistema de extracción de información parte del supuesto de que un atacante ha conseguido infiltrarse en un sistema y necesita sacar la información obtenida para poder tratarla y utilizarla. Si la información a extraer no es muy grande puede realizar el siguiente montaje:

  1. El atacante monta en Internet un servidor DNS que publica la información sobre el dominio «malintencionado.es«. Es posible crear una web sencilla para dar apariencia de normalidad.
  2. Este servidor DNS responderá a todas la peticiones que reciba de forma normal, pero almacenará todos los subdominios solicitados de forma correlativa.

En este punto el usuario malintencionado ya dispone de un servidor DNS accesible públicamente y preparado para almacenar la información. Cuando un equipo realice una solicitud de resolución de nombre el sistema DNS de la corporación comprobará el dominio pedido «malintencionado.es» y entonces realizará una solicitud normal al servidor DNS malintencionado quien la registrará y contestará para pasar desapercibido.

Supongamos que el atacante se ha hecho con el fichero shadow de nuestro sistema Linux que tiene la siguiente información:

oracle:$6$MvOuttAz$5ZUMuRkx8b2kGJ/jQvTszUQz73R1G9wM78kh1SogNRnSNARUtH9YFbRX/E9iSkcokC4Djyo86DDj39Tq5ebw4/:15057:0:99999:7:::

Así pues a nuestro atacante le interesa enviar al exterior el nombre de usuario y el hash de la contraseña almacenado en este fichero. Una vez tenga esta información en su poder podrá intentar atacar este hash, mediante la técnica que prefiera, para obtener la contraseña válida. Veamos cómo se podría realizar esta extracción:

  1. El servidor infectado solicita las siguientes resoluciones en este mismo orden:
    1. USER.malintenciado.es
    2. oracle.malintenciado.es
    3. HASH.malintenciado.es
    4. $6$MvOuttAz$5ZUMuRkx8b2kGJ.malintencionado.es
    5. /jQvTszUQz73R1G9wM78kh1SogNRnSNARUtH9YFbRX.malintencionado.es
    6. /E9iSkcokC4Djyo86DDj39Tq5ebw4/.malintencionado.es
    7. EOF.malintencionado.es
  2. El servidor recompone la información y obtiene los datos enviados:
    • USERoracleHASH$6$MvOuttAz$5ZUMuRkx8b2kGJ/jQvTszUQz73R1G9wM78kh1SogNRnSNARUtH9YFbRX/E9iSkcokC4Djyo86DDj39Tq5ebw4/EOF

En este ejemplo se utilizan palabras claves para marcar los diferentes campos enviados ya que, aunque sea posible, será muy difícil que estas palabras claves coincidan dentro del resultado de la función resumen enviada. Con este formato se facilita el tratamiento automatizado en destino.

Defensas ante la extracción de información vía DNS

El primer paso para una coporación es obligar a que todos los servicios internos utilicen el sistema DNS corporativo. No hay razón alguna para que un servidor u ordenador de usuario pueda acceder a DNS externos. Toda conexión a un servidor DNS externo, que no provenga de nuestro propio sistema DNS corporativo, debe ser bloqueada a nivel de firewall.

Los sistemas IDS/IPS podrían detectar un repentino aumento de peticiones de resoluciones de un mismo dominio y generar un evento. Aunque lo más probable es que en estos casos el sistema nos informe de un posible escaneo de un dominio concreto y no de una posible exfiltración de información. Ante la aparición de un evento de estas características los administradores deberían revisar el servidor afectado en busca de la causa de ese supuesto escaneo pudiendo detectar la infiltración y cortarla.

Algunos servidores DNS pueden generar eventos cuando detectan que los tiempos de vida de las resoluciones son muy bajos. Generalmente un dominio de Internet se guarda en caché durante horas, por lo que si un servidor responde que sus dominios sólo deben cachearse durante pocos minutos podría considerarse un comportamiento anómalo (aunque sea perfectamente plausible según el protocolo). Este comportamiento (el reducir los tiempos de almacenamiento temporal) suele formar parte de los ataques DoS a los servidores DNS por lo que es algo que suelen tener en cuenta.

Como vemos la detección de este comportamiento depende en gran medida de la pericia del atacante (de la configuración del servidor DNS malicioso y de su prisa en sacar la información) y, además, los eventos suelen asociarse a otros tipos de ataques por lo que la detección real de este comportamiento es muy difícil.

Limitaciones de esta técnica de exfiltración

Esta técnica de exfiltración es muy lenta comparada con otras más habituales (conexión a webs externas, envío de correos electrónicos, subida a servidores SFTP, etc.) por lo que suele utilizarse cuando las anteriores han fallado. Los nombres de subdominios no pueden ser excesivamente largos ni contener caracteres extraños por lo que se limita la información a enviar. Así pues se trata de una técnica lenta, tanto por la cantidad de información enviada cada vez como para pasar desapercibidos antes los sistemas IDS/IPS.

Cabe indicar que si utilizamos el servicio DNS sobre UDP sería posible la pérdida de un paquete con lo que la información enviada no sería útil. El uso de conexiones TCP elimina este fallo pero facilita la detección de múltiples conexiones por parte de los sistemas de seguridad.

Envenenamiento de la memoria temporal del servidor DNS

En esta entrada veremos un tipo de ataque que busca redirigir a las víctimas a un servidor malicioso utilizando un ataque dirigido a sus servidores DNS (y no directamente a la víctima). La traducción al castellano de la expresión inglesa DNS cache poisoning vendría a ser envenenamiento de la memoria temporal del servidor DNS.

DNS logo

Fuente imagen: bleepingtech.com

Así, tal como su nombre indica, el atacante busca redirigir el tráfico de una víctima a servicios maliciosos de forma inadvertida usando para ello el sistema de resolución de nombres. Esta estrategia permite al atacante que los usuarios se conecten a un servicio malicioso que simula ser una web legítima (un banco, servicio de correo electrónico, etc.) de tal forma que cuando el usuario intenta acceder a su servicio en realidad está dando sus contraseñas al atacante.

Este ataque también permitiría a un atacante la gestión de un ataque de denegación de servicio (DoS) al impedir que los clientes que usen un servidor DNS concreto puedan llegar hasta el servicio atacado. Bastaría con proveer direcciones IP falsas de los nombres de dominio del servicio que se quiera atacar. Así el ataque DoS se limitaría a los usuarios que usen un determinado servidor DNS y no a toda la red en general: Si, por algún motivo, queremos que los usuarios de un operador telefónico concreto (Movistar, Vodafone, BritishTelecom, etc.) no accedan a un servicio concreto (Dropbox, PirateBay, Netflix, etc.) podríamos utilizar esta estrategia.

Funcionamiento del DNS cache poisoning

A continuación indicamos los pasos para realizar el ataque y cómo se aprovecha de las debilidades del protocolo DNS:

Funcionamiento del DNS cache poisoning.

Funcionamiento del DNS cache poisoning. Fuente imagen: NetworkWorld

  1. El atacante realiza a nuestro servidor DNS una solicitud recursiva para un dominio que es gestionado por un servidor DNS malicioso (loquesea.sitiomalicioso.com).
  2. Al ser una solicitud recursiva y no estar dentro de la memoria de nuestro servidor, éste busca el servidor propietario y resuelve el dominio solicitado.
  3. El servidor DNS malicioso no sólo le resuelve la solicitud inicial sino que, además, le envía información falseada de diferentes dominios legítimos (p.e. direcciones IP falsas para www.mibanco.com).
  4. Nuestro servidor guarda toda la nueva información en la memoria cache.
  5. Cuando un cliente legítimo quiere acceder a una página web (www.mibanco.com en nuestro ejemplo) realiza una consulta DNS normal.
  6. Nuestro servidor DNS consulta la memoria temporal y al ver que ya tiene almacenado ese dato le remite esa información falseada.
  7. El navegador del cliente se conecta a un sitio falseado, por lo que es posible que el atacante obtenga información del cliente (contraseñas, información privada, etc.).

Defensas frente al envenenamiento de memoria temporal en DNS

Veamos cuáles serían las defensas más prácticas frente a este tipo de ataque:

  • Si concienciamos al cliente (o le forzamos por políticas de empresa) a utilizar siempre que sea posible la navegación segura (https) este tipo de ataque fallaría  en el último punto ya que la página maliciosa no dispondría del certificado SSL de la web que intenta suplantar. Así el usuario se daría cuenta del problema por los avisos del navegador.
  • Aunque desactivar la memoria temporal DNS puede parecer una opción algo drástica, la verdad es que en instituciones pequeñas y medianas sería una estrategia factible.
  • Evitar la aceptación de volcado de información no solicitada por parte de nuestro servidor DNS. si nuestro DNS simplemente descarta la información extra (todo aquello que no estuviera en la consulta inicial – loquesea.sitiomalicioso.com en nuestro caso) no se sobrescribiría la memoria temporal. Esta estrategia puede hacer que nuestro sistema tarde más tiempo del habitual para actualizar los cambios legítimos que haya en los servicios web externos.
  • Configurar nuestro servidor DNS para que haga una consulta propia cada vez que recibe un volcado de información. Con esta estrategia el hecho de recibir un volcado de información haría que nuestro servidor consultase al servidor DNS legítimo la información y se actualizaría de una fuente oficial. Se trata de una solución que, aunque aumentando la carga de trabajo de nuestro servidor, permitiría mejorar los tiempos de actualizaciones legítimos mientras que evita este tipo de envenenamiento.
  • Activar DNSSec en nuestro servidor DNS permitiría detectar que el volcado de información no estaría correctamente firmado y por ello sería descartado. Esta opción requiere que el servidor DNS legítimo tenga también activadas las extensiones de seguridad.

Denegación de servicio contra servidores DNS

DNS logo

Fuente imagen: bleepingtech.com

El sistema DNS (Domain Name Service) es el que nos facilita a los humanos el uso de los servicios de Internet ya que sería casi imposible que recordásemos las direcciones IP de nuestras páginas web, sistemas de almacenamiento en la nube, portales de vídeos, etc. Así pues cualquier servicio de Internet que utilicen usuarios humanos depende, aún sin ser consciente, de este sistema de conversión de texto humano a direcciones IP.

Este sistema de nombre se creó en un momento en el que las comunicaciones eran caras y poco fiables, por lo que una de las características de este sistema es la gran permanencia de la información publicada. Esto hace que un ataque que busque una denegación de servicio contra DNS de un servicio concreto a base de eliminar su información registrada en el sistema deba ser continúo y durar más de 24 o 48 horas. La dificultad de mantener durante tanto tiempo estos ataques ha hecho que no sean prácticos para conseguir evitar que un servicio esté disponible para todos sus clientes. Por este motivo este tipo de ataques se suelen utilizar cuando queremos que un objetivo concreto no tenga conexión al exterior: anulando los servidores DNS a los que consulta una persona podemos hacer que, en la práctica, pierda su conexión a Internet (al menos para los humanos, ya que la conexión sigue estando habilitada).

En este artículo veremos algunos ataques DoS contra los propios servidores DNS y en una próxima entrada definiremos las protecciones y defensas básicas para anular, si es posible, estos ataques. Ademas hay una familia de ataques espejo en el que utilizando peticiones malformadas podemos conseguir que los propios servidores DNS dejen fuera de servicio una tercera víctima, pero estos ya merecen otro artículo.

Peticiones múltiples de dominios inexistentes

Se trata del tipo de ataque más básico que consiste simplemente en enviar solicitudes de información sobre dominios no existentes. Al recibir la petición el servidor consultará con sus servidores de referencia gastando recursos en el proceso (memoria, ciclos de CPU, ancho de banda…). El hecho de utilizar nombre de dominio inexistentes es porque, a diferencia de un dominio existente, al no obtener una respuesta afirmativa en la primera petición a su servidor de referencia realizará otra a un segundo servidor, y luego otra tercera, hasta agotar todos los servidores de referencia que ha aprendido previamente. Esto hace que una única consulta de un dominio no existente implique un mayor consumo de recursos que varias legítimas.

Si se hace de forma rápida es posible llenar la caché del servidor DNS víctima con dominios no existentes (NXDOMAIN) haciendo que cualquier petición legítima tenga un procesamiento más lento aún y acelerando la denegación de servicio a los clientes válidos de este servidor.

Ataque de dominios fantasma

Para este esquema el atacante crea un dominio real con un servidor DNS real especialmente configurado para responder de forma incorrecta: ya sea muy lentamente o con información parcial. Así cuando el atacante realiza consultas DNS a la víctima se asegura que las peticiones de información llegan a un equipo que él controla.

¿Qué pasa cuando un equipo responde, por TCP, de forma lenta? Pues que el receptor debe esperar, reservando recursos para ello, hasta que la transmisión finalice. ¿Qué pasa cuando un servidor envía la información de forma desordenada? Pues que el receptor debe esperar a recibir los diferentes paquetes para reordenarlos y obtener la información, lo cual implica reserva de recursos. ¿Y si el servidor pide retransmisiones de paquetes? Pues lo mismo: más reserva de recursos para almacenar información.

Realizando múltiples peticiones al servidor DNS víctima para que resuelva información contra el servidor DNS que nosotros controlamos podemos hacer que se quede sin recursos y provocar una denegación de servicio a todos los clientes que consultan a ese servidor.

Ataque basado en subdominios aleatorios

Gráfico de un ataque por subdominios

Ejemplo de ataque por subdominio. Fuente imagen: Incapsula

Este tipo de ataque es una evolución de los dos anteriores. La idea es solicitar una gran cantidad de subdominios inexistentes de un dominio concreto. Aunque es posible realizarlo contra un dominio inexistente (cosa que puede ser interesante para intentar burlar defensas contra el ataque anteriormente explicado) generalmente se realiza contra nombres de dominio existentes, ya sean controlados por el atacante (con lo que sería una evolución del ataque al dominio fantasma) o bien contra páginas conocidas que tengan gran capacidad de respuesta (de forma que se sature antes nuestro servidor víctima) como pudiera ser Google, Microsoft, Amazon, etc.

Aunque no es imprescindible, en la práctica, debido a las defensas de los propios servidores es necesario realizar este tipo de ataque desde una botnet. Cada miembro de una botnet, de forma coordinada, solicita la resolución de un subdominio aleatorio (asjdhaskd.yahho.com, jhsgdhafasd.microsoft.com, 8ajsdalNDBY.apache.org ,etc.) que no existirá forzando al servidor a reservar recursos para su infructuosa resolución.