Cómo los atacantes evitan la autenticación de dos factores moderna y cómo proteger a sus usuarios

Ben Balthazar, 10 de Mayo de 2022

En este artículo veremos un ejemplo de las herramientas y técnicas que los atacantes pueden usar para eludir los métodos de autenticación de dos factores (2FA), desde SMS con códigos de contraseñas de un solo uso a notificaciones push cifradas a una aplicación móvil. El método para eludir 2FA no es simplemente un ataque de fuerza bruta y puede ser muy efectivo contra la mayoría de los tipos de métodos 2FA implementados en la actualidad, incluida la autenticación fuera de banda. Un administrador de contraseñas será de poca ayuda contra estos ataques, por lo que también analizaremos qué tipo de contramedidas pueden implementar los bancos para mitigar el riesgo y proteger a sus clientes de piratas informáticos y ciberdelincuentes, de fraudes de toma de control de cuentas, obtención de información confidencial, información que se utiliza para pedir un «rescate» o ataques de persona en el medio (también conocidos como man-in-the-middle o MITM en inglés).

Comprender la autenticación de dos factores

2FA no es solo una capa adicional de seguridad. Se refiere a un proceso de autenticación para cuentas en línea que incluye dos factores. Por otro lado, la autenticación multifactor (MFA) implica dos o más factores de autenticación. Los factores de autenticación incluyen algo que usted tiene (como un código de acceso único de seis dígitos), algo que sabe (como la contraseña del usuario, credenciales de usuario o preguntas de seguridad) o algo que usted es (como datos biométricos). En el proceso típico de código de verificación de 2 pasos, un usuario envía sus credenciales de inicio de sesión. Posteriormente, la aplicación web, aplicación móvil o herramienta envía un código de verificación o clave de seguridad a través de un mensaje de texto al número de teléfono del usuario. Luego, el usuario ingresa ese código 2FA en la página de inicio de sesión y se le da acceso a la cuenta de usuario o se completa la función de recuperación de cuenta o restablecimiento de contraseña. Alternativamente, estos códigos de verificación de dos pasos, códigos de seguridad y códigos de recuperación se pueden enviar a través de una aplicación de autenticación, un token de autenticación u otro sistema de autenticación.

Cómo eludir la verificación de contraseña de un solo uso: Configuración del ataque

Para ejecutar este ataque para eludir 2FA, usaremos una combinación de dos herramientas, Muraena y Necrobrowser. Muraena es un proxy inverso transparente que ejecutará nuestra página de phishing de ingeniería social. Los sitios de phishing y la página web representarán la página original con la que interactuará la víctima. Una vez que la víctima se haya autenticado para la sesión, Muraena entregará la sesión a Necrobrowser, lo que le permite al atacante tomar el control de la sesión o automatizar los próximos pasos del ataque. Debido a que Muraena actúa como un proxy inverso, no habrá diferencia entre nuestro sitio malicioso y el sitio web original, aparte de la URL. Muraena se puede configurar para usar SSL con certificados obtenidos a través de, por ejemplo, LetsEncrypt. Desde el punto de vista de la víctima, toda la experiencia parecerá legítima, ya que parece que están interactuando con la página genuina. Pasarán por el proceso de autenticación regular, incluida la 2FA. Si la 2FA consiste en un código de autenticación normal de contraseña de un solo uso a través de SMS, hardware o token de software, la víctima lo ingresará como de costumbre. Sin embargo, incluso las funciones de seguridad modernas, como una notificación automática a un dispositivo móvil o el escaneo de un código QR en la pantalla, serán eludidas por este ataque. 

 

Ilustración del ataque de phishing de proxy inverso.

  1. El usuario visita la página de phishing, que tiene habilitado SSL.
  2. El proxy inverso (Muraena) obtiene la página bancaria legítima y entrega una copia a la víctima.
  3. La víctima del ciberdelito intenta iniciar sesión en la página y se le solicita una autenticación de dos factores
  4. Una vez que la víctima ha completado el proceso de autenticación, el proxy inverso (Muraena) entrega la sesión al atacante (Necrobrowser) para que tome el control, dejando atrás a la víctima.

En la imagen a continuación, puede ver a Muraena alojando a Google en el dominio phish.anti. Con fines de demostración, configuré un DNS local para resolver esto en mi máquina de prueba y también emití certificados usando mi propia Autoridad Certificadora en la que confía el navegador. Sin embargo, esto es exactamente el aspecto que tendría desde la perspectiva de la víctima si se implementara en su propio dominio utilizando certificados válidos.

Captura de pantalla de Muraena haciendo proxy de google.com a phish.anti mediante SSL.

Ciberseguridad: protegerse contra el ataque

Ahora que entendemos cómo funciona el ataque, podemos identificar qué estrategias y funcionalidades de seguridad cibernética serían exitosas para identificar o protegerse contra este tipo de ataques.

El Enlace dinámico proporciona una buena primera capa de defensa contra una variedad de ataques. La vinculación dinámica consiste en una autenticación de dos factores realizada en el momento de la transacción, que incorpora los detalles de la transacción en el proceso de firma. A menudo llamado «Lo que ve es lo que firma», porque al usuario final se le deben presentar los detalles de la transacción antes de completar el proceso de firma. Una vez firmada, la firma solo debe ser válida para esta transacción específica, por lo que es más difícil de eludir para el atacante. Por lo general, la vinculación dinámica se implementa a través de tokens de hardware, tokens de software o se integra en una aplicación bancaria. A continuación, tenemos dos ejemplos de vinculación dinámica: el primero para un pago legítimo y el segundo donde un atacante intenta modificar el pago.

Ilustración del enlace dinámico en un pago legítimo.

  1. El usuario crea una transacción en la banca en línea.
  2. El usuario envía la transacción.
  3. El banco envía los detalles de la transacción al teléfono móvil del usuario.
  4. El usuario verifica los detalles de la transferencia y autoriza el pago con un biométrico (u otro segundo factor).
  5. La aplicación móvil genera una contraseña de un solo utilizando los detalles de la transacción y la clave del token dentro de la aplicación móvil.

Ilustración del enlace dinámico en el que un atacante intenta modificar el pago.

  1. El usuario intenta crear un pago en la banca en línea.
  2. El atacante modifica el pago para tener una nueva cuenta de beneficiario y/o monto.
  3. El banco envía los detalles de la transacción al teléfono móvil del usuario.
  4. Al usuario se le presenta la información de pago modificada y rechaza el pago.

Los ejemplos anteriores también ilustran la importancia de usar el cifrado de principio a fin al implementar enlaces dinámicos. Además, muestra que la aplicación móvil en sí debe ser protegida, ya que el atacante puede intentar atacar la aplicación en el punto final para ocultar al usuario los detalles de pago modificados.

Otra forma efectiva de reconocer y defenderse de una gran variedad de ataques es implementar monitoreo continuo en sus plataformas digitales como una capa adicional de seguridad. Al monitorear la sesión desde el momento del inicio hasta el final de la sesión, podemos brindar más contexto a través de las acciones de los usuarios y los dispositivos o cuentas Microsoft Android y Apple iOS con los que se asocian. El monitoreo continuo se combina a la perfección con otras capas, como 2FA o vinculación dinámica, ya que le permite al banco incorporar también el contexto de estos dispositivos de autenticación.

Example of continuous monitoring to understand each operation attempt, authentication and outcome.

Luego, el banco puede monitorear los indicadores típicos de ataques conocidos, como nuevos dispositivos, ubicaciones, presencia de proxies u otros. Esta información se puede comparar con los datos de su base de usuarios para comprender mejor el riesgo de estos elementos. También podemos tener en cuenta las operaciones que el usuario está realizando a lo largo de la sesión y compararlas con su comportamiento habitual. Este enfoque establece un perfil de riesgo constante para la sesión que puede cambiar con cada acción realizada por el usuario final. Esto no solo le permite al banco tomar acciones automatizadas en tiempo real cuando se detectan anomalías, sino que también le permite reducir la fricción para sesiones legítimas al reducir la cantidad de autenticaciones requeridas para sesiones genuinas.

Conclusión

Si bien los ataques para eludir la autenticación de dos factores en este artículo utilizan tecnología y conceptos que han existido durante años, vemos que aplicarlos correctamente aún puede conducir a un gran éxito y derrotar varios métodos de autenticación a día de hoy. Es importante que los bancos y los proveedores de servicios utilicen un enfoque en capas, ya que la mayoría de las capas individuales tienen vulnerabilidades que aún pueden ser atacadas o explotadas. Al implementar enlaces dinámicos, los bancos deben asegurarse de establecer una línea de comunicación segura con el usuario final. Confiar en la verificación de SMS, por ejemplo, ya ha demostrado ser poco confiable, ya que los mensajes pueden ser robados, falsificados o interceptados por atacantes. Sin embargo, al implementar aplicaciones móviles, los bancos también deben ser conscientes de que estas aplicaciones pueden convertirse en un objetivo y deben proteger sus aplicaciones móviles de ataques externos. El objetivo principal de este artículo es demostrar que los ataques de phishing se pueden modernizar para burlar la autenticación de dos factores al iniciar sesión, de modo la implementación de 2FA por sí sola no ofrece una protección completa contra el phishing. Finalmente, mencionamos algunas capas que los bancos pueden implementar para brindar mayor protección a sus usuarios finales, así como las trampas que deben evitar al hacerlo. Para resumir:

  • Implemente el enlace dinámico con cifrado de principio a fin.
  • Implemente análisis del lado del servidor para monitorear sesiones de usuario final, dispositivos y comportamientos relacionados con posibles ataques.
  • Proteja sus aplicaciones celulares de malware y otras amenazas externas. 

 

White-label Your B2C Agreement Processes to Prevent Phishing Attacks
Blog

Personalice sus procesos de acuerdo con sus consumidores con su propia marca para prevenir ataques de phishing

Esta personalización con su marca es lo primero que puede hacer para proteger su marca, generar confianza entre sus firmantes y lograr tasas de finalización muy altas.

Lea el post del blog

Ben Balthazar es consultor de fraude en OneSpan y ayuda a las instituciones financieras de Europa, Oriente Medio y Asia a defenderse del ciberdelito financiero. Ben comenzó su carrera con OneSpan en 2014 y se mudó de Bélgica a Dubai en 2016.