Saludos y bienvenidos a... Mañana! (No, no estoy loco, ya lo entenderéis luego :P )
En los 2 post anteriores, vimos cómo se puede hacer un Man In The Middle y cómo combinarlo con sslstrip. Si realizaste alguna prueba, habrás visto que había conexiones que seguían utilizando HTTPs en lugar de HTTP.
Lo que nos estaba pasando es que muchos servicios, utilizan una cabecera llamada HTTP Strict-Transport-Security o HSTS.
Esta cabecera le indica al navegador que debe comunicarse con el servidor utilizando un protocolo seguro. Es decir, HTTPs. Siempre. Por lo tanto, esta es la razón por la que sslstrip no funcionaba :(
Hay que tener en cuenta, que cuando instalas algunos navegadores, ya vienen con la información necesaria para que cuando conecta con ciertas webs siempre se utilice HTTPs. Otros vienen con la información de la cabecera pre-cargada para ciertas webs.
Ahora bien, cuando se envía esta cabecera, se envía junto con un periodo de tiempo en el cual es válida esta cabecera. Este periodo de tiempo se indica con el valor max-age seguido por el número de segundos que será valida la cabecera.
Por ejemplo:
Strict-Transport-Security max-age=10886400
En este caso, la cabecera es válida durante 10886400 segundos o lo que es lo mismo, 126 días.
Si un servidor envía esta cabecera a un cliente, cuando el cliente la reciba, automáticamente su navegador intentara realizar todas las comunicaciones posteriores vía HTTPs y normalmente en todas las respuestas del servidor que utilice HSTS se enviara la cabecera.
Esto nos lleva al punto en el que se fuerza constantemente el uso del protocolo HTTPs.
(Hasta aquí, todo pinta mal para poder espiar las comunicaciones, lo sé)
Por todo lo explicado anteriormente, supongamos que nuestra víctima, accede a un servicio bancario, por ejemplo www.mibancainventada.com y el servidor le envía en la primera respuesta la cabecera HSTS con un max-age de 126 días, tal y como hemos visto anteriormente.
Si queremos que funcione el sslstrip, necesitamos que la víctima no tenga esa cabecera, es decir, o hemos realizado el ataque cuando la víctima no ha visitado la web, o cuando la victima hace mas de 126 días que ha visitado la web.
Pero... ¿Que pasa si hacemos que la fecha y hora de la víctima cambien a una fecha y hora en la que la cabecera ya haya caducado?
Aquí es donde entra en juego delorean (Te puedes descargar el código, lo vas a necesitar :) ).
Delorean es un script escrito en python que nos permite responder con la información que nosotros queramos a una petición de ajuste de hora que se realice utilizando el protocolo NTP.
Esto tiene un pequeño problema, y es que cada sistema operativo tiene una política diferente para decidir cuando es un buen momento para sincronizar su fecha y hora.
En resumen, esto quiere decir que la efectividad de este ataque depende de la suerte que tengas para estar realizando un man in the middle en el momento en el que el sistema operativo de la víctima decida sincronizarse. (Aquí siempre podemos armarnos de paciencia)
De forma muy simplificada el funcionamiento del protocolo NTP es el siguiente:
Primero la victima realiza una petición a un servidor NTP.
Luego el servidor NTP contesta con la información necesaria para que se ajuste la fecha y hora.
Pero como nosotros tenemos hecho un Man In The Middle a la víctima, en realidad la petición hará lo siguiente:
Y lo que contestara delorean será:
Ahora que hemos visto la teoría, vamos a ver como montar todo esto en la práctica.
Lo primero que hay que hacer para realizar el ataque es configurar iptables para redirigir el tráfico que utiliza el protocolo NTP.
Es decir, redirigir el tráfico del protocolo UDP que utilice el puerto 123. Para ello utilizamos el siguiente comando:
El segundo y último paso es descargar delorean (Gracias Jose Selvi por esta herramienta) y ejecutarlo en una terminal.
Una vez hecho esto, cuando la víctima intente sincronizarse, delorean lo detectara, y le contestara con una fecha futura (Esto es configurable mediante parámetros en la llamada del script, pero a nosotros el funcionamiento por defecto nos sirve perfectamente)
Y entonces, como la victima ha viajado al futuro, la información de las cabeceras HSTS habrá caducado, sslstrip hará su trabajo y nosotros podremos espiar las comunicaciones de la víctima.
Bueno pues ya hemos visto como viajar al futuro para espiar las comunicaciones ;). Espero que os haya gustado la entrada.
Hasta la siguiente!
Esta cabecera le indica al navegador que debe comunicarse con el servidor utilizando un protocolo seguro. Es decir, HTTPs. Siempre. Por lo tanto, esta es la razón por la que sslstrip no funcionaba :(
Hay que tener en cuenta, que cuando instalas algunos navegadores, ya vienen con la información necesaria para que cuando conecta con ciertas webs siempre se utilice HTTPs. Otros vienen con la información de la cabecera pre-cargada para ciertas webs.
Ahora bien, cuando se envía esta cabecera, se envía junto con un periodo de tiempo en el cual es válida esta cabecera. Este periodo de tiempo se indica con el valor max-age seguido por el número de segundos que será valida la cabecera.
Por ejemplo:
Strict-Transport-Security max-age=10886400
En este caso, la cabecera es válida durante 10886400 segundos o lo que es lo mismo, 126 días.
Si un servidor envía esta cabecera a un cliente, cuando el cliente la reciba, automáticamente su navegador intentara realizar todas las comunicaciones posteriores vía HTTPs y normalmente en todas las respuestas del servidor que utilice HSTS se enviara la cabecera.
Esto nos lleva al punto en el que se fuerza constantemente el uso del protocolo HTTPs.
(Hasta aquí, todo pinta mal para poder espiar las comunicaciones, lo sé)
Por todo lo explicado anteriormente, supongamos que nuestra víctima, accede a un servicio bancario, por ejemplo www.mibancainventada.com y el servidor le envía en la primera respuesta la cabecera HSTS con un max-age de 126 días, tal y como hemos visto anteriormente.
Si queremos que funcione el sslstrip, necesitamos que la víctima no tenga esa cabecera, es decir, o hemos realizado el ataque cuando la víctima no ha visitado la web, o cuando la victima hace mas de 126 días que ha visitado la web.
Pero... ¿Que pasa si hacemos que la fecha y hora de la víctima cambien a una fecha y hora en la que la cabecera ya haya caducado?
Aquí es donde entra en juego delorean (Te puedes descargar el código, lo vas a necesitar :) ).
Delorean es un script escrito en python que nos permite responder con la información que nosotros queramos a una petición de ajuste de hora que se realice utilizando el protocolo NTP.
Esto tiene un pequeño problema, y es que cada sistema operativo tiene una política diferente para decidir cuando es un buen momento para sincronizar su fecha y hora.
En resumen, esto quiere decir que la efectividad de este ataque depende de la suerte que tengas para estar realizando un man in the middle en el momento en el que el sistema operativo de la víctima decida sincronizarse. (Aquí siempre podemos armarnos de paciencia)
De forma muy simplificada el funcionamiento del protocolo NTP es el siguiente:
Primero la victima realiza una petición a un servidor NTP.
 | |
|
Luego el servidor NTP contesta con la información necesaria para que se ajuste la fecha y hora.
 |
| Respuesta NTP |
Pero como nosotros tenemos hecho un Man In The Middle a la víctima, en realidad la petición hará lo siguiente:
 | |
|
Y lo que contestara delorean será:
 | |
|
Ahora que hemos visto la teoría, vamos a ver como montar todo esto en la práctica.
Lo primero que hay que hacer para realizar el ataque es configurar iptables para redirigir el tráfico que utiliza el protocolo NTP.
Es decir, redirigir el tráfico del protocolo UDP que utilice el puerto 123. Para ello utilizamos el siguiente comando:
iptables -t nat -A PREROUTING -p udp --dport 123 -j REDIRECT --to-port 123
El segundo y último paso es descargar delorean (Gracias Jose Selvi por esta herramienta) y ejecutarlo en una terminal.
./Delorean/delorean.py
Una vez hecho esto, cuando la víctima intente sincronizarse, delorean lo detectara, y le contestara con una fecha futura (Esto es configurable mediante parámetros en la llamada del script, pero a nosotros el funcionamiento por defecto nos sirve perfectamente)
Y entonces, como la victima ha viajado al futuro, la información de las cabeceras HSTS habrá caducado, sslstrip hará su trabajo y nosotros podremos espiar las comunicaciones de la víctima.
Bueno pues ya hemos visto como viajar al futuro para espiar las comunicaciones ;). Espero que os haya gustado la entrada.
Hasta la siguiente!
Este post me ha gustado mucho más que el anterior. Está claro que Https tiene sus defectos, a veces graves, pero siempre es un avance respecto a Http. Todo lo que sea ralentizar, dificultar y reducir los vectores de ataque aunque no sea al 100% es bienvenido. Igual que un buen algoritmo de Hash debe ser lento para dificultar la fuerza bruta, el complicar los ataques puede conseguir que el atacante desista dependiendo de sus motivaciones. Creo que el apartado mental es un factor más a considerar en el tema de la Seguridad, y conseguir que alguien se desmotive o fruste puede ser clave.
ResponderEliminar