Bootstrap MITM en HTTPs y la directiva preload en HSTS

Hace ya seis años, cuando estuve en el programa de Salvados con Jordi Évole, hice una demostración de un ataque de Man in the Middle con mi querida Evil FOCA para hacer un Bridging HTTPs(IPv4)-HTTP(IPv6), es decir, básicamente lo que hacía era pillar la primera petición de un navegador a un dominio y hacer que fuera por HTTP siempre.

Figura 1: Bootstrap MITM en HTTPs y la directiva preload en HSTS

El truco se basa en que es la primera petición que se captura desde ese navegador al sitio. Es decir, alguien solicita http://www.facebook.com y el atacante captura esa petición la primera vez. Para ello el truco era utilizar la Evil FOCA para quitar del medio toda cabecera HSTS y cualquier petición HTTPS desde el cliente.

Figura 2: Demo de Evil FOCA y Bootstrap MitM Bootstrap en Salvados
Es decir, entre el cliente y el Man in the Middle todas las peticiones se fuerzan a ser HTTP sobre IPv6, mientras que entre el MITM y el backend - en este caso de Facebook - se hacen en HTTPs sobre IPv4. Este es un ataque muy molón que presentamos en DefCON con la charla de la Evil FOCA, y que se describe en detalle en el libro de Ataques en Redes de Datos IPv4 & IPv6 3ª Edición que tenéis en 0xWord - (aún está el código de descuento activo hasta el día 20 de Julio).

Figura 3: Libro de Ataques en redes de datos IPv4 & IPv6 3ª Edición

Ese tipo de ataque que yo contaba y que implementamos en Evil FOCA se recoge en el estándar del HSTS (HTTP Strict Transport Security) en la sección 14.6 como BootStrap MITM vulnerabiliy, ya que si alguien es capaz de cazar la primera petición de un dominio bajo HSTS por un redirect, entonces el atacante podría hacer justo, justo, justo lo que hacía nuestra querida Evil FOCA en las demos que hice yo.

Figura 4: Bootstrap MITM Vulnerability en HSTS

Para resolver esto solo hay una solución, y es que todos los sitios que quieren ser HTTPS sí o sí, y que no quieren sufrir suplantaciones de certificados digitales, estén cargados previamente en una lista en el navegador. Es decir, que Google Chrome, Mozilla Firefox, Microsoft Edge o Apple Safari - por citar algunos - tengan una lista de fabrica con todos los dominios que sí o sí tienen que ser HTTPS. 

Figura 5: Pre-Loaded List en el estándar HSTS

Así, cualquier dominio de esa lista pre-cargada en los navegadores que intentara ser accedido vía HTTP porque un atacante hiciera un ataque MITM como el que hacía yo con mi querida Evil FOCA, fallaría tanto si captura la primera petición como si es otra petición.

Figura 6: DefCON 21 Ataques IPv6 con Evil FOCA

Para comprobar si un dominio está en la lista de pre-carga de HSTS, se puede hacer uso de esta web llamada HSTSPreload, y donde puedes poner cualquier dominio para validarlo. En este caso voy a probar el dominio de elladodelmal.com, y como veis me dice que es inseguro.

Figura 7: Análisis de la directiva HSTS Preload en Elladodelmal.com

Y lleva toda la razón. Este blog está hospedado en Blogger de Google, y viene del servicio Blogspot original. Este blog tiene una URL inicial que sigue funcionando que es elladodelmal.blogspot.com que hace la redirección a elladodelmal.com 

Figura 8: Dominios redirigidos a www.elladodelmal.com

Pero también elladodelmal.com hace la redirección a www.elladodelmal.com y si hay peticiones HTTP se redirigen a HTTPs. Pero el servicio de Blogger no deja configurar las cabeceras HTTP para los dominios personalizados, así que no se puede solicitar estar en la lista de precarga.

Figura 9: Configuración HTTPS en Blogger

No obstante, si tu eres el dueño de tu servidor web y quieres evitar un ataque de Bootstrap Man in the Middle, y haces uso de HTTPS y HSTS previamente, puedes solicitar incluir tu dominio en la lista de precarga de dominios para que no haya ninguna primera petición sin HTTP jamás a tu dominio. Para ello, en la cabecera de HSTS debes añadir la directiva preload.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

A partir de aquí, se producirá una validación de que tu servidor contra esa lista si previamente cumples los requisitos para entrar en ella, y se cerrará un ataque más de tu lista de posibles vectores de riesgo. Esto es algo que desde ElevenPaths, en nuestro servicio de pentesting persistente Faast hemos añadido en la última revisión de las directivas de seguridad HTTP para avisar a todos los administradores de dominios auditados.

Figura 10: Lista de requisitos para ser incluido en la lista de preload

Este ejemplo es uno más de los muchos rinconcitos que debes tener protegido cuando pones un servicio en la web, ya que el número de vectores de ataques que existen cuando la superficie de exposición de tu servicio es "todo Internet" es muy alto. 

Figura 11: Libro de Hacking Web Technologies 2ª Edición
escrito por Chema Alonso, Amador Aparicio, Pablo González,
Enrique Rando, Ricardo Martín y Ioseba Palop en 0xWord.

Y os dejo dos cosas que me han venido a la mente. La primera recomendaros el libro de Hacking Web Technologies 2ª Edición para los que os guste el hacking web, y la segunda la charla con el Decálogo de Seguridad Maligno, donde creo recordar que decía eso de "Si tu no auditas tu web otro lo hará por ti... y gratis".

Figura 12: Decálogo de seguridad Maligno por Chema Alonso
Autor: Chema Alonso (Contactar con Chema Alonso)