HSTS vs; MITM Attacks & SSLStrip


 

HSTS, BLOG - 002

HSTS, BLOG - 003

A menudo todos – o casi – escucháis, leéis que debéis, al menos, estar “seguros” de que vuestra <navegación> viaja sobre “HTTPS” a la hora de introducir <Passwords> (contraseñas) o tratar de acceder a sitios de “información confidencial” (ya sabéis; bancos, compras, etc). Pero, seguro que en alguna que otra ocasión os habéis preguntado.. ¿será mi conexión “HTTPS” realmente segura?. Una cosa está clara, hoy por hoy en las <tecnologías de la información>  no se puede constatar un “100%” de seguridad y siempre se ha de estar pendiente (atento) de esa multitud de circunstancias que nos rodean y que pueden ser aprovechadas para vulnerar dichas comunicaciones.

En esta ocasión (artículo) veremos un “ataque” muy clásico pero bastante eficaz contra “conexiones seguras” (sslstrip) y un <mecanismo> reciente que lo mitiga (hsts).

Vayamos pues al lío 😉

Nota I: Qué nos dice nuestra amiga “Wikipedia” respecto a la definición “HSTS“;

HSTS, BLOG - 004
Captura 1: DefiniciónHSTS” (Wikipedia) 🙂

HSTS, BLOG - 005

El “ataque” de <hombre en el medio> o “MITM” (del inglés Man in the Middle) es una de las técnicas mas frecuentemente utilizadas por su implementación, relativamente sencilla, y por la eficacia de sus resultados. No obstante, el uso de “SSL/TLS” y el uso de <criptografía>  en las “comunicaciones” ha puesto siempre en <jaque> este tipo de “interceptación de tráfico”. Ante esta dificultad los <ataques> han tratado de sacar partido de debilidades en las “suites de cifrado” negociadas en una <conexión segura>, como “BEAST“, <CRIME> o “BREACH” o en <vulnerabilidades “SSL”> como “Heartbleed“. Actualizaciones, parches y otros condicionantes hacen que estas circunstancias no sean, en general, sencillas de explotar.

HSTS, BLOG - 007
Captura 2: AtaqueMan in the Middle” (esquema) }:P

Otra <técnica> muy “conocida y utilizada” ampliamente durante un buen periodo de tiempo es <SSLStrip>. SSLstrip fue presentado por Moxie Marlinspike en la Black Hat 2009, y demostraba una genial idea para interceptar conexiones <HTTPS>  donde, en lugar de atacar el “cifrado” entre el <cliente y el servidor> se engaña al cliente, interponiéndose en mitad de la conexión. De este modo, <SSLStrip> hace de pasarela, intercepta el “tráfico HTTP”, evita que llegue un mensaje de <redirección> a “HTTPS” por parte del <servidor> y a continuación establece y mantiene “dos conexiones”: una “HTTP” sin cifrar con el cliente (víctima) y otra con el servidor <HTTPS>, manejando las “cookies y la sesión” para hacer creer a la víctima que está bajo una conexión segura cuando en realidad todo el tráfico va <sin cifrar>.

HSTS, BLOG - 006

Durante un buen periodo de tiempo esta técnica dio excelentes resultados puesto que, para el servidor todo era correcto (conexion segura) y para también para el cliente, el cual no es consciente de que la conexión no es cifrada. Algunas <contramedidas> contra este “ataque” pasaban por utilizar <plugins> de navegador para forzar “HTTPS” hasta que apareció una mejora en el protocolo denominada “HSTS“.

HSTS, BLOG - 008

HSTS, <acrónimo> para “HTTP Strict Transport Security”, nace con el objetivo de evitar  “ataques” de interceptación en conexiones <HTTPS>. La idea principal es introducir una nueva cabecera “HTTP” denominada <Strict-Transport-Security>, la cual puede ser enviada por un servidor al navegador cliente para fijar una política que obligue a usar únicamente conexiones seguras “SSL/TLS” y de como manejar las mismas con el servidor. En una política <HSTS> hay dos parámetros principales;

HSTS, BLOG - 009
Captura 3: PolíticaHSTS” (parámetros) 😉

Un ejemplo de la cabecera de respuesta <HSTS> de conexión  con un “servidor web” puede ser  el siguiente;

HSTS, BLOG - 010

Este campo de la cabecera establece que ,durante un año (max-age=31556926) tanto el <dominio> solicitado como todos sus “subdominios” (includeSubDomains) han de ser accedidos únicamente utilizando <HTTP’s>.

Adicionalmente, una política “HSTS” también previene que un usuario pueda aceptar un certificado <autofirmado> o cualquier “irregularidad” al registrarse y recordarse la CA que firma un <dominio> ya visitado.

Un aspecto importante a tener en cuenta es, que cuando se visita por primera vez un servidor con <HSTS> se recibirán la cabecera “Strict-Transport-Security” y los parámetros fijados, momento desde el cual  el navegador reconocerá el sitio y aplicará la política “HSTS” hasta su expiración. Esta primera visita es un punto vulnerable puesto que aún el navegador no tiene información sobre el sitio en concreto. Lo mismo ocurre cuando la política caduca.

De este modo al igual que hace “SSLStrip” con el manejo de una  sesión <HTTP’s>, en un “ataque <man in the middle<” se podrían eliminar las cabeceras “HSTS” en la primera visita (vulnerabilidad “Bootstrap <man in the middle>”)  y así de este modo evitar que el navegador reciba esta notificación y aplique una política estricta. Sin embargo del mismo modo que en la parte servidora, también es posible  establecer en el navegador (parte cliente) “listas precargadas” de <dominios>, a los que se aplicará una política estricta independientemente de que sea la primera vez que se visita el sitio “HTTPS”. Este mecanismo evitaría el <Bootstrap “man in the middle”>. En algunos navegadores se pueden consultar y/o añadir elementos de estas listas, por ejemplo en Chrome accediendo a la URL;

HSTS, BLOG - 011


HSTS, BLOG - 012

Resumiendo…. ¿podemos considerar <HTTP “Strict Transport Security”> el mecanismo que acaba definitivamente con los “ataques <SSLStrip>” y similares?. No, y tal y como se describe en el propio “RFC de HSTS” existen diversos vectores de <ataque> entre ellos ataques basados en “NTP” o <DNS poisoning> y que convenientemente explotados pueden servir para evitar la protección ofrecida por “HSTS”.


HSTS, BLOG - 013.png


TonyHAT - 435

Anuncios

Un comentario en “HSTS vs; MITM Attacks & SSLStrip”

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s