Atacando HTTP Strict Transport Security

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

[7] Otros ataques
[8] Herramientas de ayuda

Descargo de responsabilidad: Toda la información se ha obtenido de una forma empirica, realizando pruebas, y en un periodo de tiempo concreto, con lo que puede haber cambiado en el momento de leer este artículo.

En los últimos artículos hemos visto como funciona la sincronización de hora en diferentes sistemas operativos, y como podríamos cambiar eel reloj interno usando Delorean en cada uno de ellos. Sin embargo, aún no hemos hablado de ningún ataque practico que podamos realizar alerando dicho reloj.

Esta investigación la empecé después de haber estado intentando hacer una demo de MitM usando SSLStrip. A pesar de que había hecho demos similares mil veces, no conseguí que me funcionara cuando intentaba visitar GMail y otras webs similares. Cuando analicé el problema, descubrí la existencia de una cabecera "Strict-Transport-Security" que nunca había visto antes.

HTTP Strict Transport Security (alias HSTS) es un mecanismos de seguridad que fue publicado en 2012 y que, a pesar de que aún no está siendo usando masivamente en Internet, sí que es utilizado por los principales proveedores de servicios. La parte servidor es muy sencilla, ya que únicamente es necesario enviar la cabecera HTTP "Strict-Transport-Security" para aplicar la política deseada usando los parámetros "max-age" e "includeSubdomains". En el ejemplo de arriba, el servidor web está configurando una política que dice "¡ey! No importa lo que pase, pero por favor conecta conmigo siempre usando HTTPS durante los próximos 3153600 segundos".

La parte más complicada de HSTS recae en el lado del navegador. Un navegador necesita leer la cabecera y tomar las acciones necesarias para asegurarse que se cumple la política. La mayoría de navegadores soportan HSTS en la actualidad, aunque IE no lo ha soportado hasta el 9 de Junio de este año. Mientras estaba hablando en DEF CON (Agosto 2015), un asistente me corrijió cuando dije que "IE no soporta HSTS", lo cual era cierto en aquel momento. Le pregunté si era algo reciente y me dijo que hacía 6 meses de aquello, aunque la documentación que he podido encontrar no habla de esas fechas. En cualquier caso, en este momento IE sí que soporta HSTS.

Además, Google y Mozilla crearon una lista precargada de HSTS en sus navegadores (idea posteriormente utilizada también en otros navegadores). Una lista precargada es una lista de proveedores conocidos (google, twitter, facebook, paypal, etc) para los que el uso de HSTS "está forzado". El objetivo de esta lista precargada es evitar que un atacante aproveche los momentos siguientes a la instalación del navegador o a la limpieza de las cachés, o cuando se visita una página por primera vez, antes de que se configure ninguna política.

Aunque la información que podemos encontrar desde Google y Mozilla parece que hablan de la lista precargada como si fuera una lista estática, lo cierto es que las entradas precargadas son tratadas exactamente igual que las entradas dinámicas. Cuando un navegador es instalado y so caché es limpiada, todas las entradas de esta lista son añadudas como entradas dinámicas usando un valor por defecto (10 semanas) y son actualizadas del mismo modo que cualquier entrada dinámica, por lo que no representa un problema a la hora de utilizar Delorean. 

El único navegador de los que estuve analizando que funcionaba de una forma diferente fue Apple Safari, que guarda la lista precargada en un fichero .plist y fuerza siempre que esos hosts se visiten por HTTPS, indepientement de la fecha del equipo.

Como sabemos que la política de HSTS nos va a impedir interceptar la primera conexión HTTP y, como consecuencia, a user SSLStrip (o interceptar la comunicación de otro modo) durante la cantidad de segundos especificada como "max-age", nuestro ataque contra HSTS consiste en actualizar la hora local de tal forma que forcemos la expiración de la caché de HSTS. Cuando no hay entradas en la caché de HSTS, el navegador se comporta de la forma habitual, con lo que al teclear nombres de hosts como "mail.google.com" se conectará usando HTTP antes de ser redirigido a HTTPS.


Este fue el principal ataque que enseñe en la BlackHat Europe del año pasado, que ya fue publicada hace unos meses, así que podéis pegar un vistazo, pero no vale burlarse de mi Inglés ;)