HSTS es insuficiente frente ataques MiTM – PoC

El HSTS es un es un mecanismo de seguridad web según la cual un servidor web fuerza a los navegadores que se conectan que deben interactuar con ellos solamente mediante conexiones seguras https. Es decir si tu te intentas conectar a una web poniendo “facebook.com” automáticamente el navegador reescribe la url a “https://facebook.com”.

El objetivo de esta entrada es concienciar a la gente que incluso cuando sabemos que una web fuerza la conexión SSL (https) como por ejemplo gmail o la web de nuestro banco (no todos) debemos mirar siempre si, en el instante en que nos estamos conectado, esta conexión es establecida mediante https y si además el certificado SSL esta o no caducado. Cómo ya hemos visto en la entrada anterior conectarnos a una wifi abierta trae ciertas problemáticas, incluso cuando es nuestra propia red puesto que no sabemos si alguien nos ha podido entrar aprovechando alguna debilidad.

Para esta prueba de concepto lo que haremos es realizar un ataque man in the middle para redireccionar todo el trafico de la víctima a través de nuestro ordenador y que este realice un SSLstrip. Después de esto solo queda activar el Whireshark y esnifar el trafico de la red.

SSLstrip fuerza a que las conexiones que pasan a través de nuestro ordenador (debido al MITM) se hagan a través de http (inseguro). ¿Que sucede si forzamos el http delante de la url y esta tiene activado el HSTS? Que la web no cargará.

Pero tranquilos que tenemos a SSLStrip 2 que nos soluciona este problema eliminado las cabeceras HSTS, para facilitar el trabajo tenemos el MiTMf que es un framework que lo incorpora y nos facilita su uso, empecemos.

Usaremos el framework antes mencionado y lo configuraremos para una ip muy concreta 192.168.1.62 (víctima) este lo que hará es transformar todas las peticiones de esta ip de https a http como acabo de explicar para que los datos viajen por la red en texto claro. Todos sabemos que cuando los datos viajan en texto claro y por tanto no están encriptados podemos leerlos con cualquier sniffer de red, pero vayamos paso a paso.

Primero de todo lanzaremos el framework de la siguiente manera.

A continuación si nos intentamos conectar desde el pc de la victima a una web como la de Outlook (la cual siempre se nos conecta por https) vemos como la url empieza con “http” (inseguro). Ahora ya tenemos la web preparada para que envié los datos en texto claro.

El siguiente paso es muy obvio, es mirar que nos ha capturado nuestro sniffer de red.

Si no queremos usar ningún sniffer podemos volver al framework y ver los datos que ha capturado del envió de formularios vía POST a login.live.com

Al intentar replicar esta prueba de concepto a otra web como por ejemplo Gmail vemos que el navegador de la victima se conecta a través de HTTPS. ¿Qué ha pasado?

Lo que nos acaba de suceder es que a esta pagina ya había accedido hacía poco tiempo y el navegador tenia cargada en cache la política de conectarse forzosamente mediante HTTPS.

Para solucionar este problema lo que vamos a hacer es usar Delorean. Se trata de un script que permite generar peticiones NTP a una victima para que esta sincronice su reloj a una fecha del futuro. De esta manera y con un ataque ARP Spoofing básico, SSL Strip 2 y Delorean podemos Interceptar las peticiones NTP y modificarlas, por ejemplo diciendo al sistema que se encuentra en 2 o 3 años adelante. Gracias a este engaño hacemos que las políticas instauradas por la cabecera HSTS caduquen y que SSLstrip realice bien su trabajo.

Para poder usar Delorean tenemos que configurar nuestro firewall.

Una vez configurado solo tenemos que lanzarlo y esperar a que el sistema se sincronice.

Una vez sincronizado vemos como el ataque también funciona para gmail pudiendo extraer usuario y contraseña de manera rápida y fácil.

 

Recordad!!! Tenéis que revisar siempre que en vuestro navegador aparezca el símbolo de conexión segura (https) con certificado valido!!.