Archivo de la categoría: Definiciones

Diferentes definiciones relativas a los sistemas de ciberseguridad

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.).

WAF – Web Application Firewall

Un Web Application Firewall (WAF) es un sistema que analiza, filtra y bloquea el tráfico del protocolo HTTP que gestionan los servicios web. A pesar de incluir el término firewall en su nombre, podemos decir que los WAF son más bien una evolución de los IDS/IPS generalistas para cubrir específicamente la protección de los sistemas web. Los WAF analizan el tráfico el tráfico que capturan, no sólo por las direcciones IP y puertos, que es lo que haría un firewall; sino también por el contenido de las peticiones y respuestas transmitidas. Así el sistema trata de detectar diferentes patrones de ataques a servicios web (Inyecciones SQL, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), etc.).

WAF

Montaje tradicional de un sistema WAF. Fuente imagen: Terminatio

Si bien las funciones que realiza un sistema WAF puede ser realizadas por los IPS tradicionales correctamente configurados, el gran desarrollo en los últimos años de las aplicaciones web ha hecho que sean cada vez un objetivo más goloso para los usuarios malintencionados y ha propiciado la creación de una herramienta específica para su protección.

Tal como se muestra en la imagen superior, aunque podríamos conectar el sistema WAF de forma independiente, generalmente se utiliza como una segunda capa de protección: un firewall tradicional bloquear todo el tráfico que no sea HTTP de manera que el sistema WAF sólo deba analizar y gestionar el tráfico web. Esta doble capa de seguridad permite que cada una de ellas sea más eficiente y genere el mínimo retraso posible en la comunicación. La actuación de un IDS/IPS, categoría dentro de la que cabría enmarcar los WAF, implica el análisis del tráfico capturado antes de decidir si darle paso o bloquearlo por lo que siempre habrá una latencia añadida al sistema. Para evitar que los usuarios noten esta latencia es importante que los WAF sólo deban analizar el tráfico que realmente tenga como destino las páginas web que protegen. Un sistema WAF en solitario es posible y funcional, pero no sería eficiente de cara al rendimiento de la aplicación web (que, al fin y al cabo, es lo que el usuario final nota).

Otra de las ventajas de los WAF frente a los IPS tradicionales son que, debido a su especificidad en la protección, incorporan herramientas específicas y adaptables a casi cualquier entorno web. Así es posible crear reglas específicas de protección para cada aplicación, con lo que al final se consigue un sistema de protección totalmente adaptado a las necesidades de cada cliente. Se trata de un cambio de paradigma de buscar ataques o vulnerabilidades conocidos por parte de un IPS a proteger específicamente nuestra web con sus peculiaridades específicas.

Esquema de un WAF Cloud

Diagrama de un WAF en la nube. Fuente imagen: CDNetworks

Debido a la expansión de los servicios ‘en la nube’, muchos sistemas de seguridad que se crearon pensando en las estructuras tradicionales (cliente <> protección <> servicio) han debido integrarse también como servicios ofrecidos en la nube para poder mantener el mismo nivel de protección.


Como nota curiosa si buscáis por Internet WAF es posible que os encontréis con el Wife Acceptance Factor, que poco tiene que ver con la seguridad informática 😉

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.