Archivo por meses: enero 2017

Envenenamiento de la memoria temporal del servidor DNS

Deja un comentario

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.

DHCP snooping

2 respuestas

Se utiliza la expresión DHCP Snooping para definir una serie de técnicas que permiten asegurar que únicamente los servidores DHCP autorizados estén funcionando en una red.

Logo DHCP

Logo DHCP
Fuente imagen: IES Haría

El intento de hacer funcionar servidores DHCP no autorizados (DHCP Rogue) se conoce como DHCP Spoofing.

El servicio de DHCP (Dynamic Host Configuration Protocol)  es de uso casi imprescindible para cualquier red de uso común: permite que los equipos se unan a una red de forma automática y sin necesidad de configuración manual. Así ya no hace falta que un administrador de la red configure todos y cada uno de los equipos para poder trabajar. Su uso está tan extendido que muchas veces lo damos por supuesto: cuando llegamos a casa nuestro teléfono móvil se conectar a la red WiFi sin que tengamos que hacer nada (salvo poner la contraseña la primera vez) y nadie se pregunta porqué.

Porqué proteger el servicio DHCP

Como hemos visto el servicio DHCP permite la configuración de cualquier ordenador que se conecte a una red y parte de esa configuración suele ser la puerta por defecto y los servidores DNS que debe utilizar. Los ataques tipo Man-In-the-Middle buscan forzar que el tráfico legítimo pase por sus sistemas y una de las formas de hacerlos es precisamente engañando a los equipos para que usen sus servicios como puerta de enlace o sus DNS. Así si queremos asegurar que los equipos se conecten a nuestra red lo hagan con una configuración segura deberemos proteger el servicio DHCP para que únicamente funcione el sistema oficial y no sea posible crear un sistema falso.

Debilidades del funcionamiento DHCP

Antes de proteger nada, hay que revisar el funcionamiento básico del protocolo DHCP y cuáles son sus puntos débiles.

A grandes rasgos el funcionamiento de DHCP que permite que cualquier equipo se conecte de forma automática a una red sería:

  1. Un equipo se conecta a una red (bien porque se arranca un equipo apagado, bien porque conectamos nuestro móvil a una red Wifi, etc.)
  2. El equipo (cliente) envía un mensaje de difusión (broadcast), que llegará a todos los equipos de esa red, solicitando información sobre la propia red.
  3. El servidor DHCP (o el elemento delegado), y únicamente él, le responderá con un mensaje directo con la información de autoconfiguración que necesita para trabajar.
  4. El cliente configurará sus parámetros con la información recibida del servidor.
Ataque DHCP Spoofing

Ataque DHCP Spoofing
Fuente imagen: RSTUT

La petición del cliente se envía en modo difusión por lo que todos los equipos de la red detectan esa petición. Esto es necesario porqué el nuevo equipo no sabe cómo está montada la red, así que la única opción es enviar la petición de forma que todos los equipos la puedan recibir. el protocolo supone que únicamente responderá a la petición el servidor DHCP y el resto de equipos simplemente la ignorarán, pero ¿qué pasa si un equipo malicioso responde a esa petición? Pues que el nuevo cliente se autoconfigurará con los parámetros que le haya enviado dicho equipo malicioso (el cliente no conoce la red así que no puede saber a priori quién es el servidor DHCP). Esta técnica es conocida como DHCP Spoofing.

Motivos para el DHCP Spoofing

¿Para qué querríamos falsear los datos de configuración de los nuevos equipos que se conecten a la red? Estos son los principales usos de un DHCP spoofing:

  • Hacer creer a un nuevo equipo que nosotros somos su proxy de navegación: Así conseguiremos que el ordenador nos envíe su navegación web a nosotros que podremos analizarla.
  • Hacer creer al nuevo equipo que somos su puerta de enlace: Así todo el tráfico del equipo que salga de la red local pasará por nuestro equipo. Esta opción incluye más tráfico que no sólo el web.
  • Asignarle servidores DNS maliciosos: Podemos redirigir al usuario a nuestros servidores cuando el equipo solicite la resolución de nombre de dominio. Así el usuario creer estar entrando en su banco, cuenta de correo electrónico, etc. cuando en realidad lo está haciendo a una web falsa.
  • Asignación de prefijos telefónicos: Es posible propagar a los teléfonos IP un prefijo de llamada de tal forma que redirijan las llamadas salientes a una numeración especial que tenga un mayor coste.

Si bien las tres primeras opciones son las más habituales pero el protocolo define bastantes opciones de autoconfiguración que pueden ser falseadas con fines maliciosos.

Protección por DHCP Snooping

Como hemos visto el protocolo DHCP se pone en funcionamiento cuando un equipo se conecta a una red de la que desconoce cualquier tipo de información, por lo que no es posible delegar la seguridad del sistema en el cliente ya que simplemente no tiene información alguna de la red. Igualmente hemos visto que el tráfico de petición de información es, y debe ser, visible por toda la red por lo que cualquier equipo conectado a la red puede actuar de forma maliciosa, lo cual impide que deleguemos la seguridad del sistema en el propio servidor. Así pues la seguridad de DHCP queda en manos de los propios equipos de red (swithces y routers, principalmente).

Las diferentes técnicas de protección que componen el DHCP Snooping son las siguientes:

Funcionamiento de los puertos confiables.

Funcionamiento de los puertos confiables.
Fuente imagen: Cisco

  1. Definir, de forma fija y estática, cuáles son los servidores DHCP oficiales de la red. De esta forma cuando un equipo de red detecta tráfico del protocolo DHCP que no se ha originado en uno de los servidores oficiales puede descartarlo.
  2. Definir desde qué interfaces puede generarse tráfico DHCP. Podemos indicarle a los equipos de red, desde cuáles de sus interfaces son confiables y se puede recibir tráfico DHCP. De esta manera si el equipo detecta tráfico de dicho protocolo que se origina desde una posición no confiable puede descartarlo. Así si un equipo de usuario responde a una petición de DHCP el equipo de red más cercanos a él lo detecta y elimina dicho tráfico (y puede bloquear la toma de red, avisar al administrador, etc.).
  3. Delegación de DHCP. Es posible unificar la gestión del DHCP en un servicio externo que no esté dentro de la red local propia (p.e. empresas con diferentes oficinas interconectadas pero con el servicio centralizado en la sede central) de tal forma que los equipos de red descartarían cualquier paquete DHCP local.