Cómo los atacantes evitan la nueva identificación de dos factores y cómo proteger a tus usuarios

Preparar el ataque

Para ejecutar el ataque utilizaremos 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 será la página original con la que interactuará la víctima. Una vez que la víctima se haya autenticado en 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 simula que está interactuando con la página original. Pasarán por el proceso de autenticación regular, incluido el 2FA. Si el 2FA consiste en una contraseña de un solo uso (OTP) regular enviada por SMS, token de hardware o software, entonces la víctima la ingresará como de costumbre. Sin embargo, incluso los métodos modernos, como una notificación automática a un dispositivo móvil o el escaneo de un código QR en la pantalla, serán ignorados por este ataque.

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

En la imagen de abajo puedes ver a Muraena alojando a Google en el dominio phish.anti. Para fines de demostración, se configurará una DNS local para resolver esto en tu máquina de prueba y también emitir certificados utilizando tu propia CA, en la que confía el navegador. Sin embargo, esto es exactamente lo que se vería desde la perspectiva de la víctima si se implementara en tu propio dominio utilizando certificados válidos.

Protegiéndose contra el ataque

Ahora que entendemos cómo funciona el ataque, podemos identificar qué pasos serían necesarios 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. El enlace dinámico 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 ves es lo que firmas, porque el usuario final debe recibir 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 omitir para el atacante. Por lo general, el enlace dinámico se implementa a través de tokens de hardware, tokens de software o integrado como parte de una aplicación bancaria. A continuación, tenemos dos ejemplos de enlaces dinámicos, primero para un pago legítimo y el segundo cuando un atacante intenta modificar el pago.

1. El usuario crea una transacción en la banca online.
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 biometría (u otro segundo factor).
5. La aplicación móvil genera una contraseña de un solo uso (OTP) utilizando los detalles de la transacción y la clave de token dentro de la aplicación móvil.

1. El usuario intenta hacer un pago en la banca online.
2. El atacante modifica el pago para tener una nueva cuenta y/o cantidad de dinero.
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 implementar el enlace dinámico. Además, muestra que la aplicación móvil en sí misma debe estar protegida, ya que el atacante puede intentar atacar la aplicación para ocultar los detalles de pago modificados del usuario.

Otra forma efectiva de reconocer y defenderse contra una gran variedad de ataques es implementar un monitoreo continuo en tus plataformas digitales. Al monitorizar la sesión desde el momento del inicio hasta el final de la sesión, podemos poner mejor en contexto aquellas acciones de los usuarios y los dispositivos o cuentas con las que se asocian. La monitorización continua se combina perfectamente con otras capas, como 2FA o enlaces dinámicos, ya que también permiten al banco ponerse en contexto desde estos dispositivos de autenticación.

Luego el banco puede monitorizar los indicadores típicos de ataques conocidos, como nuevos dispositivos, ubicaciones, presencia de proxy u otros. Esta información se puede correlacionar a través de tu base de usuarios para comprender mejor el riesgo de estos elementos. Entonces también podemos tener en cuenta las operaciones que el usuario está realizando durante toda la sesión y comparar esto con su comportamiento habitual. Este enfoque establece un perfil de riesgo continuo para la sesión que puede cambiar con cada acción realizada por el usuario final. Esto no solo permite que el banco tome acciones automatizadas en tiempo real cuando se detectan anomalías, sino que también permite que el banco reduzca la fricción para las sesiones legítimas al reducir la cantidad de autenticaciones requeridas para sesiones reales.

Conclusión

Si bien el ataque en este artículo habla de tecnología y conceptos que han existido durante siglos, vemos que aplicarlos correctamente aún puede llevarnos a un gran éxito y luchar contra varios métodos de autenticación implementados hoy. Es importante que los bancos utilicen un enfoque por capas, ya que la mayoría de las capas individuales pueden ser atacadas o dinamitadas. Al implementar enlaces dinámicos, los bancos deben asegurarse de establecer una línea segura de comunicación con el usuario final. Por ejemplo, confiar en un SMS ya no es confiable, dado que los mensajes pueden ser robados, falsificados o interceptados por el atacante. Sin embargo, al implementar aplicaciones móviles, los bancos también deben ser conscientes de que estas aplicaciones se convierten en un objetivo y deben proteger sus aplicaciones móviles de ataques externos. El objetivo de este artículo es demostrar principalmente que los ataques de phishing se pueden modernizar para derrotar la autenticación de dos factores al iniciar sesión e implementar 2FA por sí solo no ofrece una protección completa contra el phishing. Finalmente, hemos mencionado algunas capas que los bancos pueden implementar para proporcionar una mayor protección a sus usuarios finales, así como también qué dificultades evitar al hacerlo. Para resumir:

• Implementa enlaces dinámicos con encriptación de extremo a extremo.
• Implementa análisis del lado del servidor para monitorizar las sesiones de los usuarios finales, los dispositivos y el comportamiento ante posibles ataques.
• Protege tus aplicaciones móviles del malware y otras amenazas externas.