13 jul. 2016

HSTS: cómo saltear HTTPS en la práctica (I)

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 SSLStrip 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 los 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 witter, vienen con HSTS precargado, pero en el caso de Outlook no.

Fuente: Flu-Project

3 comentarios:

  1. muy interesandte el articulo, lo probare esta noche en mi lab virtual

    ResponderEliminar
  2. Por algún motivo en especial deja sin internet a la "victima"?

    ResponderEliminar
    Respuestas
    1. Hola, si lo hiciste bien nadie se queda sin internet. La victima sí podria notar la falta de HTTPS pero eso es parte del ataque.

      Cristian

      Eliminar

Gracias por dejar un comentario en Segu-Info
Si vas a dejar una consulta, procura tener habilitado tu perfil en Blogger o deja una forma de contacto.

Gracias por comentar!