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)

HPKP: Cuando una medida de seguridad deja de ayudar

Suelo explicar muchas veces en qué consiste la fortificación de un sistema de una manera que pretende ser didáctica. Se reduce a las reglas de aplicación de configuraciones y medidas de seguridad de cualquier servicio en el ejercicio de su rol para ponérselo complicado a cualquier atacante y siempre las contamos de manera sencilla.

Figura 1: HKPK: Cuando una medida de seguridad deja de ayudar

La primera de ellas es Mínima Superficie de Exposición, la segunda Mínimo Privilegio Posible, y la tercera Defensa en Profundidad. Es decir, debemos ejecutar solo el código (y/o los programas que son estrictamente necesarios para la ejecución de su rol. Todos los componentes deben tener el mínimo de permisos necesarios para que si un componente caiga el atacante obtenga el mínimo privilegio del sistema, y se deben aplicar todas las medidas de seguridad por capas que sean posibles asumiendo que las medidas de seguridad anteriores han caído, siempre y cuando una medida de seguridad no anule a otra.

Figura 2: Conferencia sobre gestión de la seguridad informática

Es esta parte en la que "una de seguridad no anule a otra" la que a veces hay que explicar un poco más, y para que la gente lo entienda suelo hablar del uso de NIDS (Sistemas de Detección de Intrusiones en Red) e IPSEC o del uso de WAFS (Web Application Firewalls) y Certificate Pinning. Es decir, cifrar ayuda a prevenir ataques, pero elimina posibilidades a los sistemas de detección de ataques. Una medida da privacidad sobre otra. Sí, por supuesto que se pueden utilizar escenarios más complejos para garantizar que se cumplen las funciones de prevención y detección, pero seguramente necesitemos nuevas tecnologías de seguridad o transformar las medidas que ya tenemos.

Este es el caso del pinning de certificados. Hubo un tiempo en el que las técnicas de Certificate Pinning, es decir, la fijación de un certificado digital en el end-point controlado y utilizado por el servidor se vio como una manera de fortificar la comunicación entre el cliente y el servidor. La idea es simple y poderosa, ya que consiste en decirle al cliente "éste es mi certificado digital y solo éste", si alguien quiere comunicarse contigo con otro certificado digital, ignóralo. Fantástico. Ya no hay alertas, ya no hay forma de que un atacante haciendo un ataque de red en IPv4 o IPv6 pueda meterse en medio de la comunicación. Todo son ventajas. O eso parecía.

Figura 3: Ataques en redes de datos IPv4&IPv6 (3ª edición)
En este libro explico los ataques mitm en IPv6 de Bridging

La realidad es que aplicar HKPK (HTTPS Public Key Pinning) a las opciones de las HTTP Security Headers de los servicios web trajo también un buen montón de problemas que ha hecho que al final los principales navegadores de Internet hayan optado por no soportarla y hacer que HKPK pase al olvido de las medidas de seguridad.

Nosotros, que hemos escrito mucho en el blog de ElevenPaths de Certificate Pinning, de HSTS, HKPK y Certificate Transparency, que son tecnologías complementarias y superpuestas que han ido intentando mitigar el programa del acceso y la manipulación de la información entre un cliente y un servidor. Incluso hemos sacado herramientas como PinPatrol para revisar la configuración de certificados que han llegado vía HSTS y HKPK a tu Firefox, y por supuesto lo hemos aplicado en muchos sitios. Y os garantizo que también hemos sufrido inconveniencias con el pinneo de los certificados, la gestión de la caducidad y la actualización de los certificados digitales por culpa de fallos de seguridad que han aparecido en ellos, etcétera, lo que ha llevado a que tuviéramos serios debates sobre la conveniencia  o no de pinnear los certificados.

De hecho se acuñó un término que se llama HKPK Suicide, que consiste en desplegar y pinnear en clientes un certificado digital y luego perder, por un problema de gestión o seguridad - por ejemplo un ransomware que cifra los archivos del servidor - el acceso al certificado digital, con lo que la conexión con ese dominio se ha perdido para siempre - hasta que caduquen los certificados en cliente - y no hay mucho que hacer.

Figura 4: HPKP Suicide

Por supuesto, no solo por error, un atacante que consigue control de una aplicación web puede inyectar las cabeceras HTTP de seguridad y hacer que se envíe a los clientes el pinneo de un certificado que no existe durante un tiempo enorme, lo que imposibilitaría que hubiera conexión entre el cliente y el servidor. Esto, que se llamó Ransom PKP haría que dejaran de funcionar las conexiones y que solo reinstalando los clientes se pudieran volver a recuperar.

Figura 5: Ransom PKP

Este tipo de ataques se pueden encontrar no solo en entornos en los que se haga un control total del servidor, sino que si aparece una vulnerabilidad de HTTP Header Injection en la aplicación web, se podrían llegar a hacer uso de las cabeceras HSTS o HKPK para hacer exactamente lo mismo. De hecho, algunas variables como max-age que se utiliza para definir el tiempo de vida del pinneo de un certificado digital en el navegador, se han ido limitando para que el ataque no durase años y se limitara solo a un par de meses como mucho.

Figura 6: Hacking Web Technologies

A este tipo de problemas hay que sumar que HSTS con HKPK a veces no ha servido para resolver los problemas, y vimos como aparecían problemas como Delorean que permitían caducar los certificados del almacén de HKPK, o que si eras capaz de interceptar la primera petición HTTP de un cliente a un servidor que utiliza HSTS y HKPK pero que su certificado no viene cargado en el almacén del navegador web del cliente, se podía hacer un ataque de Bridging HTTP-HTTPS, como el que hicimos nosotros entre IPv4&IPv6.

Pero es que además, hemos visto que el uso de HKPK también ha tenido sus contrapartidas. El hacer uso de HSTS ha permitido la aparición de las famosas SuperCookies para espiar a los clientes y romper su validación, además de poder hacer un listado de los sitios web a los que navega un cliente con un sencillo ataque de Time-Based Web Browsing, para medir los tiempos que tarda en ir a un sitio web dependiendo de si tiene ya guardado el certificado digital de ese sitio o no en el almacén HKPK.

Figura 7: HSTS Supercookies

En definitiva, para conseguir mitigar un problema de seguridad hemos ido generando tecnología. Primero HTTPS para poner una capa de seguridad con un túnel SSL a las conexiones HTTP. Luego nos dimos cuenta de que podían eludir el tráfico HTTPs forzando tráfico HTTP, y creamos HSTS (HTTP Strict Transport Protocol), pero nos dimos cuenta de que una navegación HTTPS no tenía porque significar una navegación HTTPS contra el servidor correcto porque se podían utilizar certificados digitales controlados por el atacante y que no dieran alertas, así que creamos el Certificate Pinning y HPKP (HTTP Public Key Pinning) para usar solo "éste" certificado. Y al final tenemos dudas de si hemos generado más problemas de seguridad, privacidad, disponibilidad, y gestión de los que hemos resuelto con esta aproximación, por lo que HKPK desaparece de los navegadores.

Toda esta historia nos tiene que hacer reflexionar sobre la importancia de debatir y analizar correctamente una nueva medida de seguridad en Internet, y del valor de todos los investigadores y hackers que han ido estudiando los límites de las implementaciones que se han hecho. Por un lado tengo la sensación de ver como fracasa una medida de seguridad, por otro lado tengo la sensación de ver cómo avanza la ciencia gracias a todos los que constantemente están buscando los límites de las nuevas tecnologías.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"

Ya os he contado los trabajos que hemos venido haciendo con respecto a los Second Channels, ahora toca hablar de la parte de cómo protegerse contra los ataques en redes IPv4&IPv6. Ni que decir hay que en ElevenPaths, y en mi equipo de Ideas Locas de CDO trabajamos de continuo con todos ellos y hablamos largo y tendido. Desde ataques de Network Packet Manipulation, hasta ataques de phishing homográficos como los PunnyCodes, pasando por los procesos de Ethical Hacking con SSLStrip2 y Delorean o las investigaciones de HSTS, HPKP y Certificate Pinning.

Figura 11: 2FWB: Second Factor Web Browsing
[Parte 2 de 4] "Network Attacks"

Esto hace que la preocupación cuando Mi Hacker o Mi Survivor utilizan mi equipo en una red para conectarse a buscar algo en Internet sea máxima. Me preocupa y, además de fortificar el end-point, reviso periódicamente todo tipo de detalles para asegurarme que se están conectando al sitio correcto, que no hay ninguna inyección de scripts, que el DNS ha devuelto la dirección correcta, que el certificado digital es el que debe, etcétera. Verificaciones que seguramente también hacéis vosotros en vuestro día a día cuando navegáis por Internet.

Conexión Segura & SmartWiFi

Una de las primeras cosas que he hecho ha sido activar el servicio de Conexión Segura en casa. Este servicio permite que toda la navegación que se produce a través la conexión WiFi y la línea de fibra en los hogares con Movistar Fusión, sea analizado (sin romper HTTPs). Como cualquier servicio de seguridad no te da el 100% de garantías, pero sí que te permite añadir una capa de protección a la navegación y filtrar dominios maliciosos, o ataques comunes.

Figura 12: Gestión de Conexión Segura desde SmartWiFi

Este servicio, que se puede activar desde la app de SmartWiFi de forma gratuita para toda la navegación en la WiFi de Movistar, ha detectado ya que la mitad de los hogares, en los cientos de miles de navegaciones que están protegidas a día de hoy, hayan pasado por un contenido malicioso que ha sido bloqueado. Esto es un montón de peligros quitado. Un dominio que sirve un ransomware y es detectado, se bloquea para todos los clientes Movistar Fusión con Conexión Segura y evita que se expanda.

Figura 13: Gestión de seguridad de red WiFi con SmartWiFi

Es una capa de protección transparente para los hogares, y que yo tengo puesto a todos los familiares y amigos. Con un clic estás más protegido por defecto aplicando la seguridad desde un sitio estratégico, la red por la que circula el tráfico.

Un "Second Channel" para verificar el tráfico

Dicho esto, aún me queda el riesgo de todos ataques de red que se produzcan en la red local, o aquellos ataques al end-point que vengan por canales cifrados, o que no sean detectados por la solución EDR (Endpoint Detection and Response). En todos esos caso, además de hacer una fortificación del puesto de trabajo - recomendable el libro de Sergio de los Santos (@ssantosv) "Máxima Seguridad en Windows 4ª Edición" - queda la revisión manual de los mensajes de alerta, de los detalles de las conexiones, etcétera.

Figura 14: Máxima seguridad en Windows [4ª Edición]

Es decir, navegar de forma conjunta con ellas para ver qué está pasando en el equipo con un ojo crítico con el que buscar hasta el más mínimo detalle que pueda ser el indicador de un ataque. Y eso no escala. Mi tiempo no es infinito, y no puedo hacer todas las comprobaciones manualmente siempre, así que había que automatizar este proceso.

Verificar todo significaba estar siempre sentado a su lado y ver todo lo que pasaba. Pero, ¿y si para revisar todo en vez de estar sentado en su mismo equipo usamos de manera continua dos canales? De esta forma podríamos automatizar en otro equipo las verificaciones de "papapete" para saber si estamos sufriendo un ataque de red.

Figura 15: Idea detrás de 2FWB: Second Factor Web Browsing

La primera idea que se me vino a la cabeza fue que estaría bien tener un equipo con dos tarjetas de red, y tener siempre una conexión a él para ir recibiendo en la pantalla lo que está viendo en su navegación. Algo así como los equipos de "manos remotas" que tenemos en muchos equipos importantes en la red de comunicaciones.

Pero la mayoría de los portátiles - como la Microsoft Surface que le tengo puesta a Mi Hacker - viene con la WiFi solo. Podría comprar una segunda tarjeta, pero debería montar en todo momento una red y conectarla a mi equipo también con dos tarjetas, y además mi equipo debería conectarse a otra red distinta. Esto podría ser fácil, porque yo me suelo conectar vía "hotspot" a mi teléfono móvil vía BlueTooth. No es casualidad que se me ocurriera la malvada idea del DirtyTooth que presentamos en RootedCON 2017, era un power-user de ello.


Figura 16: DirtyTooth en RootedCON 2017
Pero para montar esta verificación de la navegación en tiempo real era demasiado lío el tener que poner el equipo de Mi Hacker o de Mi Survivor conectado al mío por una segunda red creada entre ellos y luego conectar mi terminal vía BluetTooth para usar una conexión de red LTE - que vistos los ataques a redes móviles usar otra red no es del todo seguro - que permitiera tener una segunda visión de los servicios de Internet a los que se conectan y verificar que todo está ok.

¿Y si lo simplificamos?

Al final, si tenemos una conexión vía BlueTooth+2G/3G/4G a Internet tenemos siempre un Second Channel en todos los equipos, y la verdad es que yo siempre llevo mi smartphone y todos los equipos que usamos vienen con BlueTooth. Es fácil conectar el equipo que usan mis hijas con mi SmartPhone utilizando BlueTooth y ver dónde están navegando y qué están viendo, para poder comprobar que lo que están recibiendo es lo que deben recibir.

Esta comprobación podríamos hacerla desde el propio termina móvil donde haríamos las comprobaciones, o mucho mejor, haciéndolo desde un servicio en la nube que haría esas verificaciones para todas las instancias de esta app. Las dos arquitecturas tienen ventajas e inconvenientes. Tener toda la lógica en la cloud simplifica la construcción, pero da un elemento más en el sistema que podría ser atacado en un posible esquema de DDOS al servidor en cloud que recoge la inteligencia para detectar los ataques.

Figura 17: Arquitectura de 2FWB con protección de app en smartphone

Por otro lado, tener toda la lógica en el terminal móvil obliga a desplegar nuevas apps o nueva lógica al dispositivo cuando hay nuevas reglas de detección de ataques. Pero hace el atacante deba conseguir vulnerar la red del equipo desde el que se navega a Internet más la conexión a Internet del smartphone. Un doble ataque más difícil de realizar, sobre todo si no estás cerca geográficamente para atacar al dispositivo móvil - ver libro de Ataques a redes de comunicaciones móviles GSM/2G/3G/4G de nuestros amigos de Layak -.

Figura 18: Libro de hacking y seguridad en comunicaciones móviles
GSM/GPRS/UMTS/LTE (2G/3G/4G)

Con es doble canal usando una conexión a Internet de navegación vía red WiFi o Ethernet, y un segundo canal vía BlueTooth+3G/4G, podríamos realizar dos conexiones al mismo servidor desde dos puntos diferentes, usando dos redes distintas. Usar este doble canal tiene cierta similitud con el doble factor de autenticación en los sistemas de login, donde se busca que el atacante deba vulnerar dos elementos distintos para aumentar su dificultad. En este caso, el tráfico del primer canal debe generar respuestas similares y con propiedades similares al que se obtiene por el segundo canal y si no, generamos una alerta.

Esta idea, permite detectar ataques de red en el canal primario, como un DNS Spoofing, un ataque de Phishing, un dominio marcado en un servicio de seguridad como peligroso por usar ficheros JS de  cryptominnig, ataques de bypass HSTS, o de Certificado Falso. Solo necesitamos saber qué es lo que se está recibiendo como respuesta en el canal primario y hacer una comprobación en el canal secundario.

Arquitectura en el end-point

Para conseguir los datos de seguridad útiles para la detección de ataques, necesitamos en el equipo a proteger tener una extensión en el navegador que nos permita capturar las cabeceras HTTP y datos del DOM de la página HTML de la respuesta, más alguna información de red que recibimos del sistema, como direcciones IP resueltas por el DNS, datos del DNS que responde, tablas ARP, etcétera. Toda esta información se captura usando dos elementos.

- Extensión de navegador (en este caso Google Chrome): Este elemento extrae la información que necesitamos del D.O.M. (Document Object Model, y se lo envía al Agente. Además, recibe del Agente las ordenes de bloquear o no bloquear la sesión de navegación con un mensaje de alerta.

- Agente en el sistema (en este caso escrito en Node JS): Establece la conexión vía BlueTooth con el 2FWB y le envía la información recibida de la Extensión del navegador, además de información del sistema para que el 2FWB le diga el resultado de la evaluación. Después, recibe la información desde el 2FWB y manda las órdenes a la Extensión del Navegador para que bloquee o no la sesión.

Con esta arquitectura, tenemos la ocasión de que las verificaciones que haría yo mismo de forma manual para comprobar que está viendo lo que debe de ver en cada momento, de tal manera que si algo no cuadra, o se detecta un fallo en el certificado, el nombre del dominio, la dirección IP del servidor, los ficheros incrustados en el DOM del documento, etcétera, se bloquea la navegación con un aviso que llega a la pestaña del navegador en la que está visualizando el contenido.

View this post on Instagram

Second Factor Web Browsing en #rootedcon }:)

A post shared by Chema Alonso (@chemaalonso) on Mar 29, 2019 at 8:54am PDT

He de decir que hicimos pruebas con BluetTooth Low Energy y con un solo componente basado en la extensión de Google Chrome, pero la realidad es que teníamos dos problemas con esto:

1.- Volumen de datos: Con el protocolo BLE el volumen de datos que podíamos enviar era muy limitado y lo que necesitamos enviar y a la velocidad que lo necesitábamos nos limitaba mucho a la hora de hacer verificaciones de seguridad.

2.- Datos de red del sistema: Para poder detectar ciertos ataques como ARP Spoofing, ataques MITM en IPv6 con SLAAC, etcétera, necesitábamos información del sistema operativo así que necesitábamos un agente en el sistema.

Así que por eso se eligió usar un perfil BlueTooth desde el Agente y tener la extensión de Google Chrome para acceder a la información de la web que se estaba navegando y ver los datos en tiempo real del DOM. Tener las cabeceras HTTP, información del certificado, los archivos scripts inyectados, etcétera es algo que desde la extensión es posible realizar.

Saludos Malignos!

*****************************************************************************************
- 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"
- 2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"
- 2FWB: Second Factor Web Browsing [Parte 3 de 4] "2FWB Mobile App"
- 2FWB: Second Factor Web Browsing [Parte 4 de 4] "Modo Centinela"
*****************************************************************************************

Dos plugins para FOCA OpenSource y uno para Metasploit

Nuestros compañeros del laboratorio de ElevenPaths nos han traído durante estos días atrás dos nuevos plugins para jugar con nuestra FOCA OpenSource y un módulo post-explotación para Metasploit que ataca los sistemas HSTS y HPKP.

Figura 1: Dos plugins para FOCA OpenSource y uno para Metasploit

Los plugins de FOCA OpenSource están ya disponibles en el Market de Plugins de FOCA para que se puedan descargar y comenzar a utilizar desde ya, donde además cuentas con el resto de los ya existentes. Aquí los tienes todos.

Figura 2: Market de plugins de FOCA

El primero de los nuevos es un pequeño plugin para buscar y explotar vulnerabilidades SQLi directamente desde FOCA OpenSource. En el siguiente vídeo tenéis un ejemplo de su funcionamiento.

Figura 4: Demo del Plugin de SQLi de FOCA Open Source

El segundo de ellos permite llevar las direcciones e-mail que FOCA OpenSource va descubriendo al servicio de Have I been Pwned para conocer si han sido leakeadas o no en la red y pueden ser utilizadas en un Ethical Hacking.

Figura 5: Demo del Plugin de Have I Been Pwned

Además de estos plugins de FOCA OpenSource, el equipo del laboratorio ha sacado un módulo de post-explotación para Metasploit que implementan los ataques HSTS y HPKP que hemos estado presentando por ElevenPaths en BlackHat y RootedCON.

Figura 6: HTST Eraser en Metasploit

El módulo lo ha programado nuestra compañera Sheila A. Berta y recoge el trabajo de investigación que llevaos haciendo los dos últimos años en esta materia. En los siguientes enlaces tienes artículos que hablan sobre este tema:

- Certificate Pinning: El qué, el cómo y el porqué 

- HSTS y HPKP: Análisis global y de implementación 

- Breaking Out HSTS (and HPKP) on Firefox, IE/Edge and (possibly) Chrome 

- Revisar la configuración de HSTS y HPKP con PinPatrol

Saludos Malignos!

Revisar la configuración HSTS y HPKP en el navegador de Internet para estar más seguro

Los protocolos HSTS (HTTP Strict Tansport Security) y HPK (HTTP Public Key Pins) dotan a la navegación desde un determinado navegador de Internet a un determinado sitio web de una capa de seguridad extra. El primero de los protocolos, HSTS, le permite indicar a un sitio web que siempre se conecte por HTTPs, evitando que desde el navegador se envíe ninguna petición por HTTP (aunque el usuario o una parte de la aplicación así lo indiquen). El segundo de los protocolos, HPKP el la clave de las tecnologías de Certificate Pinning y le indica al navegador que, no solo debe hacerse la petición vía HTTPs, sino que además el servidor debe tener como clave pública un determinado certificado. Es decir, el servidor web "pinnea" en el navegador el certificado que debe tener el servidor al que se conecta.

Figura 1: Revisar la configuración de HSTS y HPKP en el navegador de Internet

Estas dos tecnologías dificultan sobremanera los ataques de red Man in the Middle, aunque existen algunas limitaciones de la tecnologías que pueden ser aprovechadas por un atacante. Ya vimos como con Delorean se podía hacer caducar una configuración HSTS e incluso un certificado digital "pinneado" con HKPK. Además, ataques como SSLStrip2 pueden aprovecharse de la primera negociación de HSTS para hacer el ataque de man in the middle y robar el tráfico de red.

Figura 2: Cómo ByPassear HSTS con Delorean

Por otro lado, también hemos visto como la configuración de HSTS o de HKPK pueden ser utilizados para dañar la privacidad de los usuarios. En primer lugar, un sitio web malicioso podría aprovecharse del valor de Max-Age de HSTS para crear una supercookie en cada cliente, de igual formar que un atacante podría aprovecharse de la capacidad de HKPK para poner un certificado diferente a cada usuario y saber quién es en cada momento.

Figura 3: PoC que analiza tu historial por la información HSTS almacenada en tu navegador

Por último, haciendo un ataque Time-Based a ciegas, un atacante podría saber cuáles han sido los sitios que se han visitado solo por el tiempo de error al solicitar un recurso vía HTTP de un servidor en el que el tráfico debe ir por HTTPS porque está forzado por HSTS. Saber si el navegador ya tenía la política HSTS configurada o no hace que un atacante remoto pueda conocer su historial de navegación.

Revisar la información HSTS y HPKP de tu navegador

Conociendo las ventajas y los inconvenientes de estas tecnologías, merece la pena saber cómo se pueden consultar las configuraciones HSTS y HPKP que tiene cada uno de nuestros navegadores. Descubrir si te están vigilando o si es posible conectarse a un determinado sitio desde una red WiFi insegura sabiendo que va a ir por HTTPs puede ser de utilidad.

Figura 4: Consulta HSTS y HPKP en Google Chrome para www.Gmail.com

En Google Chrome podemos consultar la información de HSTS y HPKP desde la herramienta net-internals HSTS, tal y como se ve en la imagen superior, donde se ha consultado para Gmail. En Mozilla Firefox, por desgracia no viene nada de serie, pero en el Lab de ElevenPaths hemos creado una herramienta llamada PinPatrol que tenéis disponible en los addons de Mozilla.

Figura 5: PinPatrol para Mozilla Firefox

La herramienta, una vez la instalas, te permite consultar de una vez (mucho más sencillo que andar buscando dominio a dominio) todas las políticas HSTS que están cargadas en tu navegador.

Figura 6: PinPatrol muestra en forma de tabla las entradas HSTS y su información

Además, en el caso de que tengas un certificate pinning con HPKP para cualquier dominio, tendrás también la firma del mismo y la información relevante de él. En este caso, el plugin Calomel del que os hablé para ayudar a conocer detalles de seguridad de un certificado digital.

Figura 7: Entrada HPKP en Mozilla Firefox con datos del certificado "pinneado"

Los campos de la tabla no son complicados de entender, pero en la web del laboratorio los tenéis explicados junto con un enlace para descarga directa.

Figura 8: Plugin PinPatrol en descarga directa con información detallada

Si utilizas Mozilla Firefox para navegar o para tus proyectos de Ethical Hacking, entonces PinPatrol te puede ayudar en todo momento a evaluar cómo están funcionando las políticas HSTS y HPKP de forma sencilla. Además, puedes comprobar esta información con la que obtienes en otro navegador de forma que así sabes si te están instalando una supercookie o no para seguirte.

Saludos Malignos!

Bettercap: Una katana para realizar ataques de red

En alguna ocasión os he hablado de MITMf, un framework que implementa diversos ataques basados en interceptar una comunicación y colocarse en medio de ésta. Últimamente están saliendo herramientas que nos ayudan a automatizar y simplificar las pruebas de auditoria de red. Hoy hablaré sobre Bettercap, una evolución de la famosa navaja suiza de red Ettercap que ayuda a implementar los Ataques en redes de datos IPv4& IPv6. Vamos a verlo.

Figura 1: Bettercap, una katana para realizar ataques de red

Bettercap está escrito en código Ruby y se aprovecha de la flexibilidad y potencial de dicho lenguaje. En la propia página de Bettercap se preguntan, ¿Por qué otra herramienta de MiTM? y los propios desarrolladores explican este hecho porque Bettercap es completo, actualizado, modular, portable y fácil de extender por cualquier usuario. Si alguien argumenta que Bettercap es un Ettercap le contestan lo siguiente:

Figura 2: Explicación de por qué utilizar Bettercap

La instalación de Bettercap es realmente sencilla. Tiene dependencias, pero ejecutando gem install bettercap el proceso se lleva a cabo completamente. En caso de necesitar alguna librería se puede utilizar apt-get para completar el proceso. Una vez instalado, dispondremos de un binario, el cual podremos ejecutar.

Figura 3: Instalacion de Bettercap en un Kali Linux 2.0

Una vez instalado, lo mejor es comprobar todas las opciones que la herramienta proporciona. A continuación se pueden ver las opciones por módulos:

• Spoofing.
• Discovery.
• Sniffer.
• TCP-Proxy.
• HTTP-Proxy.
• HTTPS-Proxy.
• SSLStrip.
• HTTP-Server.
• DNS-Server.

Cada módulo dispone de diversas opciones parametrizables, lo cual hace que la herramienta sea flexible y muy potente. Como primer ejemplo, vamos a ver cómo realizar un sniffing básico, almacenando lo que pasa por la interfaz de red en un fichero PCAP. Además, vamos a aplicar un filtro al sniffer mediante el uso del parámetro –P.

Figura 4: Protocolos que pueden analizarse con Bettercap

Los protocolos “filtrables” se pueden consultar en la documentación del sitio web de Bettercap. A continuación se muestran los protocolos que serán tratados por la herramienta:

PoC: Sniffando con Bettercap y aplicando filtros

En esta prueba de concepto se configura Bettercap como sniffer. Se debe indicar al framework que no se quiere realizar spoofing mediante el parámetro –no-spoofing, tal y como se puede ver en la imagen. Si analizamos el tráfico que genera Bettercap, el módulo de Discovery está habilitado por defecto, por lo que veremos cómo se está realizando un ARP Scan de forma constante. Es decir, enviando ARP Request a todas las direcciones IP de la red. En la imagen se puede ver como la herramienta nos indica rápidamente las máquinas con las que tenemos conectividad, esto es debido al módulo de Discovery.

Con el parámetro –L indicamos a Bettercap que “parsée” los paquetes que llegan al equipo, e implícitamente habilita el modo sniffer, el cual se activa con el parámetro –X. Por otro lado, el parámetro –sniffer-output hace que todo lo que llega a la interfaz se almacene en el fichero, en este caso better.pcap.

Figura 5: Bettercap en modo sniffer

En la propia pantalla se puede visualizar las peticiones que se han realizado, aunque todo queda almacenado en el fichero PCAP. El código de colores ayuda a visualizar la información de manera sencilla y útil.

PoC: ARP Spoofing by default

En esta prueba de concepto configuraremos a Bettercap con el módulo de ARP Spoofing y aplicaremos un filtro para poder visualizar el tráfico que sea solo HTTP o al puerto 80 TCP. El escenario propuesto para esta prueba de concepto es el siguiente:

• Una máquina Windows será la víctima.
• Un router con el que la máquina Windows se comunica para enviar peticiones y tráfico hacia a Internet.
• Una máquina con Kali Linux con Bettercap instalado.

Desde Bettercap ejecutamos la instrucción bettercap –sniffer-filter “tcp port 80”. Esto por defecto activa los módulos de Spoofing, Discovery y Sniffer. Hay que recordar que para no habilitar el módulo de Spoofing habría que indicarlo con el parámetro –no-spoofing. El filtro nos permite filtrar la información no deseada y centrarnos en lo deseado, en este caso, tráfico HTTP. Si quisiéramos realizar un ARP Spoofing contra dos máquinas concretas, podríamos utilizar con el parámetro –T la dirección IP a suplantar, por ejemplo –T 192.168.1.35 y con –G 192.168.1.1 indicamos la dirección IP del router.

Figura 6: Ataque de ARP Spoofing con Bettercap

El ataque de suplantación se puede realizar a través de ARP Spoofing o con ICMP Redirect. Con el parámetro –spoofer se puede indicar ARP, ICMP o NONE. Por defecto, si no se indica se lanzará ARP Spoofing. Además, si no se indican direcciones IP a las que spoofear, el ataque se llevará a cabo contra toda la red de ámbito local y todos los equipos que se encuentren disponibles en la red.

PoC: SSL Strip 2 con Bettercap

En esta prueba de concepto vamos a configurar un SSLStrip+ o SSLStrip2 de Leonardo Nve, el cual viene implementado con Bettercap y se puede utilizar de forma muy sencilla, como ya se vio con MITMf en el artículo de “Ataques man in the middle a HSTS: SSLStrip 2 & Delorean”. Bettercap es compatible con el SSLStrip de Moxie Marlinspike, por lo que también se puede utilizar. Configuramos el módulo de Proxy para reenviar todo el tráfico dirigido al puerto 80 a Bettercap, le indicamos el target con el parámetro –T y con el parámetro –P le indicamos que “parsée” las peticiones POST.

Figura 7: Ejecución de bettercap en modo proxy

El parámetro –proxy-module permite inyectar código HTML, CSS o Javascript. Esto es interesante si se quiere modificar el contenido de un recurso, e intentar ejecutar código del lado del navegador tal y como se hacía con el trabajo de "Owning bad guys {and mafia} using Javascript botnets". Un posible objetivo podría ser la inyección de código HTML con intención de lograr un Phishing en la página o conseguir que el navegador realizara peticiones a un recurso externo el cual devolviera un exploit.

En la documentación de Bettercap viene un ejemplo de lo que se verá cuando el Bypass de HSTS funcione. Sabemos que el bypass de HSTS es parcial y que depende de una serie de condiciones, pero si las cumplimos, la eliminación de la cabecera HSTS por parte de Bettercap es fundamental para que nos funcione el ataque. Recordando las condiciones nos encontramos con:

• El navegador Firefox o Chrome no debe tener cacheado el dominio en su caché HSTS, es decir, el Max-Age no debe estar insertado en el navegador. En caso de que esté cacheado durante N segundos, lo que se indique en Max-Age, las peticiones a ese dominio no se realizarán nunca por HTTP, y serán siempre por HTTPS. 

• En el caso de tener cacheado dicho dominio o esté en una lista precargada, podríamos realizar un ataque de tipo Delorean, creado por José Selvi. Con este ataque se busca provocar la caducidad de dichas entradas en la caché del navegador. Este ataque se logra interceptando peticiones NTP de las máquinas y llevándolas hacia el futuro.

Figura 8: Ataque de HSTS bypass cambiando el dominio de la víctima

En la imagen se puede ver cómo Bettercap muestra “Found stripped HTTPS link”. El módulo de SSLStrip está funcionando y podemos ver cómo todo pasa por nuestro Proxy, el cual hemos arrancado con el parámetro –proxy. Es fundamental el cambio de las “www” a las “wwww”. Estamos apoyándonos en un servidor DNS que está devolviendo la dirección IP del mismo Facebook en este caso.

Figura 9: Ataque ejecutado con éxito saltándose el sistema HSTS

Si analizamos las peticiones POST nos encontramos con información jugosa. Por ejemplo, SSLStrip+ nos ha funcionado y vemos como el usuario introdujo su dirección de e-mail y su contraseña “dadada”. Las peticiones pueden verse en texto plano, cuando en un uso normal estarían protegidas bajo HTTPS, pero de esta forma tenemos acceso al contenido.

Figura 10: Captura de credenciales en texto plano

Conclusión final

Bettercap es una herramienta llena de posibilidades con la que podemos realizar gran parte de los ataques de red modernos y que permite ser ampliada de forma sencilla gracias al lenguaje sobre el que está programada. Sin duda, Bettercap es una de las herramientas que debemos llevar en la mochila en una auditoria interna y/o de red.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”