Breaking Out HSTS (and HPKP) on Firefox, IE/Edge and (possibly) Chrome. Nuestra presentación en Black Hat

Durante mucho tiempo hemos investigado sobre HSTS, HPKP, certificate pinning y tecnologías TLS en general. Como efecto colateral de este trabajo hemos encontrado algunas debilidades interesantes en la forma en la que Firefox, Chrome e IE/Edge implementan ambos mecanismos: HSTS y HPKP. Usando este estudio, fuimos seleccionados para la Black Hat Europe 2017 en Londres, donde hablamos, el pasado 7 de diciembre, en la sección de briefings. Estos son algunos detalles sobre lo que hemos presentado, a modo de resumen de la presentación disponible aquí.

Introducción

Aparte de las vulnerabilidades como HeartBleed, CRIME, etc. los ataques habituales sobre SSL se aprovechan de:

Certificados Rogue: que ocurren cuando un atacante entra en una autoridad certificadora, desempeña la función de una CA dentro de una red, o se aprovecha de un error de procedimiento, lo que le permite emitir un certificado que parezca pertenecer a una entidad, pero en realidad es falso. En los últimos años podemos encontrar muchos ejemplos de este tipo.

Técnicas SSLStrip: consisten básicamente en interceptar una conexión inicial no segura, a partir de la que todas las peticiones siguientes son reconducidas vía HTTP y no HTTPS.

Para el primer problema, HPKP es una de las soluciones propuestas. Forzando al navegador a recordar los certificados legítimos de los sitios que visita, puesto que el servidor los envía usando una cabecera HTTP. Para el segundo, se utiliza HSTS. Que consiste en una cabecera enviada para obligar al navegador a recordar que siempre debe conectarse vía TLS/SSL, así no se producirá ninguna conexión insegura tras el envío de esta cabecera.

Hemos analizado cómo los diferentes navegadores implementan esas (relativamente) nuevas funcionalidades, y hemos encontrado (entre otros errores menores) lo siguiente:

Firefox

Tal y como explicamos cuando PinPatrol fue publicado, Firefox usa un fichero TXT con un límite de 1024 entradas para recordar dominios HSTS y HPKP. Parece que pensaron que era improbable que un usuario fuese a almacenar más que esa cantidad. Además implementaron el concepto de Score (puntuación) para cada dominio incluido.

Código de Firefox explicando el límite de 1024 entradas

Este score indica la frecuencia con la que el usuario visita cada dominio en días diferentes. Una puntuación de 0 significa que la cabecera ha expirado o que es el primer día que ha visitado el sitio. Este score adquiere el valor de 1 el siguiente día que el usuario vuelve a visitar ese dominio. Y subirá a 2 al siguiente día diferente (que no es necesariamente el siguiente día) que visite ese sitio con HSTS. En resumen, cuanto más frecuentemente el usuario visite el sitio en días distintos, mayor será el score. En caso de que fuese necesario eliminar alguna de las 1024 entradas para alojar nuevas direcciones (liberar un slot), se eliminará el que menor puntuación tenga.

Lo que hemos hecho es crear un JavaScript para Bettercap para inyectar dominios y un sitio web para alojarlo. Ambos elementos se han desarrollado para permitir el envío masivo de cabeceras HSTS (lo que llamamos «entradas basura») con diferentes subdominios. Firefox, en menos de 2 minutos, ha completado la tabla de las 1024 entradas y comienza a eliminar dominios legítimos con puntuación 0.

Script para enviar cabeceras desde nuestro sitio cloudpinning.com

¿Qué ocurre si un dominio legítimo tiene una puntuación mayor y es menos probable que sea eliminado? Para esos casos, debemos realizar este ataque en días diferentes, de esta manera nuestras entradas basura obtendrán un score de 1, y los dominios legítimos de 0 o 1 serán, con bastante probabilidad, eliminados. Y podríamos repetir indefinidamente este proceso.

Entradas basura con Score = 0 han eliminado dominios legítimos

Si no queremos esperar uno o varios días, podemos utilizar una técnica de Jose Selvi llamada Delorean, acelerando este período de tiempo en clientes Linux y Mac. Combinadas, podríamos probablemente desalojar dominios consolidados de las entradas HSTS y HPKP de Firefox, en pocos minutos.

Usando Delorian para acelerar el proceso, si quisiésemos hacerlo

Incluso si esto no funcionase y no somos capaces de desalojar un dominio de la tabla (esto equivale a deshabilitar HSTS y HPKP para este dominio, lo que permitiría un ataque Man in The Middle), Firefox, debido a este mecanismo basado en entradas, acabará usando únicamente un único espacio (el único que queda con score 0) para almacenar entradas HSTS. De esta forma será constantemente reemplazado por nuevos dominios con puntuación de 0 también, con lo cual, eventualmente, hace que HSTS sea inútil.

Si rellenamos las 1024 entradas con un valor mayor que 0, sólo quedará un espacio libre para usar.

Chrome

Chrome no implementa el concepto de score. Simplemente almacena HSTS y HPKP en un fichero JSON. Si alguien envía un conjunto amplio de entradas HSTS y HPKP desde un servidor o utilizando un ataque MiTM, Chrome los almacenará para siempre. Nuestra técnica aquí consiste en enviar miles de peticiones HSTS y HPKP gracias a la ilimitada cantidad de «pins» que almacena Chrome para HPKP, donde cada petición puede ser tan larga como lo permita una cabecera HTTP. Resultado: en aproximadamente 10 minutos, este fichero JSON ocupa 500 megabytes o más de espacio en disco duro, y como consecuencia Chrome se bloquea. Ni siquiera permitiendo escribir ni una sola dirección nueva. La única opción es eliminar la configuración (si es que se puede) o eliminar el JSON. Este ataque puede ser realizado desde cualquier sitio web donde se pueda insertar código JavaScript.

Montones y montones de pins enviados a Chrome

IE/Edge

Básicamente, la funcion o API que gestiona HSTS en Windows está localizada en la librería WININET.DLL, y se llama HttpIsHostHstsEnabled, que parece no tener documentación oficial. Entendemos que para comprender el sistema en detalle se requiere un proceso de ingeniería inversa y análisis forense más profundo. Internet Explorer (e incluso de Edge), Microsoft utiliza un tipo de base de datos propietaria llamada Extensible Storage Engine (ESE) para almacenar datos HSTS entre otros. Este fichero con la información en bruto se almacena habitualmente en el fichero WebCacheV01.dat bajo el perfil de usuario, en la carpeta WebCache.

Con la falta de documentación oficial, esto es todo lo que puedes «saber» de cómo IE/Edge almacena su información HSTS

HSTS no parece funcionar adecuadamente en este navegador. Hemos descubierto que las tablas donde esta información se almacena aparentemente solo funciona con dominios populares. Parece que no se recuerda el HSTS para aquellos dominios menos conocidos. Además, incluso eliminando la cache (no sólo el sistema donde se almacena el HSTS) no parece afectar a la lista de entradas. Hemos realizado ingeniería inversa sobre las APIs que deberían estar involucradas en el almacenaje de esta información y por lo visto, nunca son usadas. Como PoC, hemos consultado 131 veces nuestra dirección cloudpinning.com, y tras reiniciar el navegador e incluso el ordenador, ni un solo cambio fue realizado en las tablas permanentes de HSTS.