miércoles, marzo 02, 2016

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

16 comentarios:

Anónimo dijo...

http://www.ipv6core.com.ar/2016/02/atacando-hsts.html

xperia92 dijo...

Mejor visiten www.spirate.li :'v

Karim dijo...

Muy buena entrada Pablo ;)

kabracity dijo...

Muy interesante :)!

Unknown dijo...

Muy bueno esto. Me gusta mucho gracias chema Alonso

Anónimo dijo...

Delorean ya no funciona

Anónimo dijo...

Anónimo, a día 3 de Marzo sigue funcionando. Seguro que sabes usarlo?

Anónimo dijo...

Articuli me ha gustado mucho, unas maquinas, saludos

Anónimo dijo...

Funciona pero los navegadores lo tienen parcheado

Paco dijo...

Buenas Chema, te descubri hace poco por internet y empece a investigar cosas de ti y veo que entiendes en el tema espero que puedas ayudarme.
Lo primero es sabes que es yodel? la app para moviles tan famosa en España. El usuario se descarga la aplicación, y sin registro previo, puede hablar con otras personas en un radio de 10 kilómetros sin necesidad de revelar su identidad
, pero la primera vez que te lo instalas necesitas poner un correo o cuenta de gmail,hotmail,etc.
El caso con un sniffer he capurado los paquetes y he desencriptado el ssl y lo he convertido en texto plano, pues de hay logro sacar todo el trafico de los mensajes, y consigo su posicion pero solo un redondeo en grados celsious, tambien la hora exacta cuando se puso el mansaje y la fecha. Y lo mas importante de todo el id de usuario .
El problema es que necesito o una posicion exacta desde donde se envian, no un redondeo que es lo que consigo sacar del ssl convertido a plano, o a partir del ID del usuario conseguir el primer correo o cuenta con la que nos logeamos que supongo que tiene que estar unido de alguna forma porque no puede ser totalmente anonima esta aplicacion es imposible.
Con todo esto espero que si me lees puedas ponerte en contacto y poder ayudarme.
Mi correo es franciscohernandezsantos3@gmail.com
Si no entiendes algo soy yo que no me se explicar xD
Gracias de ante mano

Anónimo dijo...

Con una simple redirección http -> https en .htaccess se acabo el problema, ¿no?
Despues al tener activado el HSTS cargaria directamente los https

Unknown dijo...

Buenas espero a alguien pueda ayudarme instale kali Linux 2.0 Y le agregue persistencia después procedo a instalar y actualizar repositorios y prosigo con instalar mitmf el problema es que al iniciarlo no me escanea el tráfico y me doy cuenta que los asteriscos qué creo confirman que están corriendo los programas no están por ejemplo al lado de sslstrip o arp no me. Aparecen el comando qué uso es el mitmf - - spoof - - arp - i wlan0 --target ip victima - - gateway ip router - - hsts y al dar entre se inicia pero no captura nada y supongo que es porque no aparece esos asteriscos

Unknown dijo...

hola. una consulta ojala alguien ayude, cada vez que abro sslstrip o sslstrip2, al capturar el primer paquete se detiene, solo me deja captar el primer paquete, alguna solucion????

Ruidos Molestos dijo...

No creo que gmail, facebook, twitter, etc y cualquier sitios que se digne de ser seguro sirva contenido en http, por lo cual no hay bypass que funcione afuera de un lab...

Chema Alonso dijo...

@Ruidos Molestos, se nota que sabes poco de tecnología y de cómo funciona. El Bridging HTTPS(IPv4)-HTTP(IPV4) funciona en las conexiones cuando el cliente no trae almacenado en código del propio navegador el certificado de todos los sitios con HSTS que se quieren proteger de primeras conexiones. Por otro lado, periódicamente aparecen vulnerabilidades de HSTS como esta de Delorean, que fuerzan a recargar esa primera conexión, y entonces se produce una nueva petición HTTP que puede ser utilizada para hacer un Bridging HTTPS-HTTP entre IPv4&IPv6 como hacíamos nosotros, pero existen otros ataques como WPAD(IPv4 o IPv6).

Esto es "ingeniería", no "creencia"... así que se estudia, se investiga, y se avanza.

Para terminar... este post es de 2016, así que la rueda ha girado mucho desde entonces....

Ruidos Molestos dijo...

Si, tienes razon, la conexion https la realiza el atacante contra el server, y el navegador usa http contra el atacante (siempre y cuando este hardcodeado en el navegador o no haya expirado el tiempo de hsts como indicas), luego de estudiarlo un rato entre en razon, mis disculpas y gracias por contestar Chema.

Entrada destacada

Cibercriminales con Inteligencia Artificial: Una charla para estudiantes en la Zaragoza

Hoy domingo toca ir a participar en un evento, con una charla y una pequeña demo. Ahora mismo sí, así que el tiempo apremia, os dejo una cha...

Entradas populares