Evilginx2: Herramienta para ataques MITM que permite evadir incluso autenticación de dos factores

Evilginx

Evilginx es una herramienta de ataque para configurar páginas de phishing. En lugar de mostrar plantillas de páginas de inicio de sesión parecidas, Evilginx se convierte en un relevo entre el sitio web real y el usuario phishing . El usuario de Phishing interactúa con el sitio web real, mientras que Evilginx captura todos los datos que se transmiten entre las dos partes.

Evilginx, al ser el hombre en el medio, captura no solo nombres de usuario y contraseñas, sino que también captura tokens de autenticación enviados, como cookies. Los tokens de autenticación capturados permiten al atacante eludir cualquier forma de 2FA (autenticación de dos factores) habilitada en la cuenta del usuario (excepto U2F, más información al respecto más adelante).

Incluso si el usuario víctima de phishing tiene 2FA habilitado, el atacante, equipado solo con un dominio y un servidor VPS, puede tomar control remoto de su cuenta . No importa si 2FA está usando códigos de SMS, aplicación de autenticación móvil o claves de recuperación.

Eche un vistazo a la demostración en video, que muestra cómo los atacantes pueden hackear de forma remota una cuenta de Outlook con 2FA habilitado .

Descargo de responsabilidad: El proyecto Evilginx y todo lo que se realiza en Security Hack Labs se lanza con fines educativos y se debe usar solo en demostraciones o asignaciones legítimas de pruebas de penetración con el permiso por escrito de las partes que se convierten en phishing. El objetivo es mostrar que 2FA no es una panacea contra los intentos de phishing y las personas deben saber que sus cuentas pueden verse comprometidas, sin embargo, si no tienen cuidado.

· Viejas tácticas de phishing

Los ataques de phishing comunes, que vemos todos los días, son plantillas HTML, preparadas como parecidos a las páginas de inicio de sesión de los sitios web populares, atrayendo a las víctimas a revelar sus nombres de usuario y contraseñas. Cuando la víctima ingresa su nombre de usuario y contraseña, las credenciales se registran y el ataque se considera un éxito.

Aquí es donde ingresa 2FA. Si el usuario con phishing tiene 2FA habilitado en su cuenta, el atacante requerirá una forma adicional de autenticación, para complementar el nombre de usuario y la contraseña que interceptaron a través del phishing. Esa forma adicional de autenticación puede ser el código de SMS que llega a su dispositivo móvil, token TOTP, número de PIN o respuesta a una pregunta que solo el propietario de la cuenta sabría. El atacante que no tenga acceso a ninguno de estos nunca podrá autenticarse con éxito e iniciar sesión en la cuenta de la víctima.

Los viejos métodos de phishing que se centran exclusivamente en capturar nombres de usuario y contraseñas son completamente rechazados por 2FA.

· Phishing 2.0

¿Qué pasaría si fuera posible atraer a la víctima no solo para revelar su nombre de usuario y contraseña, sino también para proporcionar la respuesta a cualquier desafío 2FA que pueda surgir después de que se verifiquen las credenciales? Interceptar una sola respuesta 2FA no le haría ningún bien al atacante. El desafío cambiará con cada intento de inicio de sesión, haciendo que este enfoque sea inútil.

Después de cada inicio de sesión exitoso, el sitio web genera un token de autenticación para la sesión del usuario. Este token (o tokens múltiples) se envía al navegador web como una cookie y se guarda para su uso futuro. Desde ese punto, cada solicitud enviada desde el navegador al sitio web contendrá ese token de sesión, enviado como una cookie. Así es como los sitios web reconocen a los usuarios autenticados después de una autenticación exitosa. No piden a los usuarios que inicien sesión, cada vez que se vuelve a cargar la página.

Esta cookie de token de sesión es oro puro para el atacante . Si exporta cookies desde su navegador e las importa a un navegador diferente, en una computadora diferente, en un país diferente, estará autorizado y tendrá acceso completo a la cuenta, sin que se le pidan nombres de usuario, contraseñas o tokens 2FA.

Así es como se ve, en Evilginx 2, cuando la cookie token de sesión se captura exitosamente:

Sessiones

Ahora que sabemos cuán valiosa es la cookie de sesión, ¿cómo puede el atacante interceptarla remotamente, sin tener acceso físico a la computadora de la víctima?

Los ataques de phishing comunes se basan en la creación de plantillas HTML que toman su tiempo. La mayor parte del trabajo se dedica a que se vean bien, responden bien en dispositivos móviles o se ofuscan de forma adecuada para evadir los escáneres de detección de phishing.

Phishing

Evilginx lleva el ataque un paso más allá y, en lugar de publicar sus propias páginas HTML parecidas, se convierte en un proxy web. Cada paquete, procedente del navegador de la víctima, es interceptado, modificado y reenviado al sitio web real. Lo mismo sucede con los paquetes de respuesta, que provienen del sitio web; son interceptados, modificados y devueltos a la víctima. Con Evilginx no hay necesidad de crear sus propias plantillas HTML. En el lado de la víctima, todo parece estar comunicándose con el sitio web legítimo. El usuario no tiene ni idea de que Evilginx se sienta como un hombre en el medio , analizando cada paquete y registrando nombres de usuario, contraseñas y, por supuesto, cookies de sesión .

Puede preguntar ahora, ¿qué pasa con la conexión HTTPS encriptada que usa SSL/TLS que impide escuchar a escondidas los datos de comunicación? Buena pregunta. El problema es que la víctima solo está hablando, a través de HTTPS, al servidor Evilginx y no al verdadero sitio web en sí. Evilginx inicia su propia conexión HTTPS con la víctima (utilizando sus propios certificados SSL / TLS), recibe y descifra los paquetes, solo para actuar como un cliente y establecer su propia conexión HTTPS con el sitio web de destino, donde envía paquetes re-cifrados, como si fuera el navegador de la víctima en sí. Así es como se rompe la cadena de confianza y la víctima aún ve ese ícono de candado verde al lado de la barra de direcciones, en el navegador, pensando que todos están seguros.

Cuando la víctima ingresa las credenciales y se le pide que brinde una respuesta de desafío 2FA, todavía están hablando con el sitio web real, con Evilginx retransmitiendo los paquetes hacia adelante y hacia atrás, sentados en el medio. Incluso mientras es víctima de un ataque de phishing, la víctima seguirá recibiendo el código 2FA SMS en su teléfono móvil, ya que está hablando con el sitio web real (solo a través de un relevo).

Evilginx

Una vez que la víctima completa el desafío 2FA y el sitio web confirma su validez, el sitio web genera el token de sesión, que devuelve en forma de cookie. Esta cookie es interceptada por Evilginx y guardada. Evilginx determina que la autenticación fue un éxito y redirige a la víctima a cualquier URL con la que se configuró (documento en línea, video, etc.).

En este punto, el atacante tiene todas las llaves del castillo y puede usar la cuenta de la víctima, evitando por completo la protección 2FA, después de importar las cookies de token de sesión en su navegador web.

Tenga en cuenta que: cada página de inicio de sesión, que requiere que el usuario proporcione su contraseña, con cualquier forma de 2FA implementada, puede ser engañada utilizando esta técnica.

¿Cómo protegerse?

Hay una falla importante en esta técnica de phishing que cualquiera puede y debe explotar para protegerse: el atacante debe registrar su propio dominio.

Al registrar un dominio, el atacante intentará que se vea lo más similar posible al dominio real y legítimo. Por ejemplo, si el atacante tiene como objetivo Facebook (el dominio real es facebook.com), puede, por ejemplo, registrar un dominio faceboook.com o faceb00k.com, lo que maximiza las posibilidades de que las víctimas no vean la diferencia en la dirección URL del navegador.

Dicho eso, siempre verifique la legitimidad del dominio base del sitio web, visible en la barra de direcciones, si le pide que brinde información privada. Por dominio base quiero decir el que precede al dominio de nivel superior.

Phishing2

Como ejemplo, imagina que esta es la URL y el sitio web al que llegaste te pide que inicies sesión en Facebook:

https://en-gb.facebook.cdn.global.faceboook.com/login.php 

El dominio de nivel superior es .com y el dominio base sería la palabra anterior, con el siguiente . como un separador Combinado con TLD, eso sería faceboook.com. Cuando compruebe que faceboook.com no es el facebook.com real, sabrá que alguien está tratando de estafarlo.

Como nota al margen: el ícono del candado verde que se ve al lado de la URL, en la barra de direcciones del navegador, ¡no significa que esté seguro!

El ícono de bloqueo verde solo significa que el sitio web al que ha llegado encripta la transmisión entre usted y el servidor, de modo que nadie pueda espiar su comunicación. Los atacantes pueden obtener fácilmente certificados SSL/TLS para sus sitios de phishing y darle una falsa sensación de seguridad con la posibilidad de mostrar el ícono de bloqueo verde también.

Averiguar si el dominio base que ve es válido, a veces puede no ser fácil y deja espacio para el error. Se hizo aún más difícil con el apoyo de caracteres Unicode en nombres de dominio. Esto hizo posible que los atacantes registraran dominios con caracteres especiales (por ejemplo, en cirílico) que serían parecidos a sus contrapartes latinos. Esta técnica recibe el nombre de un ataque homógrafo.

Como ejemplo rápido, un atacante podría registrar un dominio facebooĸ.com , que se vería bastante convincente a pesar de que era un nombre de dominio completamente diferente ( ĸ no es realmente k ). ebаy.com aún más con otros caracteres cirílicos, lo que permite ebаy.com vs ebay.com. El primero tiene una contraparte cirílica para el carácter a, que se ve exactamente igual.

Los principales navegadores fueron rápidos para abordar el problema y agregaron filtros especiales para evitar que los nombres de dominio se muestren en Unicode, cuando se detectaron los caracteres sospechosos.

Si está interesado en cómo funciona, consulte el código fuente del filtro de suplantación IDN del navegador Chrome.

Ahora puede ver que la verificación visual de los dominios no siempre es la mejor solución, especialmente para las grandes compañías, donde a menudo solo se necesita un empleado para ser atacado y permitir que los atacantes roben grandes cantidades de datos .

Esta es la razón por la cual FIDO Alliance introdujo U2F ( Autenticación universal de segundo factor ) para permitir la autenticación de segundo factor no modificable.

En resumen, tiene una clave de hardware físico en la que solo presiona un botón cuando el sitio web lo solicite. Además, puede pedirte una contraseña de cuenta o un PIN complementario de 4 dígitos. El sitio web habla directamente con la llave de hardware conectada a su puerto USB, con el navegador web como el proveedor del canal para la comunicación.

U2F

Lo que es diferente con esta forma de autenticación, es que el protocolo U2F está diseñado para tomar el dominio del sitio web como uno de los componentes clave en la negociación del protocolo de enlace. Esto significa que si el dominio en la barra de direcciones del navegador no coincide con el dominio utilizado en la transmisión de datos entre el sitio web y el dispositivo U2F, la comunicación simplemente fallará. Esta solución no deja lugar al error y no se puede descifrar usando el método Evilginx.

Citando al proveedor de dispositivos U2F: Yubico (que co-desarrolló U2F con Google):

Con YubiKey, el inicio de sesión del usuario está vinculado al origen, lo que significa que solo el sitio real puede autenticarse con la clave. La autenticación fallará en el sitio falso, incluso si el usuario fue engañado al pensar que era real. Esto mitiga en gran medida el aumento del volumen y la sofisticación de los ataques de phishing y detiene la adquisición de cuentas.

Es importante señalar aquí que Markus Vervier (@marver) y Michele Orrù (@antisnatchor) sí demostraron una técnica sobre cómo un atacante puede atacar dispositivos U2F usando la función WebUSB recientemente implementada en los navegadores modernos (que permite que los sitios web hablen con USB conectado dispositivos). También es importante mencionar que Yubico, el creador de los populares dispositivos U2F YubiKeys, intentó robar el crédito por su investigación, y luego se disculparon.

Puede encontrar la lista de todos los sitios web compatibles con la autenticación U2F aquí.

Coincidiendo con el lanzamiento de Evilginx 2, WebAuthn está saliendo en todos los principales navegadores web. Introducirá el nuevo estándar de autenticación sin contraseña FIDO2 para cada navegador. Chrome, Firefox y Edge están a punto de recibir un soporte completo.

Para concluir: si a menudo necesita iniciar sesión en varios servicios, ¡haga su vida más fácil y obtenga un dispositivo U2F! Esto mejorará en gran medida la seguridad de sus cuentas.

· Instalación de Evilginx2

Para realizar la instalación solo basta con ejecutar unos cuantos comandos. Los comandos a continuación son válidos para ArchLinux pero probablemente funcione con todas las demás distribuciones.

#Instalación de dependencias
pacman --needed -Syu go dep git

#Descarga de evilginx2
go get -u github.com/kgretzky/evilginx2

#Compilación de evilginx2
cd $HOME/go/src/github.com/kgretzky/evilginx2
make

· Ejecución de evilginx2

Solo basta con ejecutar en nuestra terminal lo siguiente, estando en el último directorio de la instalación:

sudo ./bin/evilginx -p ./phishlets/

Fuentes:

https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens/

https://github.com/kgretzky/evilginx2

Síguenos en FacebookTwitterunete a nuestro chat en Matrix y no olvides compartirnos en las redes sociales. También puede hacernos una donación o comprar nuestros servicios.

Acerca del autor

Especialista en Seguridad Informática bajo certificación OSCP, experto en técnicas de privacidad y seguridad en la red, desarrollador back-end, miembro de la FSF y Fundador de Security Hack Labs. Desarrollador de la distribución de hacking BlackArch Linux. Twitter: @edu4rdshl XMPP/Email: [email protected]