EL PHISHING DEL SIGLO XXI

Categorías: ,
Etiquetas: , , ,

Todo gracias a @kgrenzy y @TomAbel.

Todos hemos visto en numerosas ocasiones cómo hacer un phishing desde direcciones maliciosas o locales en las que se nos presenta una web o una dirección del tipo 192.168.0.0/24. Hoy en día los navegadores, cuando introducimos una password en un sitio no seguro (sin certificado SSL), alertan que los datos no son seguros y que pueden ser vistos por equipos ajenos. Así que hoy en día hacer un intento de robo de contraseñas se ha complicado un poco y hay que ser más fino.

Por otro lado, cuando alguien obtiene una contraseña de una red social o correo electrónico de las grandes empresas como Microsoft, Google, Yahoo, etc. … Cuando esta ha sido vinculada a un terminal móvil con su propia aplicación, con los valores por defecto nos puede servir como segundo factor de autenticación en el caso de que se detecte que es un equipo nuevo el que intenta acceder a la cuenta. Es por eso que aunque un actor obtenga una dirección de gmail y su contraseña, lo normal  es que no pueda acceder a la misma desde ubicaciones ni equipos diferentes a los utilizados legítimamente por el cliente.

Es por esos motivos que el phishing tenía que dar un paso más y evolucionar para poder seguir engañando al usuario y acceder al contenido personal de estos.

El camino que se ha seguido para que este tipo de ataque sea posible es el de los proxys reversos.

Todos seguramente hemos oído hablar de los proxys, pero voy a intentar dar un repaso rápido de lo que es y para qué lo usamos. Normalmente nos sirve para que sea otro equipo (el proxy) el que visita una página web en nuestro lugar y nos la sirve, haciendo este servidor proxy de puente entre el servidor web final y el cliente, es decir, nosotros mismos. Este era un método común para evitar restricciones por localización o utilizar servicios con IP’s diferentes a la propia. Otro uso, seguramente más extendido, es el de restricción de contenidos o control de accesos cuando estos servidores están dentro de nuestra propia red. Pero lo que me gustaría que tuviéramos en mente, es que un solo equipo podría acceder a cualquier web a través del puente que le facilita el servidor proxy, y que sería éste el que hace la visita al contenido por nosotros, y “luego” nos la muestra. Hay que apuntar, que una vez configurado el navegador para usar un proxy, para el usuario será transparente y no tiene porqué ser consciente de que lo está usando ya que los nombres de dominio serían los legítimos.

Entendiendo someramente lo que es un proxy transparente, vamos a poder entender mejor qué es un proxy reverso.

El proxy reverso lo que va a conseguir es visitar una pagina/servicio predeterminado por su propia configuración haciendo de puente entre los clientes  y el servicio final. De esta forma si tenemos un servicio (A.com) , y un Proxy inverso (B.es) que apunta a A.com, cuando visitemos el servicio B.es, éste visitara por nosotros A.com, sin informarnos de nada más, ni configurar nada en nuestros dispositivos, como sí que tendríamos que hacer en el proxy transparente convencional del que todos hemos oído hablar. De este modo, cuando nosotros accedemos a la web pruebas.com que se aloja en la IP 12.34.56.78 y es lo que visita nuestro navegador, este proxy lo que puede estar haciendo en realidad, es acceder a un servicio propio en otra dirección 87.65.43.21 por nosotros. Esto se puede usar por diferentes motivos, como por ejemplo, evitar que se puedan hacer consultas a determinados servicios de un servidor desde algunas IP’s o desde todas menos desde la del proxy reverso. Hay infinidad de situaciones y motivos por las que se utiliza este tipo de proxy inverso sin que el usuario sea consciente de que lo está usando. Tampoco puedo extenderme más por que no soy ningún experto, pero quizá esto os valga para haceros una composición de lugar y entender por que el proxy inverso es la solución para que los 2FA y los usuarios y password pierdan valor en el robo de cuentas personales a día de hoy.

phishing sh3llcon.org

Foto de https://www.blai.blog/

Una vez entendido como funciona el asunto, vamos a ver cómo comprobar que estos tipos de ataque son factibles.

Desde 2019 han proliferado las herramientas que facilitan este tipo de pruebas, Muraena , Modlishka , o Evilginx2.

Por su facilidad de uso y por ser quizá la más utilizada, para estas pruebas vamos a mostrar Evilginx2.

Para llevar a cabo la prueba de la forma más real posible necesitaremos un dominio.

Por ejemplo en **nos.es podemos contratar un dominio de prueba y trastear un ratito sin hacer daño a nadie.

Apuntaremos los registros tipo A, a nuestro servidor/maquina. Tenemos que tener presente que nuestra maquina tiene que ser accesible a los puertos 80,443 y 53 para no tener fallos en la instalación y configuración ya que son los que usara la tool.

A ejemplo.com nuestra_ip

A *.ejemplo.com nuestra_ip

Ya tenemos el dominio y subdominios apuntando a nuestra máquina, ahora tendremos que introducir el registros TXT, para eso una forma fácil es usar certbot (apt-get install certbot).

certbot certonly –manual -d *.ejemplo.com -d ejemplo.com –agree-tos –manual-public-ip-logging-ok –preferred-challenges dns-01 –server https://acme-v02.api.letsencrypt.org/directory

phishing sh3llcon.org

El resultado de este comando lo introducimos en nuestro dominio como tipo de registro TXT y el subdominio que nos refleja el output de este comando.

La instalación de la herramienta es fácil, conforme explican en su README:

sudo apt-get -y install git make
git clone https://github.com/kgretzky/evilginx2.git
cd evilginx2
make
make install
evilginx
phishing sh3llcon.org

Por defecto nos cargará las plantillas, denominadas phishlets, que nos permitirán probar diferentes cuentas como las de Twitter, Facebook, Instagram, etc.

Configuramos el dominio que hemos registrado y la IP pública de nuestra propia maquina:

config domain ejemplo.com
config ip 12.34.56.78

Lo siguiente sería configurar la plantilla (phishlet) que vamos a emplear y crear la url (lures) desde la que accederemos al proxy reverso y su ataque:

phishing sh3llcon.org

Por ultimo habilitamos la plantilla y obtenemos el enlace:

phishlet enable nombre_plantilla
lures get-url 0
phishing sh3llcon.org

Donde 0 será la ID de nuestro lure. Cada uno de los “lures” es personalizable, con diferentes url o imágenes para que se carguen al compartir el enlace con los diferentes parámetros que nos facilita la herramienta desde la opción.

lures edit numero_ID

Solo nos queda hacer llegar el enlace de una forma u otra al cliente víctima y esperar a que acceda.

phishing sh3llcon.org
phishing sh3llcon.org
phishing sh3llcon.org
phishing sh3llcon.org

Como podéis ver son los pasos clásicos que se repiten cuando hacemos login desde un nuevo dispositivo, pero los datos que nos da durante el login parecen legítimos, ya que la herramienta utiliza nuestro user agent para visitar la página del servicio.

Mientras se suceden los pasos de login en nuestra consola podemos ver los resultados. Usuario, password y cuando finaliza el proceso, las famosas cookies, que es lo que se andaba buscando realmente.

phishing sh3llcon.org
phishing sh3llcon.org

Para obtener los resultados escribiremos el comando:

sessions

Esto nos muestra todos los logins o intentos de login que se hayan llevado a cabo y solo con poner a continuación la ID nos mostrará el detalle de la captura.

Para finalizar copiaremos las cookies y las importaremos a cualquier navegador con extensiones como cookie-editor y podremos acceder al correo, historial o lo que sea que nos interese para corroborar el éxito del ataque.

En resumen, lo que ha pasado es que ha sido la maquina maliciosa la que ha hecho el login en lugar de la víctima, si el usuario no detecta que el nombre de dominio no es el original puede ser víctima de este tipo de ataque. Pero lo que está claro es que no nos podemos fiar de cualquier web que tenga  su candadito verde, y que el segundo factor de autentificación no es infalible si el usuario final está siendo engañado. 

Para siguientes entregas veremos cómo los actores maliciosos pueden hacer llegar este tipo de enlace a sus víctimas. Un saludo, nos vemos en Santander en la próxima edición de SH3LLCON

KubaFan

Sh3llCON no se hace responsable de las opiniones vertidas por sus colaboradores ni por las actuaciones que, fruto del conocimiento transmitido, puedan realizar terceras personas.


La imagen de la cabecera se ha compuesto con dos fotos cortesía de Pixabay:

https://pixabay.com/illustrations/binary-digitization-zero-one-pay-1327490/
https://pixabay.com/photos/boy-child-fishing-fishing-rod-909552/