9 Abril, 2017 a las 0:00

Últimamente veo en gran cantidad de foros y grupos de Telegram gente que empieza con las auditorías de red a aprender técnicas de MitM y a jugar con herramientas como sslstrip2 que se fustran al ver que no pueden realizarlos en algunos sitios como Facebook. El motivo de esto es que estos sitios tienen una característica llamada HSTS, pero ¿qué es HSTS y cual es la diferencia con respecto a HTTPS/SSL?.

Bueno, realmente HSTS (HTTP Strict Transport Security) no es diferente a SSL, realmente HSTS es un añadido a SSL. Para explicar por tanto qué es HSTS vamos a explicar primeramente cómo funcionan normalmente las Webs HTTPS.

  1. El usuario introduce el dominio en su explorador sin indicar el protocolo.
  2. El explorador hace una petición HTTP hacia el servidor Web.
  3. El servidor Web le envía una cabecera indicandole que se dirija a la versión HTTPS
  4. El navegador hace una petición hacia HTTPS.

Si recordamos, las herramientas como SSLstrip funcionan aprovechándose del segundo paso y tercer paso en el cual el navegador hace una consulta insegura contra el servidor Web y este le envía una respuesta igualmente insegura redirigiéndole hacia la versión segura. SSLStrip elimina la cabecera que redirige hacia la versión HTTPS y crea un túnel inseguro entre el atacante y la víctima y otro seguro el atacante y el servidor legítimo, de forma que las peticiones el cliente las haga a el atacante mediante HTTP y el atacante las reenvíe hacia la versión HTTPS.

¿Entonces qué es HSTS y por qué impide que pueda usarse SSLstrip?

Bien, HSTS es una cabecera que envía el servidor Web que indica que a partir de ese momento todas las peticiones que se hagan hacia el servidor se hagan a través de HTTPS independientemente de que se indique el protocolo o no. En esta cabecera, además irá un número de segundos en los que esta directiva debe cumplirse. Aquí podéis ver un ejemplo de dicha cabecera enviada desde www.facebook.com que indica que las futuras peticiones se hagan siempre por HTTPS durante los próximos 15552000 segundos, es decir 180 días.

Por tanto, el único momento donde SSLstrip podría atacar la conexión es la primera conexión que hace el navegador hacia Facebook una vez instalado o la primera vez que se realiza una petición transcurridos 180 días desde la última lo cual hace que el ataque de SSLstrip sea obviamente mucho mas complicado.

Además de esto y por si fuese poco, previniendo que se haga un ataque en la primera conexión (con el navegador recién instalado) algunos navegadores como Google Chrome incorporan precargada una lista de dominios que funcionan mediante HSTS, de forma que la primera conexión nada mas instalar el navegador se haga también mediante HTTPS.

Así pues, podríamos definir que para atacar una web con HSTS es mantener SSLstrip hasta que la directiva caducase, el gran problema es que cada nueva petición enviada hacia la Web renovaría el tiempo que debe permanecer dicha directiva pues la cabecera volverá a enviarse, por tanto la víctima debería haber estado el tiempo suficiente sin usar la Web en cuestión (en nuestro ejemplo 180 días) para que la política caducase. Entonces ¿De qué forma pueden interceptarse el tráfico entre una Web con HSTS y la víctima? la solución mas habitual es cambiar la hora del equipo víctima para hacerlo viajar en el tiempo hasta un momento que la directiva HSTS esté caducada.

Atacando un sitio web con HSTS habilitado gracias a Delorean

Todos sabemos que los sistemas operativos realizan una consulta hacia determinados servidores mediante el protocolo NTP para mantener sincronizado su reloj. Delorean es una utilidad capaz de interceptar las peticiones NTP de la red y modificarlas para así cambiar la hora en los equipos víctimas por tanto si conseguimos establecer el reloj de una máquina fuera del rango de validez de la política Strict-Transport-Security podremos usar sslstrip. En el ejemplo que vamos a poner a continuación usaremos MitMf (un framework para ataques de MitM) y nos ayudaremos de Delorean para invalidar la política de HSTS actual.

Dependiendo del sistema operativo la fecha y hora se actualiza en determinados momentos. Así pues sistemas operativos como macOS la actualizan cuando el usuario arranca el sistema o abre el menú de preferencias de hora; Ubuntu o Fedora lo hacen cada vez que se conectan a Internet pudiendo así forzarse mediante un ataque de desautenticación Wifi por ejemplo; por su parte Windows es el mas seguro de ellos realizando la sincronización automática únicamente el domingo de madrugada (o el lunes siguiente si el sistema estaba apagado).

El primer paso para este tipo de ataque es crear las rutas correctas en iptables, para ellos redirigiremos el puerto 123 udp y ya que estamos crearemos el regla típica para el uso de SSLstrip redirigiendo el tráfico tcp del puerto 80 hacia el 10000.

Una vez preparadas las reglas en iptables procederemos a lanzar el MitMf, en nuestro caso cargaremos los plugins de spoofing, dns, arp y por supuesto hsts. El plugin hsts carga sslstrip+ por eso en nuestra prueba de concepto no usaremos la herramienta sslstrip por separado. En la captura podéis ver como lanzamos MitMf siendo la puerta de enlace de nuestra red la IP 11.11.11.2.

Una vez lanzado y posicionados en medio de las comunicaciones pasaremos a arrancar Delorean, esta herramienta no requiere ningún parámetro especial. Ahora solo falta esperar o tratar de forzar de alguna de las maneras que hemos explicado anteriormente a que el equipo víctima sincronice la hora.

Aquí vemos como Delorean envía las respuestas NTP cambiando la fecha al año 2020 a un equipo con Ubuntu que acaba de arrancar.

Sin problema MitMf está haciendo su trabajo eliminando las cabeceras strict-transport-security y forzando al usuario a usar http.

Acerca de Miguel Díaz

Informático, enamorado de la programación, diseño Web y el deporte.
Categorías: Internet, Pentesting, Seguridad. Etiquetas: , , , , , , , , , .

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *