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

Ben Balthazar, 4 de Febrero de 2020
How Attackers Bypass Modern Two-factor Authentication and How to Protect Your Users

En este artículo veremos un ejemplo de las herramientas y técnicas que los atacantes utilizan para eludir la mayoría de los métodos tradicionales de autenticación de dos factores (2FA), desde OTP a través de SMS hasta las notificaciones push cifradas para una aplicación móvil. El método de ataque puede ser muy eficaz contra la mayoría de los tipos de 2FA que se utilizan hoy en día, como la autenticación fuera de banda. También analizaremos qué tipo de contramedidas pueden aplicar los bancos para mitigar el riesgo de los ataques y proteger a sus clientes.

Configuración del ataque

Para ejecutar este ataque, usaremos una combinación de dos herramientas, Muraena y Necrobrowser. Muraena es un proxy inverso que ejecutará nuestra página de phishing. La página de phishing sustituirá a la página original con la que la víctima interactuará. Una vez que la víctima ha autenticado la sesión, Muraena entregará la sesión a Necrobrowser. Esto permite al atacante tomar el control de la sesión o automatizar los siguientes pasos del ataque. Como Muraena actúa como un proxy inverso, no habrá diferencia entre nuestro sitio malicioso y el sitio web original aparte de la URL. Muraena puede configurarse 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 habitual, que incluye la 2FA. Si la 2FA consta de una contraseña de un solo uso común y corriente que se envía a través de un SMS, un token de hardware o software, la víctima la ingresará como de costumbre. Este ataque incluso evitará los métodos modernos, como el envío de notificaciones push a un dispositivo móvil o el escaneo de códigos QR en la pantalla.

Ilustración del ataque de phishing de proxy inverso.

  1. El usuario visita la página de phishing, que tiene SSL activado.
  2. El proxy inverso (Muraena) busca la página legítima del banco y le entrega una copia a la víctima.
  3. La víctima intenta entrar en la página y se le pide 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, lo que hace que la víctima se desconecte.

En la imagen de abajo se puede ver cómo Muraena aloja a Google en el dominio phish.anti. Con el fin de demostrarlo, he configurado un DNS local para resolver esto en mi máquina de prueba y también he emitido certificados con mi propia CA, en la que confía el navegador. Sin embargo, esto es exactamente lo que parecería desde la perspectiva de la víctima si se implementara en su propio dominio con certificados válidos.

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

Protección contra el ataque

Ahora que entendemos cómo funciona el ataque, podemos determinar qué pasos serían eficaces para detectar este tipo de ataques o para protegerse contra ellos.

El enlace dinámico proporciona una buena primera capa de defensa contra una gran variedad de ataques. El enlace dinámico consta de una autenticación de dos factores que se realiza en el momento de la transacción y que incorpora los detalles en el proceso de firma. Suele denominarse “Lo que ves es lo que firmas”, porque al usuario final se le deben presentar los detalles de la transacción antes de completar el proceso de firma. Una vez que se firma, dicha firma solo será válida para esta transacción en particular, lo que hace más difícil que el atacante pueda eludirla. Por lo general, el enlace dinámico 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 enlace dinámico, 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 comprueba los detalles de la transferencia y autoriza el pago con un sistema biométrico (u otro segundo factor).
  5. La aplicación móvil genera una contraseña de un solo uso con los detalles de la transacción y la clave token de la misma 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 de modo que tenga otra cuenta de beneficiario u otro 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 utilizar el cifrado de extremo a extremo al aplicar el enlace dinámico. Además, demuestran que la aplicación móvil debe estar protegida, ya que el atacante quizás intente atacarla para ocultar al usuario los datos de pago modificados.

Otra forma eficaz de reconocer una gran variedad de ataques y defenderse de ellos es implementar un monitoreo continuo en sus plataformas digitales. Al monitorear la sesión desde el momento de su inicio hasta el final, podemos contextualizar más las acciones de los usuarios y los dispositivos o cuentas con los que se asocian. El monitoreo continuo se combina perfectamente con otras capas como la 2FA o el enlace dinámico, ya que permite al banco también obtener el contexto de estos dispositivos de autenticación.

Ejemplo de monitoreo continuo para comprender cada intento de operación, autenticación y resultado.

Así, el banco puede monitorear los indicadores habituales de ataques conocidos, como nuevos dispositivos, ubicaciones, presencia de proxy u otros. Esta información puede correlacionarse a través de su base de usuarios para comprender mejor el riesgo de estos elementos. Además, podemos tener en cuenta las operaciones que el usuario está realizando durante la sesión y compararlas con su comportamiento habitual. Este enfoque establece un perfil de riesgo continuo para la sesión que puede cambiar con cada acción que realice el usuario final. Esto no solo permite al banco tomar medidas automatizadas en tiempo real cuando se detectan anomalías, sino que también le permite disminuir la cantidad de autenticaciones necesarias para iniciar las sesiones auténticas y reducir los problemas de las sesiones legítimas.

Conclusión

Si bien el ataque en este artículo utiliza tecnología y conceptos que existen desde hace mucho tiempo, vemos que, si se aplican correctamente, se pueden lograr ataques satisfactorios y derrotar varios métodos de autenticación que se emplean hoy en día. Es importante que los bancos usen un enfoque por capas, ya que la mayoría de las capas individuales igual pueden atacarse o explotarse. Al implementar el enlace dinámico, los bancos deben cerciorarse de que establecen una línea de comunicación segura con el usuario final. Por ejemplo, recurrir a los SMS ya ha demostrado ser poco fiable, ya que el atacante puede robar, falsificar o interceptar los mensajes. Sin embargo, al implementar aplicaciones móviles, los bancos también deben ser conscientes de que estas se convierten en un objetivo y de que deben protegerlas de los ataques externos. El objetivo de este artículo es principalmente demostrar que los ataques de phishing pueden modernizarse con el fin de derrotar la autenticación de dos factores en el inicio de sesión y que la implementación de 2FA por sí sola no ofrece una protección completa contra el phishing. Por último, hemos mencionado algunas capas que los bancos pueden implementar para proporcionar una mayor protección a sus usuarios finales, además de las trampas que deben evitar al hacerlo. En resumen:

  • Implemente el enlace dinámico con cifrado de extremo a extremo.
  • Utilice el análisis del lado del servidor para monitorear las sesiones, los dispositivos y el comportamiento de los usuarios finales, y detectar posibles ataques.
  • Proteja sus aplicaciones móviles de malware y otras amenazas externas.
Libro electrónico

Fraude de robo de cuenta: cómo proteger a sus clientes y su negocio

Evite el fraude de robo de cuenta y proteja a los clientes en cada etapa de su viaje digital.

Descargar ahora

 

 

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