Archivo de la etiqueta: ataques

Podcast – 42 – R U Dead Yet?

R U Dead Yet?o simplemente R.U.D.Y. es una herramienta que busca la denegación de un servicio web a la página web a reservar recursos para una conexión absurdamente lenta. Mientras la mayoría de ataques de denegación de servicio se basan en el envío de una gran cantidad de conexiones rápidas para conseguir la saturación, RUDY utiliza un enfoque opuesto: ‘relativamente’ pocas conexiones de gran duración que lleguen a agotar los recursos del servidor al no permitirle liberarlos por mucho tiempo.

Esta herramienta tiene un funcionamiento muy sencillo que permite que cualquiera la utilice sin requerir conocimiento alguno: simplemente hay que indicarle la dirección de la web que queremos atacar y darle al botón y lanzamos el ataque. Debido a su funcionamiento cualquier web que tenga un formulario es susceptible de ser atacada mediante esta técnica.

Funcionamiento

Fuente imagen: Riverbed

Veamos cómo funciona esta herramienta:

  1. El programa R.U.D.Y. revisa la web indicada en busca de un formulario. Sirve cualquier formulario: uno sencillo de contacto es suficiente.
  2. Ahora la herramienta establece una primera conexión con un mensaje HTTP POST, pero indicándole al servidor destino que el tamaño del mensaje es muy grande (10,100MB, 20GB.). Esto hará que el servidor reserve espacio de memoria suficiente para recibir esta información tan voluminosa.
  3. Una vez establecida la primera conexión, ahora la herramienta empieza a enviar datos a una velocidad exageradamente lenta. Piensa que puede enviar un único byte por paquete a intervalos de aproximadamente 10 segundos.
  4. La herramienta seguirá enviando información lentamente y el servidor, al ir recibiendo actualizaciones, no cerrará la sesión pues creerá que se trata simplemente de un usuario con una mala conexión.

Si combinas múltiples sesiones de R.U.D.Y. es posible agotar los recursos del servidor atacado al llegar a saturar el espacio de memoria disponible o bien, más probablemente, el número de sesiones simultáneas que el servidor puede manejar. Así pues, si se combina un ataque R.U.D.Y desde varios orígenes, se puede obtener una denegación de servicio distribuida (o DDoS).

Protecciones

Al contrario que otros tipos de ataques de denegación de servicio, un ataque tipo R.U.D.Y es mucho más silencioso y sutil, por lo que es más difícil de detectar.

En las primeras versiones de la herramienta los paquetes se enviaban de forma continua cada 10 segundos, por lo que los sistemas IDS podían detectarlos con relativa facilidad, pero ahora mismo este envío de información se realiza de forma semialeatoria: a estos 10 segundos fijos se le añaden o restan un número aleatorio de segundos para evitar ser detectado por esta regla estática.

La forma más habitual para evitar este tipo de ataques es simplemente cerrar este tipo de conexiones tan lentas. Aunque esto hará que usuarios legítimos con conexiones muy lentas se verán impedidos de acceder a nuestro servicio web.

Otra defensa es el uso de proxys inversos que controlen y gestionen del tráfico de datos de tal forma que sean estos los que realicen las reservas de recursos para gestionar las conexiones lentas y no los propios servidores web.

Descarga directa.

Ataques Man-in-the-middle

Se denominan ataques Man-in-the-middle (cuya traducción al español podría ser «Ataques de intermediario»), que suelen acortarse usando las siglas como MiM o mitm, a una categoría de ataques que lo que buscan es que el atacante tenga la capacidad de leer, modificar los mensajes entre los dos interlocutores e incluso insertar sus propios mensajes en la comunicación. El gran peligro de este tipo de situaciones es que los dos interlocutores originales no saben que hay un elemento intermedio en su comunicación y que puede alterar la información a voluntad.

Ejemplo de MiM

Fuente imagen: Wikimedia Commons

El hecho de simplemente cifrar las comunicaciones entre los dos interlocutores no tiene porqué solventar esta situación. En la Wikipedia tenéis un ejemplo muy claro de cómo una un elemento intermedio (Mallory) puede interceptar la comunicación entre Allice y Bob aunque ambos creen estar en un entorno seguro y cifrado.

Aunque este comportamiento puede parecer teórico, en realidad no es difícil de detectar en el mundo real. Uno de las principales consejos de seguridad informática es que nunca conectemos nuestros equipos (portátiles, teléfonos móviles, etc.) a redes desconocidas ya estén abiertas o no. No es técnicamente difícil para un usuario malintencionado montar una red «Free-Wifi» en un espacio público permitiendo que los usuarios se conecten a ella. Una vez los usuarios se han conectado a dicha web basta con hacer que todo el tráfico saliente a Internet pase por nuestro equipo y convertirnos en Mallory. En este momento el atacante tiene acceso completo a la información que circula por la red, salvo que ésta vaya cifrada.

Defensas ante ataques Man-in-the-Middle

Pirata montando MiM

Un pirata montado un ataque MiM 🙂
Fuente imagen: Simmone Tocco

En la actualidad existen protocolos de comunicaciones que permiten un intercambios de claves de cifrado seguras aún usando un medio inseguro y sin tener un conocimiento previo entre los interlocutores: probablemente el protocolo de claves más utilizado sea Diffie-Hellman. Si las comunicaciones utilizan cifrado de clave pública sería suficiente con confirmar la autenticidad y propiedad de las claves intercambiadas con los sistemas de Certificate pinning.

Algunos estudios muestran la posibilidad de detectar la existencia de un sistema intermedio calculando la latencia en las comunicaciones cifradas. Se basan en que el trabajo de cifrado y descifrado de Mallory hace que las comunicaciones tenga una latencia mayor pero que dicha latencia sea casi constante (generada por el trabajo de descifrado, análisis y recifrado del punto intermedio). EL problema de este enfoque es que presupone un alto grado de estabilidad en la red que haga que la latencia no sufra fluctuaciones por el comportamiento normal de la red, por loq ue no sería aplicable en una red tipo Internet pero sí en entornos cerrados (redes corporativas, etc.).

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.