fkasler/cuddlephishNavegador en el Medio (BitM) Armado para Probadores de Penetración
Browser-in-the-middle (BitM) multi-usuario armado para probadores de penetración. Este ataque puede usarse para eludir la autenticación multifactor en muchas aplicaciones web de alto valor. Incluso funciona para aplicaciones que no usan tokens de sesión y, por lo tanto, no serían explotables mediante ataques tradicionales de robo de tokens. Esta es una herramienta de ingeniería social y no explota ninguna falla técnica en el servicio objetivo.
Esta herramienta es un servidor web especializado. Está diseñada para ejecutarse en un servidor Linux Debian 11 (Bullseye) y depende de información de IP pública para proteger la funcionalidad de administración. No esperes poder probar localmente sin saltar algunos obstáculos serios.
Advertencia: Chromium no es compatible con ARM. Aunque técnicamente es posible forzar el uso de un binario ARM de Chromium, perderás todas las funciones/protecciones adicionales de puppeteer-extra.
Esta configuración de ejemplo utiliza Caddy para manejar TLS, SNI y agregar un par de encabezados personalizados como 'X-Real-IP' a cada solicitud. No tienes que usar Caddy con Cuddlephish, ya que el mismo proxy inverso se puede configurar usando Nginx, Apache, etc. Simplemente me gusta Caddy porque es fácil de instalar con Docker y tiene complementos para administrar certificados de Letsencrypt para la mayoría de los registradores de dominios. El Caddyfile de ejemplo muestra cómo lo configurarías para Gandi. Consulta la documentación de tu registrador.
Instala Docker, Node, XVFB y algunas otras dependencias:
git clone https://github.com/fkasler/cuddlephish
cd cuddlephish
sudo bash install_deps.sh
Luego puedes usar Docker para construir Caddy con un complemento de certificado comodín para tu registrador. El ejemplo es para Gandi. Consulta la documentación aquí y la lista de módulos de proveedores DNS aquí. Puedes modificar el Dockerfile para tu registrador antes de construir:
sudo docker build -t caddy .
Ahora modifica el Caddyfile para cambiar tu dominio y la clave API de Gandi (u otro registrador), e inicia Caddy. Recomiendo iniciar esto en una ventana de screen o tmux para que puedas ejecutar el servidor Node en otra ventana en un momento:
sudo docker run -p 80:80 -p 443:443 -p 2019:2019 -v $PWD/Caddyfile:/etc/caddy/Caddyfile --network=host caddy:latest
Con Caddy manejando el tráfico por nosotros en los puertos 80 y 443, ¡finalmente podemos ejecutar la herramienta!
Instala las dependencias de Node:
npm install
Algunos ajustes de configuración: PASO CRÍTICO: Asegúrate de modificar el config.json de ejemplo para agregar tus IP(s) públicas aprobadas para acceso de administrador. Esta lista blanca de IPs es lo que dicta el acceso a la interfaz web "/admin". También deberías cambiar la clave de socket predeterminada por algo más seguro.
La herramienta no está configurada para apuntar a ningún inicio de sesión de forma predeterminada, por lo que deberás agregar algunos. Hay un script 'add_target.js' para facilitar este paso. Simplemente ejecuta el script y pega la URL del portal de inicio de sesión que deseas apuntar cuando se te solicite:
node add_target.js
Esto obtendrá el nombre del servicio, el título de la pestaña y el favicon por ti y agregará una entrada a 'targets.json'. Puedes ejecutar este script varias veces y añadirá tus nuevos objetivos. El script nombrará cada servicio según el dominio, sin el nivel superior. Entonces, para 'https://www.example.com/login.php', el servicio sería solo 'example' al especificar tu objetivo cuando tú...
¡Ejecútalo!
node index.js example
Después de unos segundos, deberías ver un mensaje en la consola cuando tu primera instancia automatizada de Chrome se registre a través de websockets. Ahora los visitantes de tu sitio de phishing deberían ver lo que parece ser la página de inicio de sesión objetivo, pero en realidad es una transmisión de video de tu instancia de navegador automatizada. También pueden interactuar con tu instancia de navegador e iniciar sesión por ti.
Si configuraste correctamente tus IP(s) de administrador en config.json, deberías poder ver una interfaz web especial '/admin' para rastrear usuarios, ver registros clave, tomar el control de instancias de navegador conectadas, robar cookies y eliminar instancias de navegador no deseadas.
Nota: No verás nada en la página de administración hasta que tengas algunas víctimas. Una vez que tengas una víctima, su instancia de navegador debería aparecer en la interfaz de administración.
He tenido varias personas que abren problemas sobre una "Página Blanca en Blanco", que es más un síntoma de muchos problemas posibles, y no un problema en sí mismo. No abras problemas bajo nombres de síntomas vagos. En su lugar, si tienes una página en blanco en el lado del usuario, primero intenta revisar lo siguiente:
A alto nivel, si solo ves una página en blanco en el front-end, significa que hay una interrupción en la cadena de flujo de datos desde "Iniciar WebRTC" > "Seleccionar pestaña para transmitir" > "Negociar ICE con el navegador de la víctima" > "Transmitir video". Los pasos de solución de problemas anteriores están destinados a ayudarte a seguir los datos a través de este proceso. Cuando funcione correctamente, deberías ver un flujo de registros en el servidor similar al siguiente:
Espero que esto ayude con cualquier problema, y como siempre, tener suficiente información para replicar un problema de manera consistente es un requisito previo para enviar problemas para una investigación adicional.
Activa manualmente un payload para descargar en el sistema de la víctima a través de JavaScript. Cada objetivo comienza con 'payload.txt' como payload de prueba. Simplemente intercambia la ubicación del archivo en targets.json para enviar un payload personalizado.
Envía un cambio de window.location a la víctima para enviarla al portal de inicio de sesión real. Parecerá que simplemente están siendo obligados a reautenticarse y evitará que te vean tomar los controles. Si modificas el código, podrías hacer otras cosas elegantes con esta técnica general ;)
Te permite intervenir y tomar el control de una instancia de navegador directamente desde el portal de administración. Para dejar de controlar la instancia, presiona la tecla ESCAPE. Nota: esto quitará los controles a la víctima de phishing y podrá ver tus movimientos si no la expulsas primero. Has sido advertido.
Te permite devolver manualmente el control al usuario de la instancia de navegador automatizada. Esto podría ser útil para algunos escenarios de ingeniería social al hacerse pasar por TI. Puedes decirle al usuario que estás iniciando una sesión de ayuda, tomar el control y navegar al servicio objetivo, devolver el control y hacer que inicien sesión, tomar los controles nuevamente, etc.
Extrae todos los elementos de cookies y almacenamiento local de la instancia del navegador y lo descarga como un archivo JSON. Para inyectar este material de credenciales de nuevo en una instancia de navegador que se ejecuta en tu sistema local, hay un script en el proyecto llamado 'stealer.js'. Está diseñado para ejecutarse desde tu máquina, no desde el servidor, por lo que para usarlo también necesitarás instalar los componentes Node del proyecto en tu sistema.
node stealer.js ~/Downloads/cuddle_asdf1234.json
Mata una instancia de navegador cuando no la necesitas. A veces los usuarios no te inician sesión completamente. A veces la conexión WebRTC falla. A veces una sesión expira antes de que puedas usarla. En estos casos, este botón puede ayudarte a limpiar instancias de navegador inútiles a través del portal de administración.
Cada navegador se genera con su propio "browser id" aleatorio y un directorio de datos de usuario correspondiente en la carpeta "user_data" del proyecto. En algunos casos donde 'stealer.js' no funciona, es posible que también necesites replicar los datos de usuario para esa instancia. Esto puede ser útil en casos que apuntan a servicios con una función "recordar este navegador" dependiendo de cómo se implemente esa función.
También hay un keylog.txt en cada directorio de datos de usuario con un keylog completo del usuario víctima. El keylog general en el portal de administración intenta tener en cuenta cosas como las teclas de retroceso, mientras que este keylog.txt tendrá todas las pulsaciones de teclas registradas.
Ejemplo pm.json:
{
"tacking_id": "id",
"logging_endpoint": "https://www.phishmongerserver.com/create_event",
"admin_cookie": "admin_cookie=s3cret",
"post_url_search": "ppsecure"
}
Esta herramienta funciona emparejando a los visitantes del sitio de phishing con un navegador Chrome automatizado, que se ejecuta en el servidor de phishing. Luego, una transmisión de video de la instancia de Chrome controlada por el atacante se transmite a la víctima de phishing a través de WebRTC, y todos los movimientos del mouse y las entradas del teclado proporcionados por el usuario se reenvían desde el navegador de la víctima a su instancia de Chrome asociada. El servidor utiliza websockets para rastrear víctimas, emparejarlas con navegadores, intermediar transmisiones de video WebRTC y actuar como hombre en el medio en las entradas del usuario. Por cada nuevo visitante, el servidor genera una nueva instancia de Chrome. Debido a que usamos Chrome Devtools Protocol (CDP) para controlar cada instancia de Chrome, podemos usar APIs como "Storage.getCookie" para extraer cookies de sesión de los sitios objetivo una vez que el usuario ha iniciado sesión por nosotros. También podemos intervenir en cualquier momento y controlar directamente cada instancia de Chrome, aprovechando el mismo método que usamos para dar a las víctimas control remoto en primer lugar.
El servidor Node realiza lo siguiente:
Tengo entendido que esta técnica se ha teorizado e incluso armado durante varios años (ver agradecimientos). Por lo tanto, mientras que los actores de amenazas pueden aprovechar esta técnica, y probablemente lo han hecho durante algún tiempo, los profesionales de seguridad ofensiva no han tenido una forma fácil de replicar esta técnica y pueden incluso desconocer su existencia. Mi intención al publicar la herramienta es permitir que los probadores de penetración y los equipos rojos usen BitM en operaciones para mostrar su impacto potencial y ayudar a los defensores de la red a prepararse para amenazas reales.
Primero, entiende que este ataque depende de la ingeniería social para que un usuario visite un sitio web malicioso. La lista blanca de dominios sería de gran ayuda para prevenir este y otros tipos de ingeniería social. Si confiamos en que los usuarios gestionen el 100% de los datos de credenciales (contraseña, OTP, SMS, PhoneFactor, notificación push, etc.) para un servicio web, entonces somos potencialmente vulnerables a este ataque. Por lo tanto, para frustrar este ataque, necesitamos aprovechar datos de credenciales que los usuarios no gestionen. Por ejemplo, se pueden emitir certificados TLS de cliente a los dispositivos del cliente, y solo serán válidos para el servicio web real. El certificado es gestionado por el navegador y el sistema operativo, y no hay forma de que el servidor de un atacante obtenga una copia del certificado TLS de la víctima. Otra opción es usar U2F o FIDO2 con hardware como un YubiKey para gestionar algunos de los datos de credenciales requeridos. No hay forma de que el sitio web de un hacker interactúe con un YubiKey conectado a la computadora de una víctima.
No soy un experto en Docker (todavía). Si puedes idear una configuración simple con Docker, me encantaría recibir un pull request.
Es un juego de palabras con Cuttlefish (sepia), una criatura marina increíble que puede mimetizarse con su entorno, Phishing, porque requiere ingeniería social para realizar el ataque, y mal escrito intencionalmente para ser único, divertido y tonto. Me alegra pensar que este nombre de herramienta divertido se mencionará junto con hallazgos de riesgo crítico en informes de pentesting.
Aunque llegué a esta técnica e implementación de forma independiente, desde entonces he sabido que un par de otros investigadores me ganaron en el descubrimiento. Cada uno tomó un enfoque de usar clientes VNC basados en web para lograr un resultado similar. Es un enfoque intuitivo y podría ser aplicable para realizar ataques MitM contra otro software, no solo navegadores (¿VPN en el navegador tal vez?). Definitivamente vale la pena echarle un vistazo:
Franco Tommasi, Christian Catalano & Ivan Taurino https://link.springer.com/article/10.1007/s10207-021-00548-5
@mrd0x https://mrd0x.com/bypass-2fa-using-novnc/
También:
Agradecimiento a Daniel Aaron @majordmg por ayudar en las primeras etapas de la prueba de concepto de WebRTC.
Un enorme agradecimiento a RJ Stallkamp @Z3rO-C00L por arreglar y dar estilo a la interfaz de administración, y el nuevo logotipo genial.