El HSTS, HTTP Strict Transport Security, es un mecanismo de seguridad web que permite asegurar que las conexiones que se realizan desde un navegador a un sitio web se realizan a través de TLS/SSL. En otras palabras, 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 “https://gmail.com” o “https://facebook.com”, sino que, generalmente el usuario introduce gmail.com o facebook.com. De esto se aprovechaba en el pasado el ataque SSL Strip diseñado por el famoso hacker Moxie Marlinspike.
A día de hoy, la mayoría de estos sitios de gran uso como puede 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 gmail.com, por ejemplo, se debe acceder a través de TLS/SSL. De este modo, nunca se realizará una petición HTTP a un dominio que permita HSTS.
Por otro lado, quedaba resolver la primera petición cuando se instala un navegador, es decir, si nosotros instalamos Firefox o Chrome, la primera vez que hiciéramos una petición a gmail.com, esta petición iría por HTTP hasta ser redirigido. Para resolver este mínimo problema, se habilitó una lista precargada, 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 max-age que es el tiempo en segundos de vida del HSTS en nuestro navegador para dicho dominio, Por ejemplo, si un dominio X nos devuelve en su cabecera Strict-Tansport-Security un 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 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:
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.
PoC: Usando MITMf para lanzar SSLStrip 2
El investigador Leonardo Nve publicó la herramienta SSLStrip 2 o SSLStrip+, la cual es una evolución del SSLStrip de Moxie. 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.
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.
Si comprobamos 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 el SSLStrip 2 se está encargando de zappear las headers HSTS.
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 Kali, tal y como se puede ver en la imagen inferior. 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. 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. 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.
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.
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.
El 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.
No hay comentarios:
Publicar un comentario