Ataques man in the middle a HSTS: SSLStrip 2 & Delorean

HSTS (HTTP Strict Transport Security) es un mecanismo de seguridad que se fuerza desde el servidor web a los navegadores y que permite asegurar que las conexiones que se realizan desde el navegador al sitio web se realizarán siempre a través de un canal seguro con TLS/SSL. En otras palabras, si cuando un usuario quiere acceder a un sitio web cómo puede ser Gmail o Facebook, éste no introduce en la barra de direcciones URL el protocolo con HTTPs, por ejemplo “https://gmail.com” o “https://facebook.com”, sino que introduce simplemente gmail.com o facebook.com, entonces el navegador automáticamente fuerza la conexión HTTPs.

Figura 1: Ataques a HSTS: SSLStrip 2 & Delorean

Si no se hiciera ese forzado, durante esa primera conexión un atacante en medio podría hacer una manipulación de todo el tráfico entre el navegador y el atacante para que la conexión en ese tramo fuera sin cifrar, y el cifrado se hiciera entre la máquina del atacante y el servidor original que usa HTTPs. De esto se aprovechaba en el pasado el ataque SSL Strip diseñado por el famoso hacker Moxie Marlinspike, y nuestra querida Evil FOCA lo implementa de igual forma pero en los ataques de Bridging HTTP(IPv6)-HTTPs(IPv4).

Figura 2: Concepto de SSLStrip de un dominio con Evil FOCA

Sin embargo, a día de hoy la mayoría de los sitios de gran uso, como pueden ser Paypal, Gmail, Facebook, Twitter, Outlook, etcétera, utilizan la cabecera HSTS para que los navegadores que lo soportan, que a día de hoy son todos, sepan que cuando el usuario introduzca el dominio en la barra de direcciones sin especificar el protocolo, se debe acceder siempre a través de TLS/SSL. De este modo, nunca se realizará una petición HTTP a un dominio que use HSTS y evitará que un atacante en medio puedo hacer un esquema de SSLStrip. Puedes leer más sobre esto en la serie de artículos de nuestro compañero Sergio de los Santos dedicada a Certificate Pinning.

El problema de la primera petición

Por otro lado, quedaba por resolver la primera petición cuando se instala un navegador, es decir, si nosotros instalamos Mozilla Firefox o Google Chrome, la primera vez que hiciéramos una petición a gmail.com, esta petición iría por HTTP hasta ser redirigido al servidor por HTTPs con un redirect y recibir la cabecera HSTS para establecer la política de seguridad. Para resolver este "mínimo" problema, se habilitó una lista precargada de dominios, dónde al instalar un navegador, éste ya tiene una lista precargada de dominios a los que debe conectarse por HTTPs.

La cabecera que un servidor con HSTS habilitado nos devuelve tiene 3 partes: el valor de max-age que es el tiempo en segundos de vida del HSTS en nuestro navegador para dicho dominio - y que vimos que se podía utilizar como una supercookie para vigilar al usuario. Si un dominio X nos devuelve en su cabecera Strict-Tansport-Security un valor de max-age de 1.000.000 de segundos, esto quiere decir que durante el próximo millón de segundos, siempre que hagamos una petición al dominio X, nuestro navegador lo hará bajo HTTPs, aunque no lo indiquemos explícitamente. Otra parte es include subdomains, es decir si el servidor nos devuelve este campo querrá decir a partir del dominio hacia abajo se hará efectivo el HSTS. Por último, podemos recibir el valor preload.

¿Cómo podemos saber si un sitio devuelve HSTS?

Para ver las opciones de HSTS puedes usar las herramientas del developer de Google Chrome o muchos plugins de Firefox, pero para esta pequeña prueba utilizaremos la herramienta curl, con la que podemos realizar peticiones web y obtener las respuestas del servidor. En el primer ejemplo hacemos la consulta sobre Paypal:

Figura 3: Información HSTS de paypal.com 

El servidor de Paypal nos devuelve la cabecera Strict-Transport-Security con el valor del max-age. Probando con Outlook encontramos una curiosidad. Tal y como se puede ver en la imagen el dominio que tiene HSTS es www.hotmail.com y no www.outlook.com. Realmente da igual, ya que se hacen varias redirecciones al acceder a Outlook, pero dominios como Outlook.com o login.live.com no devuelven la cabecera.

Figura 4: Configuración de hotmail.com

Estas configuraciones abren posibilidades a un atacante y ventanas de vulnerabilidad a estos dominios en las redes, tal y como vamos a ver a continuación.

PoC: Usando MITMf para lanzar SSLStrip 2

El investigador Leonardo Nve publicó hace algún tiempo la herramienta SSLStrip 2 o SSLStrip+, la cuál es una evolución de SSLStrip. Hoy en día la herramienta desarrollada por Leonardo fue añadida a un framework denominado MITMf. Este framework es muy completo ya que proporciona gran cantidad de plugins, todos ellos relacionados con ataques de red. En este ejemplo que vamos a ver el ataque se lanzará sobre una máquina Windows 7 en la que se acaba de instalar el navegador Firefox 44.0.2. Desde la línea de comandos lanzamos el script mitmf.py con los plugins de arp, dns, hsts e indicando a quién se debe envenenar, en este caso a un router y la máquina Windows.

Figura 5: Lanzando el ataque con MITMf

Si comprobaramos la caché ARP de la máquina Windows veríamos que el envenenamiento de caché ha funcionado. Ahora toca comprobar qué dominios vienen precargados en el navegador. Por ejemplo, introduciendo sitios como Gmail, Facebook o Twitter, el navegador directamente se ha conectado por HTTPs, por lo que el SSLStrip 2 no nos funciona. En el caso de Outlook vemos cómo empezamos a ver qué la herramienta MITMf comienza a trabajar y podemos ver el mensaje: “zapped a strict-transport-security header”, es decir, estamos en medio, hubo una primera petición por HTTP y SSLStrip 2 se está encargando de eliminar los headers HSTS para evitar problemas futuros.

Figura 6: MITMf intercepta las peticiones Outlook.com y subsiguientes

Una vez vemos que está funcionando el ataque, si introducimos un usuario y contraseña en el login de Outlook lo podemos visualizar en la máquina con Kali Linux, tal y como se puede ver en la imagen superior. Lo curioso de esto, es que en un navegador recién instalado Gmail, Facebook o Twitter, vienen con HSTS precargado, pero en el caso de Outlook no.

Poc: Viajemos hacia el futuro

El investigador José Selvi demostró como mediante un ataque al tiempo de los equipos podríamos hacer caducar las entradas HSTS en el navegador, por lo que se tendría que hacer de nuevo una petición por HTTP. Selvi llamó a esto ataque Delorean. Es cierto que conseguir cambiar el tiempo de una máquina remota no es sencillo, aunque depende un poco del caso. José Selvi enseñó en una de sus charlas como en el caso de Ubuntu o Fedora se podía aprovechar el acceso de este sistema operativo a la red para interceptar la petición NTP que se genera. El protocolo NTP permite sincronizar los tiempos de una máquina. Entonces, con un ataque ARP Spoofing básico, SSL Strip2 y Delorean podemos:

- Colocarnos en medio de la comunicación.
- Interceptar las peticiones NTP y modificarlas, por ejemplo diciendo al sistema que se encuentra en 2 o 3 años adelante.
- Visualizar las claves.

Aparte de mantener la aplicación MITMf con la configuración anterior, habrá que lanzar la herramienta Delorean e incluir una regla en iptables. La regla en iptables es la siguiente:

iptables –t nat –A PREROUTING –i [interfaz de red] –p udp –s [red origen] ! –d [red destino] –dport 123 –j REDIRECT –to-port 123.

La máquina víctima es un Ubuntu, el cual podría ser echado de una red WiFi mediante un ataque de desautenticación para así forzar la petición de sincronización temporal vía NTP. Otro ataque posible sería el de colocar una WiFi abierta y esperar a que un sistema Ubuntu se conectara. En ese instante, el sistema realizará una petición NTP que puede ser interceptada por nosotros y modificada con Delorean.

Figura 7: Camibando la hora a un Ubuntu para caducar HSTS

Como se puede ver en la siguiente imagen correspondiente al sistema Ubuntu, el tiempo ha cambiado. Nos hemos ido al futuro, concretamente al año 2019, al mes de Enero. Hemos viajo al futuro.

Figura 8: Fecha del sistema cambiada

Ahora, si desde Ubuntu accediéramos al navegador y navegásemos a dominios como Gmail o Facebook seríamos vulnerables y con SSLStrip 2 nos podrían robar las credenciales. En el caso de Twitter no, porque deberíamos viajar en el tiempo 20 años, ya que el max-age que la empresa del pájaro azul impone son más de 20 años. En la siguiente imagen se puede ver como se accede a Gmail y no se está haciendo a través de HTTPs. Esto es debido a que las entradas HSTS caducaron en la caché del navegador y se realizó la petición por HTTP. Como mucha gente puede pensar, en un entorno real, esto haría saltar alarmas, ya que modificar 2 o 3 años la fecha de un equipo puede provocar que los certificados caduquen y salten alarmas en la máquina, pero las passwords de Gmail vuelan también.

Figura 9: Autenticando en Google sin HTTPs

HSTS es una medida a día de hoy bastante segura, y aunque existen técnicas para bypassearla, no es algo sencillo. Es cierto que hay muchos sitios, incluidos bancos, que no utilizan HSTS a día de hoy, pero cada vez van siendo más los que se decantan por la sencillez de HSTS y por el potencial que tiene.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”