Ataque de intermediario

Ataque de intermediario , o ataque de hombre en el medio ( MITM) : un  tipo de ataque en criptografía y seguridad informática , cuando un atacante transmite en secreto y, si es necesario, cambia la conexión entre dos partes que creen que se están comunicando directamente entre sí con un amigo. Es un método de comprometer un canal de comunicación , en el que un atacante, habiéndose conectado a un canal entre contrapartes, interviene en el protocolo de transmisión, borrando o distorsionando la información.

Un ejemplo de un ataque man-in-the-middle es el espionaje activo, en el que el atacante establece vínculos independientes con las víctimas y transmite mensajes entre ellas. Al hacerlo, hace creer a las víctimas que están hablando directamente entre ellas a través de una conexión privada, de hecho, toda la conversación está controlada por el atacante. El atacante debe poder interceptar todos los mensajes transmitidos entre las dos víctimas, así como introducir otros nuevos. En la mayoría de los casos, esto es bastante simple: por ejemplo, un atacante puede comportarse como un "hombre en el medio" dentro del alcance de un punto de acceso inalámbrico ( Wi-Fi ) [1] .

Este ataque tiene como objetivo eludir la autenticación mutua, o la falta de ella, y solo puede tener éxito cuando un atacante tiene la capacidad de hacerse pasar por cada punto final o permanecer sin ser detectado como un host intermedio. La mayoría de los protocolos criptográficos incluyen alguna forma de autenticación de punto final específicamente para evitar ataques MITM. Por ejemplo, TLS puede autenticar a una o ambas partes mediante una autoridad de certificación de confianza mutua [2] .

Principio de ataque

El ataque generalmente comienza escuchando el canal de comunicación y termina cuando el criptoanalista intenta reemplazar el mensaje interceptado, extraer información útil de él y redirigirlo a algún recurso externo.

Supongamos que el objeto A planea enviar alguna información al objeto B. El objeto C tiene conocimiento sobre la estructura y las propiedades del método de transferencia de datos utilizado, así como el hecho de que la transferencia planificada de la información real que C planea interceptar. Para realizar un ataque, C “se presenta” al objeto A como B, y al objeto B como A. El objeto A, creyendo erróneamente que está enviando información a B, la envía al objeto C. El objeto C, habiendo recibido la información y al realizar algunas acciones con él (por ejemplo, copiar o modificar para sus propios fines), envía los datos al destinatario mismo - B; el objeto B, a su vez, cree que la información fue recibida por él directamente de A.

Ejemplos de ataques

Un ejemplo de un ataque en un lenguaje algorítmico

Supongamos que Alice quiere darle a Bob alguna información. Mallory quiere interceptar el mensaje y posiblemente cambiarlo para que Bob obtenga la información incorrecta.

Malory comienza su ataque estableciendo una conexión con Bob y Alice, mientras que ellos no pueden adivinar que alguien más está presente en su canal de comunicación. Todos los mensajes que envían Bob y Alice pasan por Mallory.

Alice le pide a Bob su clave pública . Malory se presenta a Alice como Bob y le envía su clave pública. Alice, creyendo que es la clave de Bob, encripta un mensaje con ella y se la envía a Bob. Mallory recibe el mensaje, lo descifra, luego lo modifica si es necesario, lo cifra con la clave pública de Bob y se lo envía. Bob recibe un mensaje y cree que proviene de Alice:

  1. Alice envía un mensaje a Bob, que Mallory intercepta: Alice “Hola Bob, soy Alice. Envíame tu clave pública". → Mallory Bob
  2. Malory reenvía el mensaje a Bob; Bob no puede adivinar que este mensaje no es de Alice: Alice Mallory "Hola Bob, soy Alice. Envíame tu clave pública". → Bob
  3. Bob envía su clave: Alice Mallory ← [La llave de Bob] Bob
  4. Malory reemplaza la llave de Bob con la de ella y le envía el mensaje a Alice: Alice ← [La llave de Malorie] Mallory Bob
  5. Alice cifra el mensaje con la clave de Mallory, creyendo que es la clave de Bob y que solo él puede descifrarla: Alice "¡Encuéntrame en la parada del autobús!" [cifrado con la clave de Mallory] → Mallory Bob
  6. Malory descifra el mensaje, lo lee, lo modifica, lo cifra con la clave de Bob y lo envía: Alice Mallory "Encuéntrame en la entrada del museo a las 18:00". [cifrado con la clave de Bob] → Bob
  7. Bob cree que este es el mensaje de Alice.

Este ejemplo demuestra la necesidad de usar métodos para verificar que ambas partes estén usando las claves públicas correctas, es decir, que la parte A tiene la clave pública de la parte B y la parte B tiene la clave pública de la parte A. en el medio".

Ataque al Protocolo Diffie-Hellman

Considere un ataque al protocolo secreto compartido Diffie-Hellman entre las partes A y B. Supongamos que el criptoanalista E tiene la capacidad no solo de interceptar mensajes, sino también de reemplazarlos por los suyos, es decir, de realizar un ataque activo:

Interceptación y sustitución de llaves

  1. Parte A envía un mensaje a Parte B :
  2. El criptoanalista E intercepta el mensaje de la parte A y lo reemplaza enviando otro mensaje a la parte B :
  3. La Parte B envía un mensaje a la Parte A :
  4. El criptoanalista E intercepta el mensaje de la parte B y lo reemplaza enviando a la parte A algún mensaje propio:
  5. El resultado de estas acciones es la formación de dos canales de comunicación entre el criptoanalista E y las partes A y B , y la parte A cree que se comunica con la parte B usando la clave secreta , y la parte B envía mensajes usando la clave . Al mismo tiempo, las partes A y B no sospechan que el intercambio de mensajes no se realiza directamente, sino a través del criptoanalista E :

Falsificación de mensajes

  1. La Parte A envía un mensaje a la Parte B encriptado con la clave :
  2. El criptoanalista E intercepta este mensaje, lo descifra con la clave , lo cambia a , si es necesario, lo cifra con la clave y lo envía a la parte B : :
  3. El criptoanalista E realiza acciones similares cuando envía mensajes de B a A.

Así, el criptoanalista E tiene la oportunidad de interceptar y reemplazar todos los mensajes en el canal de comunicación. Al mismo tiempo, si el contenido de los mensajes no permite revelar la presencia de un tercero en el canal de comunicación, entonces el ataque del “hombre en el medio” se considera exitoso.

Ataque de intermediario SSL

En este ejemplo, consideraremos un ataque a SSL sobre HTTP , también conocido como HTTPS, ya que este es el modelo de implementación más común para el protocolo SSL y se usa en casi todos los sistemas de aplicaciones de redes bancarias, servicios de correo electrónico para proporcionar un canal de comunicación. encriptación Esta tecnología está diseñada para garantizar la seguridad de que los datos no sean interceptados por terceros mediante un simple rastreador de paquetes.

Considere el proceso de comunicación a través de HTTPS usando el ejemplo de conectar un usuario a una cuenta de Google. Este proceso incluye varias operaciones separadas:

  1. El navegador del cliente accede a http://mail.google.com en el puerto 80 mediante HTTP.
  2. El servidor redirige la versión HTTPS del cliente de este sitio mediante la redirección del código HTTP 302.
  3. El cliente se conecta a https://mail.google.com en el puerto 443.
  4. El servidor presenta su certificado de clave pública al cliente para autenticar el sitio.
  5. El cliente verifica este certificado con su lista de CA de confianza.
  6. Se crea una conexión cifrada.

De todas estas acciones, la redirección a HTTPS a través de un código de respuesta HTTP 302 parece ser la más vulnerable.Para atacar el punto de transición de un canal inseguro a uno seguro, se creó una herramienta especial SSLStrip . Con esta herramienta, el proceso de ataque es el siguiente:

  1. Interceptación de tráfico entre el cliente y el servidor web.
  2. Cuando se encuentra una URL HTTPS, la herramienta SSLstrip la reemplaza con un enlace HTTP, igualando todos los cambios.
  3. La máquina atacante proporciona certificados al servidor web y se hace pasar por el cliente.
  4. El tráfico se recibe desde un sitio web seguro y se sirve al cliente.

Como resultado, el atacante obtiene acceso a los datos que el cliente envía al servidor. Estos datos pueden ser contraseñas de cuentas, números de tarjetas bancarias o cualquier otra información que normalmente se transmite de forma oculta. Una señal potencial de este ataque para el cliente puede ser la ausencia de una designación de tráfico HTTPS seguro en el navegador. Para el servidor, tal sustitución pasará completamente desapercibida, porque no hay cambios en el tráfico SSL.

Envenenamiento de caché ARP

La base del ataque ARP Cache Poisoning es una vulnerabilidad en el protocolo ARP . A diferencia de protocolos como DNS , que se pueden configurar para aceptar solo actualizaciones dinámicas seguras, los dispositivos que usan ARP recibirán actualizaciones en cualquier momento. Esta propiedad del protocolo ARP permite que cualquier dispositivo envíe un paquete de respuesta ARP a otro host para solicitarle que actualice su caché ARP. Enviar una respuesta ARP sin generar ninguna solicitud se conoce como enviar un ARP autodirigido. Si hay una intención maliciosa, los paquetes ARP auto-redireccionados bien dirigidos que se usan de esta manera pueden hacer que los nodos piensen que están hablando con un solo nodo, pero en realidad están hablando con el nodo interceptor de un atacante [3] .

Escenarios de ataque

Ataque a sistemas de clave pública

En el caso de un sistema de clave pública, un criptoanalista puede interceptar los mensajes de intercambio de clave pública entre el cliente y el servidor y modificarlos, como en el ejemplo anterior . Para no ser detectado, el criptoanalista debe interceptar todas las comunicaciones entre el cliente y el servidor y cifrarlas y descifrarlas con las claves adecuadas. Tales acciones pueden parecer demasiado complicadas para llevar a cabo un ataque, pero representan una amenaza real para las redes inseguras ( comercio electrónico , banca por Internet , pasarela de pago ) [4] .

Para evitar ataques a "una persona con un criptoanalista activo", que reemplazaría la clave pública del destinatario durante su transmisión al futuro remitente de los mensajes, por regla general, se utilizan certificados de clave pública .

Inyección de código malicioso

La inyección de código [5] en un ataque man-in-the-middle se usa principalmente para secuestrar una sesión ya autorizada, ejecutar comandos personalizados en el servidor y enviar respuestas falsas al cliente [6] .

Un ataque man-in-the-middle permite que un criptoanalista inyecte su código en correos electrónicos, declaraciones SQL y páginas web (es decir, permite la inyección SQL , la inyección HTML/script o los ataques XSS ), e incluso modificar los archivos binarios cargados por el usuario para para acceder a una cuenta de usuario o cambiar el comportamiento de un programa descargado por el usuario de Internet [6] .

Ataque de degradación

El término "ataque de degradación" se refiere a un ataque de este tipo en el que el criptoanalista obliga al usuario a utilizar funciones menos seguras, protocolos que aún se admiten por razones de compatibilidad. Este tipo de ataque se puede realizar sobre los protocolos SSH , IPsec y PPTP .

Para protegerse contra un ataque de degradación, los protocolos inseguros deben estar deshabilitados en al menos un lado; ¡Solo admitir y usar protocolos seguros de forma predeterminada no es suficiente!

Un atacante puede intentar cambiar los parámetros de conexión entre el servidor y el cliente cuando se establece una conexión entre ellos [6] . Según una charla en la Blackhat Conference Europe 2003, un criptoanalista puede "obligar" a un cliente a iniciar una sesión SSH1 cambiando el número de versión "1.99" de la sesión SSH a "1.51" en lugar de SSH2, lo que significa usar SSH V1 [ 7] . El protocolo SSH-1 tiene vulnerabilidades que un criptoanalista puede explotar. En este escenario de ataque, el criptoanalista engaña a su víctima haciéndole creer que una sesión IPsec no puede iniciarse en el otro extremo (servidor). Esto hace que los mensajes se reenvíen explícitamente si la máquina host está en modo de reversión [7] . En la etapa de negociación de los parámetros de la sesión PPTP , un atacante puede obligar a la víctima a usar una autenticación PAP menos segura , MSCHAP V1 (es decir, "retroceder" de MSCHAP V2 a la versión 1), o no usar el cifrado en absoluto. Un atacante puede obligar a su víctima a repetir la etapa de negociación de los parámetros de la sesión PPTP (enviar un paquete Terminate-Ack), robar la contraseña del túnel existente y repetir el ataque.

Comunicaciones Públicas

Los medios públicos de comunicación más comunes son las redes sociales, los servicios públicos de correo electrónico y los sistemas de mensajería instantánea. El propietario del recurso que proporciona el servicio de comunicaciones tiene control total sobre la información intercambiada por los corresponsales y, a su discreción, puede atacar al intermediario sin impedimento en cualquier momento.

A diferencia de los escenarios anteriores basados ​​en los aspectos técnicos y tecnológicos de las comunicaciones, en este caso el ataque se basa en aspectos mentales, es decir, en arraigar en la mente de los usuarios el concepto de ignorar los requisitos de seguridad de la información.

Detección de ataques MITM

Verificar el tiempo de retardo puede potencialmente detectar un ataque en ciertas situaciones [8] . Por ejemplo, con cálculos largos de funciones hash que se realizan en diez segundos. Para identificar posibles ataques, las partes verifican las discrepancias en el tiempo de respuesta. Suponga que dos partes suelen tardar una cierta cantidad de tiempo en completar una transacción en particular. Sin embargo, si una transacción tarda un período de tiempo anómalo en llegar a la otra parte, esto puede indicar la intervención de un tercero que introduce una demora adicional en la transacción.

Para detectar un ataque man-in-the-middle, también se debe analizar el tráfico de red. Por ejemplo, para detectar un ataque SSL, debe prestar atención a los siguientes parámetros [9] :

Implementaciones notables de ataques MITM

En 2003 , un enrutador de red inalámbrica de Belkin llevó a cabo un conocido ataque de intermediario no criptográfico . Periódicamente, un nuevo modelo de enrutador elegiría una conexión HTTP aleatoria y la redirigiría a la página de publicidad de su fabricante. Un comportamiento tan poco ceremonioso del dispositivo, por supuesto, causó un gran revuelo entre los usuarios, después de lo cual esta "característica" se eliminó de las versiones posteriores del firmware del enrutador [10] .

En 2011, una brecha de seguridad por parte de la autoridad de certificación holandesa DigiNotar condujo a la emisión fraudulenta de certificados . Posteriormente, se utilizaron certificados fraudulentos para realizar ataques man-in-the-middle.  

En 2013, se informó que Xpress Browser de Nokia descifraba el tráfico HTTPS  en los servidores proxy de Nokia, lo que le brindaba a la empresa acceso de texto sin cifrar al tráfico de navegador cifrado de sus clientes . A lo que Nokia afirmó que el contenido no se almacenaba de forma permanente y que la empresa contaba con medidas organizativas y técnicas para evitar el acceso a información privada [11] .

En 2017, Equifax retiró  sus aplicaciones para teléfonos móviles por temor a una vulnerabilidad de intermediario.

Otras implementaciones significativas de ataques MITM:

Los programas enumerados se pueden utilizar para llevar a cabo ataques man-in-the-middle, así como para detectarlos y probar el sistema en busca de vulnerabilidades .

Los errores en la configuración de enrutamiento de la interconexión de redes BGP [13] [14] se pueden utilizar para redirigir los flujos de tráfico .

Véase también

Otros ataques

Literatura

  1. ↑ Tanmay Patange. Cómo defenderse del ataque MITM o Man-in-the-middle (enlace descendente) (10 de noviembre de 2013). Consultado el 22 de noviembre de 2017. Archivado desde el original el 24 de noviembre de 2013. 
  2. ↑ Callegati, Franco; Cerroni, Walter; Ramilli, Marco. IEEE Xplore - Ataque Man-in-the-Middle al protocolo HTTPS  //  ieeexplore.ieee.org : journal. - 2009. - P. 78-81 .
  3. ↑ Comprensión de los ataques de intermediarios: envenenamiento de caché ARP . Fecha de acceso: 6 de diciembre de 2017. Archivado desde el original el 7 de diciembre de 2017.
  4. ↑ Criptosistema de clave pública
  5. ↑ Canal de seguridad de búsqueda de Techtarget: Ataques de inyección comunes . Archivado desde el original el 18 de febrero de 2012.
  6. ↑ 1 2 3 Alberto Ornaghi, Marco Valleri, "Man In The Middle Attacks", BlackHat Conference Europe 2003 . Archivado desde el original el 18 de febrero de 2012.
  7. ↑ 1 2 Alberto Ornaghi, Marco Valleri, "Man In The Middle Attacks Demos", BlackHat Conference Europe 2003 . Archivado desde el original el 18 de febrero de 2012.
  8. ↑ Aziz, Benjamín; Hamilton, Geoff. Detección de ataques man-in-the-middle en tiempo preciso.  (ing.)  // 2009 Tercera Conferencia Internacional sobre Información, Sistemas y Tecnologías de Seguridad Emergentes: revista. - 2009. - P. 81-86 .
  9. ↑ Análisis forense de red de ataques SSL MITM . Blog de seguridad de red de NETRESEC . Fecha de acceso: 27 de marzo de 2011. Archivado desde el original el 18 de febrero de 2012.
  10. ↑ Leyden, John . ¡Ayuda! mi enrutador Belkin me envía spam , The Register  (7 de noviembre de 2003). Archivado desde el original el 8 de agosto de 2011.
  11. ↑ Meyer, David Nokia: Sí, desciframos sus datos HTTPS, pero no se preocupe por eso . gigaom inc. (10 de enero de 2013). Consultado el 22 de noviembre de 2017. Archivado desde el original el 8 de abril de 2019.
  12. ↑ Goodin, Dan El error de suplantación de SSL todavía persigue a IE, Safari, Chrome; Gracias a Microsoft . The Register.co.uk (1 de octubre de 2009). Archivado desde el original el 18 de febrero de 2012.
  13. ↑ H Birge-Lee, Uso de BGP para adquirir certificados TLS falsos Archivado el 21 de julio de 2017 en Wayback Machine .
  14. ↑ Defending Against BGP Man-In-The-Middle Attacks Archivado el 25 de noviembre de 2017 en Wayback Machine // Black Hat DC, febrero de 2009

Enlaces