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)

Wild Wild WiFi "Dancing with Wolves": 2.- SSID Pinning

Continuando el trabajo realizado años atrás con la herramienta Mummy en el paper de "Living in the jungle", y viendo cómo había evolucionado el mundo de las redes Wi-Fi, decidimos hace casi un año probar una idea. En este caso consistía en modificar el cliente Wi-Fi para NO conectarse a redes Wi-Fi cuando estas estuvieran lejos de la ubicación donde se conectaron inicialmente.

Figura 10: Wild Wild WiF "Dancing with Wolves": 2.- SSID Pinning

El objetivo de esta protección es evitar que una red Wi-Fi almacenada en la "Lista de Redes Preferidas" en un sistema operativo - móvil o de escritorio - hiciera una conexión de manera automática. La pregunta que nos surgía era sobre cómo resolver esta comprobación.

3.- La comprobación de la ubicación

La primera opción, evidente, es utilizar el servicio GPS que viene en los smartphones. Crear un cliente Wi-Fi para un smartphone que almacene la ubicación GPS cuando se conecta por primera vez a una red Wi-Fi, y comprobar la ubicación GPS cuando el terminal quiere conectarse automáticamente parecía una solución muy directa. Si la distancia entre la ubicación GPS de la primera conexión y la ubicación GPS actual fuera mayor que un umbral, entonces el cliente Wi-Fi cancelaría la conexión.

Figura 11: Opción de activar GPS Location en iOS

Sin embargo, es conocido que el sistema GPS es susceptible a un ataque de GPS Spoofing, como ya vimos en el trabajo que hizo JAEP Erratum con la suplantación de las ubicaciones en un terminal iPhone. Se puede ver en este vídeo cómo realizando un ataque SDR/RTL es posible configurar el GPS a gusto de cualquier posible adversario remoto.

Figura 12: Ataque GPS Spoofing a un terminal iPhone

No obstante, existen más formas de situar un determinado terminal sin utilizar el servicio GPS, como ya hemos visto en el pasado. En la conferencia de "You are where you are" yo recorría todos ellas en el año 2016. Estas podrían ser:

Figura 13: You are where you are

- Sistema GPS en smartphone: Disponible en terminales iOS o Android. Ya comentado.

- Dirección IP pública de conexión: Existen bases de datos de Geo-Localización IP en las que se conoce dónde se encuentra una determinada dirección IP. Si el AP legítimo da una dirección IP fija de conexión a Internet, se puede utilizar ésta como forma de ubicar dónde se encuentra el cliente Wi-Fi. Como ejemplo de uso, cuando el iPad de Steve Jobs fue robado de su casa, se localizó al ladrón por medio de la dirección IP de conexión que utilizó dicho iPad para conectarse a Apple.

- Wardriving Wi-Fi: La opción que utilizan los sistemas operativos iOS y Android para ubicar correctamente dónde se encuentra un terminal, se basa en analizar los SSID/BSSID próximos al terminal que se quiere localizar. Esa información se envía una base de datos de Wardriving que ubica las redes vistas en una posición GPS del mapa. Además, cada terminal iOS y Android reporta todas las redes Wi-Fi que ve con su ubicación GPS para mantener la base de datos actualizada. Herramientas como iSniff-GPS explicaban este funcionamiento en detalle para iOS.

Figura 14 : iSniff-GPS ubica tu posición en un mapa por las redes Wi-Fi

- Antenas de conexión de telefonía móvil: Una de las formas más seguras de saber dónde se encuentra un terminal móvil en concreto es conocer a qué antena de la red de telefonía móvil está conectado y con que potencia (lo que indica más o menos la distancia a la antena). Esto, con herramientas como Signal de Cydia se podría utilizar para ubicar un dispositivo.

- Patron de descarga de baterías: Este trabajo, titulado PowerSpy, se basa en el uso de analítica predictiva con técnicas de Machine Learning. La idea es entrena un sistema con un montón de terminales móviles haciendo rutas por la ciudad y reportando dos valores (carga de batería y ubicación GPS). Una vez entrenado el sistema, el algoritmo de ML es capaz de, dado un patrón de descarga de batería (es decir, la carga inicial y los delta de descarga a lo largo del tiempo), devolver la ruta GPS que ha seguido por la ciudad.

Figura 15: PowerSpy

Se basa en que, dependiendo lo cerca o lejos que estén los terminales de las señales de telefonía móvil se emite con más fuerza o menos, la señal de conexión a la red de telefonía móvil, lo que incide en un consumo mayor o menor de batería.

Vistas todas estas técnicas, un cliente Wi-Fi avanzado podría utilizar diferentes mecanismos para asegurarse de que está conectándose al mismo AP al que se conectó inicialmente y no a uno falso con los mismo datos que el cliente Wi-Fi que viene por defecto en el sistema tomaría como legítimo. Y por eso trabajamos en el concepto de SSID Pinning.

4.- Las protecciones por redes vecinas y BSSID

Con la idea de enriquecer la información que un cliente Wi-Fi almacena de una red cuando se conecta a ella por primera vez, para poder verificarla cuando el sistema se conecte automáticamente por ser parte de las Preferred Network List comenzamos a trabajar en parámetros fácilmente verificables, como almacenar el BSSID (protección que los sistemas operativos Windows tenían al principio y luego quitaron), o el del Espectro de redes Wi-Fi vecinas.

El concepto de Espectro de redes Wi-Fi vecinas es fácil de explicar. En el punto anterior se explica cómo un dispositivo con iOS o Android envía las redes Wi-Fi vecinas - es decir, las que ve en su alcance - a una base de datos centralizada para saber exactamente dónde está y mantener activa la base de datos. En ese proceso se utilizan los nombres de las redes SSID, los BSSID y las ubicaciones GPS para determinar la posición exacta.

En nuestro caso, no contamos con la base de datos centralizada de Wardriving, pero sí que el cliente puede guardar el espectro de todas las redes Wi-Fi que ve alrededor, con su SSID/BSSID y la potencia de señal. Esto sería una lista de redes vecinas que estarían cerca de la red Wi-Fi a la que el cliente se conecta de forma legítima, y podrá utilizarse como parámetro de seguridad la próxima vez que el sistema operativo quiera auto-conectarse a esta red Wi-Fi. Si el Espectro de redes Wi-Fi vecinas cambia sustancialmente, entonces no se debería realizar la conexión automática.

5.- SSID Pinning

El concepto de Pinning es ya muy conocido en el mundo de la seguridad informática. El Certificate Pinning es uno de los mecanismos de seguridad más utilizados por apps y/o navegadores para evitar utilizar certificados digitales falsos en una conexión SSL. En el mundo de las redes Wi-Fi podíamos hacer algo similar, y a la hora de realizar la primera conexión y meter una red Wi-Fi en la Lista de Redes Preferidas, pinnear, o guardar, una serie de parámetros para verificar la autenticidad de la red Wi-Fi cuando en el futuro se vaya a realizar una conexión automática. 

En la PoC que creamos, y veremos en la siguiente parte de este artículo, utilizamos valores configurables por el usuario, pero si se detectan cambios significativos, el cliente Wi-Fi no permite la conexión automática.

Saludos Malignos!

****************************************************************************
- Wild, Wild, WiFi: 1.- Mummy
- Wild, Wild, WiFi: 2.- SSID Pinning
- Wild, Wild, WiFi: 3.- PsicoWifi
- Wild, Wild, WiFi: 4.- WEP/WPA*-TOTP
- Wild, Wild, WiFi: 5.- WEP/WPA/WPA2-TOTP-Biometry
****************************************************************************

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!

¿Por qué sale el candado rojo en los mensajes de Gmail?

Supongo que muchos ya estaréis al día de que Gmail ha añadido una nueva función para mejorar la información sobre los mensajes de correo electrónico que recibe de forma insegura. Si todavía no has visto ninguno, te recomiendo que vayas a la carpeta de Spam de tu cuenta de Gmail y busques por allí, verás que hay más de uno seguro que tiene el candadito rojo de correo inseguro.

Figura 1: ¿Por qué sale el candado rojo en los mensajes de Gmail?

Ese candado rojo abierto al lado del mensaje significa que la conexión que el servidor de correo saliente del dominio del remitente hizo con el servidor de correo entrante de Gmail no se hizo sobre un túnel TLS o SSL. Es decir, cuando se entregó ese mensaje de correo electrónico a Gmail para que lo pusiera en tu buzón, se hizo por el puerto 25 sin cifrado alguno, por lo que cualquiera que pudiera esnifar el tráfico de la red en medio podría haberlo leído.

Figura 2: Mensaje enviado por SMTP sin cifrado puerto 25

Esto lo tienes explicado en la página de soporte que ha añadido Google en su knowledge base, y no hay mucho que puedas hacer a nivel de usuario para que tus correos electrónicos lleguen sin candado, ya que es algo de configuración del servidor de correo electrónico que utilizas para enviar los mensajes.

Figura 3: Explicación de Google sobre el candado rojo

Si cuando envías un mensaje de correo electrónico llega a las cuentas de Gmail con el candado, entonces es que tu servidor de correo electrónico no has configurado el servidor SMTP de correo saliente para que envíe todo el tráfico cifrado.

Figura 4: Información sobre los puertos con cifrado en Gmail para SMTP

Para ello, debes hablar con tu proveedor, o si gestionas tú el servidor de correo electrónico activar la opción de conexión TLS o SSL por los puertos 25 o 465 con SSL yo 587 con TLS. Ojo, si tu cuenta es de Gmail, actívalo si tus mensajes llegan con ese candado, que podría ser que hubieras configurado tu cliente de correo electrónico con SMTP en lugar de IMAP.

Figura 5: Conexión a tu buzón usando IMAP con SSL para enviar y recibir e-mails

Por supuesto, esto no garantiza que el correo electrónico no haya podido ser interceptado por alguien en medio que haga un ataque de man in the middle con capacidad de tener certificados emitidos a nombre de los servidores de correo electrónico, tal y como se explicaba en este gráfico de servilleta que apareció en uno de los documentos filtrados por Edward Snowden.

Figura 6: Explicación de Muscular de la NSA para espiar Gmail

Si no hay un proceso de Certificate Pinning entre los servidores de correo electrónico saliente y servidor de correo entrante, entonces el atacante podría dar al servidor de correo saliente un certificado falso emitido por una entidad certificadora controlada en la que confíe el servidor de correo saliente y descifrar los mensajes.

Figura 7: Correo de Gmail enviado sin cifrar

Gmail entre sus servidores utiliza autenticación mutua, pero si el servidor viene desde un servidor de correo saliente de tercero entonces solo hay conexiones SSL o TLS, pero no Mutual SSL o Mutual TLS, ya que para ello debería haber un intercambio de certificados entre ambos servidores a nivel de configuración.

Figura 8: Gmail permite las conexiones SMTP puerto 25 sin cifrado

Este es un esfuerzo más desde de Google por cifrar el tráfico de Internet y ayuda a evitar la interceptación de correos por parte de atacantes, pero desde luego, mientras que no haya Mutual TLS/SSL entre todos los servidores de correo electrónico, los estados podrán seguir espiando el correo como lo hacían antes y la única solución sigue siendo usar PGP o S/MIME para tener cifrado end-to-end, así que, el que no salga el candado no garantiza que nadie haya podido espiar ese mensaje desde que salió del cliente de correo electrónico del remitente. Si quieres saber más sobre criptografía, ya sabes que una lectura recomendable es el libro de Cifrado de las comunicaciones digitales.

Saludos Malignos!

Time-Based Web Browsing History Disclosure using HSTS & Tracking with HPKP (HTTP Public Key Pinning) Cookies

Este fin de semana ha tenido lugar la conferencia ToorCON en San Diego, unas conferencias en las que tuve el placer de participar hace ya unos 6 o 7 años. En ella un investigador ha publicado un para de vulnerabilidades de lo más inteligentes que pueden utilizar los sitios web para espiar la navegación de los usuarios.

Figura 1: Abusando de HSTS para espiar la navegación de los usuarios

Ambas técnicas, aprovechando la estructura de navegación cifrada usando HTTPs, abusando en ambos casos de HSTS (HTTP Strict Transport Security) para conseguir sacar información del historial de sitios visitados y para conseguir crear una supercookie. 

Time-Based Web Browsing History Disclosure using HSTS

Cuando un sitio web hace uso de HSTS, se lo notifica al navegador mediante un HTTP Header que envía al navegador en el que le informa de que a esa página web solo se puede conectar usando HTTPs, por lo que el navegador rechazará cualquier intento de conexión que se haga a ese sitio utilizando HTTP. Conocido esto, el investigador Yan Zhu hace uso de una función JavaScript que, pasada una lista de sitios web que utilizan HSTS, intenta conectarse a ellos pidiendo una imagen que no existe en el servidor web por medio de HTTP.

Figura 2: Configuración de HTTP Header de HSTS en Gmail

La conclusión es sencilla, si el sitio ha sido visitado previamente y no ha caducado el TTL - de forma natural o por un ataque vía NTP usando Delorean - que se marca en el HTTP Header de HSTS, entonces el navegador generará un error muy rápidamente y navegará vía HTTPs, ya que sabe que no puede conectarse vía HTTP a ningún recurso de ese dominio. Si por el contrario el sitio no ha sido visitado recientemente, entonces se tiene que producir la petición al servidor web del recurso solicitado para configurar HSTS y luego pedir el recursos, obteniendo un error con un tiempo de respuesta mayor.

Figura 3: Sniffly saca una lista de sitios con HSTS que puede que hayas visitado y que no

El atacante solo debe medir los tiempos de los errores para poder hacer un ataque de Time-Based Web Browsing History Disclosure basado una lista de sitios a consultar. Eso sí, esta técnica solo vale para sitios que hagan uso de HSTS. Para que lo pruebes, ha publicado una Prueba de Concepto online llamada Sniffly.

Tracking with HPKP (HTTP Plublic Key Pinning) en Google Chrome

La segunda de las vulnerabilidades se trata de una nueva supercookie que se puede crear en los navegadores Google Chrome. Ya conocemos desde algún tiempo la posibilidad de dejar una SuperCookie en los TTL de los HTTP Headers de HSTS, pero ahora el investigador hace un abuso de la implementación HPKP que no es más que la implementación de las técnicas de Certificate Pinning en Google Chrome. La idea es que HPKP permite poner un certificado distinto para cada usuario y lo que hace el ataque es generar un cadena de identificación distinta para cada uno de estos certificados.

Figura 4: Implementación de HPKP en Google Chrome. Consulta de Gmail.com

Así, cuando el cliente se conecta la primera vez, este recibe vía HPKP un certificado con un pineo de backup con un TEXT configurado. Después, cada vez que se conecta se fuerza un error y esta cadena de TEXT  e envía vía "report-uri" al servidor que se ha configurado. De esta forma tenemos una SuperCookie usando HPKP en Google Chrome. 

Las dos técnicas son muy curiosas y de gran aplicación hoy en día en todos los sistemas de WebBrowsing FingerPrinting para los entornos de tracking publicitario, seguimiento de huellas digitales y scoring de riesgos, por lo que no os debe caber la menor duda que desde ya van a empezar a estar en uso de forma masiva.

Saludos Malignos!

Bug en OpenSSL: Alternative chains certificate forgery

Llevábamos unos días analizando qué podría ser el nuevo bug que había sido anunciado en el proyecto OpenSSL en un parche nuevo. Después de un año y medio movido, con HeartBleed de por medio, todos estábamos listos para ver qué podría ser este fallo. En Eleven Paths habíamos incluso organizado una vigilancia especial por si en había que sacar una Prueba de Concepto rápido para nuestros sistema de pentesting persistente. Pero al final, aunque es de riesgo muy alto, no será tan crítico como lo fue Heartbleed que permitía robar datos masivamente.

Figura 1: Alternative Chains Certificate Forgery en OpenSSL

El fallo que se ha anunciado en OpenSSL se ha bautizado como Alternative Chains Certificate Forgery y se le ha asignado el CVE-2015-1793. El problema se encuentra en la forma en la que algunas versiones de OpenSSL verifican la cadena de confianza de un certificado digital. Es decir, salvo que se haga una implementación de un proceso de Certificate Pinning, un certificado digital se da por bueno si está firmado por una cadena de certificados que lleva a una raíz de confianza.

Verificación de la cadena de confianza

En un certificado A, si esté está firmado por un certificado B, emitido por una entidad certificadora de primer nivel C de la que se confía, entonces se dará por correcto y no se lanzará ninguna alerta de seguridad. Esta validación de certificados se produce tanto cuando un navegador cliente tiene que verificar el certificado de un servidor web, como cuando un servidor tiene que verificar el certificado de un cliente en un proceso de autenticación de usuarios basado en certificados digitales.

Figura 2: Bug de Alternative Chains Certificate Forgery en OpenSSL

Sin embargo, el bug de Alternative Chains Certificate Forgery permite que, en determinadas condiciones y en 4 versiones en concreto de OpenSSL, se pueda hacer que esa verificación de cadena de confianza hasta un certificado raíz se de por buena aún no siendo correcta del todo la cadena de certificación.

Entornos de explotación

En otras palabras, alguien podría usurpar la identidad de un servidor si el cliente utiliza el software de OpenSSL en el cliente (no lo usan Apple Safari, Internet Explorer, Chrome o Firefox, pero sí muchas aplicaciones móviles o de escritorio clientes) que combinado con un ataque de phishing o pharming ayudarán a robar datos de cliente, o lo que es más peligroso aún, alguien podría suplantar el certificado de un cliente en un entorno de autenticación de usuarios basado en certificados digitales como si se pudiesen crear todas las credenciales a gusto -

Figura 3: Configuración de autenticación de cliente SSL en servidor NGINX con OpenSSL

Este último escenario es el realmente peligroso, ya que se podría conseguir acceder a sistemas informáticos creando los certificados adecuados de los usuarios que tienen acceso a la plataforma. Por esto, es necesario que se actualice cuanto antes el software si estás haciendo uso de este tipo de autenticación en tus plataformas.

Saludos Malignos!

Certificate Pinning: Un estudio sobre el estado del arte

En la última RECSI (Reunión Española de Criptografía y Seguridad Informática) 2014 que tuvo lugar en Alicante, participamos con un par de trabajos que puedes encontrar en el canal Slide Share de Eleven Paths. Uno de ellos estuvo centrado en las técnicas de Certifica Pinning, titulado: "Contramedidas en la suplantación de identidades. Certificate Pinning", que puedes descargar y/o leer en formato PDF.

Figura 1: Un estudio del estado del arte de las técnicas de Certificate Pinning

Las técnicas de Certificate Pinning se basan en extremar las medidas de protección a la hora de aceptar por bueno un certificado digital en una conexión segura. Hasta que comenzaron a extenderse los navegadores y/o sistemas operativos venían con un almacén de las claves públicas pertenecientes a las entidades de certificación en las que se confía, y la validación de un certificado digital enviado desde cualquier servidor se basa en analizar la cadena de confianza de certificación para ver si termina en uno de los certificados almacenados en los que se confía.

Figura 2: Contramedidas en la suplantación de autoridades de certificación. Certificate pinning

Podríamos decir que el proceso de tener la lista de certificados digitales de las entidades de confianza es el pinning "clásico", pero con la aparición de certificados falsos para dominios populares, como los que vimos que aparecieron tras el robo de la entidad certificadora Diginotar, el posible uso de entidades de certificación intermedias, o la creación de certificados falsos por medio de colisiones de hashes, tal y como se vio en el caso de The Flame o en el reciente caso de los certificados de Windows Update, lo cierto es que parece que no basta solo con pinnear el certificado de la entidad, sino el certificado concreto del servidor al que nos conectamos completamente.

Figura 3: Posibilidad de hacer Certificate Pinning con EMET en Windows

Cuando lo que se guardan son los certificados únicos de los servidores, y se hace una validación de toda la clave completa en cada conexión, es entonces cuando se está realizando Certificate Pinning, algo que se ha hecho muy popular entre los expertos en seguridad. De hecho, la herramienta EMET que se usa para maximizar la seguridad de sistemas Windows permite hacer Certificate Pinning, y para que fuera muchos más sencillo de usar, desde el laboratorio de Eleven Paths lanzamos EMET Rules para hacer Certificate Pinning a todo Internet - si quieres - hace ya algún tiempo.

Figura 4: Plugin DNSSEC TLS Validator para Firefox

En el blog de Eleven Paths le dedicamos una serie completa a Certificate Pinning: El qué, el cómo y el porqué. En ese trabajo se habla también de algunas implementaciones enfocadas en validar los certificados digitales por otras vías, como son DANE( DNS-Based Authentication of Named Entities) o TACKS (Trust Assertions for Certificate Key).

Figura 5: Fallo de Certificate Pinning en Mozilla Firefox explicado en el Blog de Eleven Paths

Todos estos puntos, así como la aplicación de estas técnicas en los navegadores Google Chrome, Internet Explorer y Firefox - incluida su última implementación de Certificate Pinning con dudoso éxito - se tratan en detalle en ese artículo, así que si te interesa conocer más sobre estas técnicas, es la lectura de este sábado para tu e-book reader. Seis páginas en Español que te permitirán tener una idea clara del estado del arte en técnicas de Certificate Pinning.

Saludos Malignos!

Comprobar el certificado digital SSH por canal paralelo

Durante este mes se ha publicado en la lista de Bugtraq una pequeña herramienta vía web que realiza una comprobación paralela a la firma del certificado que se sirve por SSH. Esto es útil cuando hablamos de una primera conexión, en la que el certificado aún no está guardado y pineado en la base de datos local del cliente y, por tanto, no puede garantizarse que sea el servidor correcto. Un atacante podría hacer un man in the middle y entregar otro certificado digital.

Figura 1: Error de reconocimiento de clave en conexión SSH

Lo que propone la herramienta es tener en un servidor web una segunda verificación, que por medio de una comprobación por medio de otro canal se compruebe el certificado. Si el fingerprinting de los certificados no es el mismo, se estaría ante un ataque de man in the middle y habría que evitar realizar esa conexión. Esa disponible es CheckSSH.com y lo único que hay que hacer es enviarle la dirección IP o el nombre de dominio del servidor que se quiere comprobar, y la herramienta devuelve el fingreprinting que ella ve.

Figura 2: Servicio Check SSH

En el debate se planteaban muchas cosas, como por ejemplo que el atacante tuviera un man in the middle en el canal de conexión a la web, además de en el canal de la conexión al servidor SSH, que hubiera un bug en el servidor web donde se aloja este código de comprobación o simplemente que los que gestionan este servicio sean los que están haciendo el man in the middle. En cualquier caso de estos, la víctima tendría una falsa sensación de seguridad que ayudaría al éxito del ataque.

Figura 3: Código fuente del servicio CheckSSH para que lo pongas en tu servidor

Con el objeto de disipar las dudas, el servicio lleva HTTPs con un certificado de validación extendida y podrías hacer un Certifiacte Pinning con él. Pero el 100% de certeza, tal y como se plantea el mundo hoy en día es casi imposible. No obstante, han publicado el código fuente del servicio que corre en la web, así que puedes montártelo en tu propio servidor y diseñarte el esquema de seguridad que más se adapte a tus requerimientos gestionándolo tú mismo.

Saludos Malignos!

EMET Rules: Haz Certificate Pinning a todo tu Internet

Una de las herramientas de las que más se habla en el libro de Máxima Seguridad en Windows es Microsoft EMET. Esta solución que está ya en su versión 4.1, de nombre Enhanced Mitigation Experience Toolkit, permite a los administradores más avanzados y a los usuarios más preocupados por la seguridad aplicar las más modernas técnicas de seguridad en la fortificación del sistema frente a nuevos exploits o ataques. En su última versión es posible, entre otras cosas, es posible configurar Certificate Pinning para que se generen alertas cuando un certificado digital cambie.

Figura 1: Certificate Pinning está disponible en EMET v4.0

Las técnicas de Certificate Pinning se basan en instalar la clave pública del servidor web que se quiere controlar, para que si en cualquier momento el navegador envía un nuevo certificado digital se genere una alerta en Internet Explorer. Esto evitaría los problemas que tiene HTTPs en ataques de Fake CA o BasicConstraints, así como los problemas asociados al esquema de cadenas de confianza, donde cualquier entidad certificadora podría generar un certificado para cualquier sitio web.

Figura 2: Proceso de hacer Certificate Pinning con EMET v4

Hacer esto en EMET no es demasiado cómodo, así que desde el laboratorio de ideas en Málaga de Eleven Paths se ha trabajado en una pequeña herramienta que se llama EMET Rules y que permite a los administradores algo tan cómodo como darle una lista de URLs con certificados digitales a "pinnear" y que la herramienta se ocupe de todo el trabajo, es decir, conectarse al servidor, descargarse el certificado digital actual en la web y configurar las reglas necesarias en EMET.

Figura 3: EMET Rules configurando Certificate Pinning de múltiples sitios en EMET v4

La idea es que este proceso se haga en un entorno en el que la conexión de red y los certificados a descargar se consideran seguros, para que después se detecten los cambios en los certificados digitales en el resto de conexiones para detectar cualquier intento de ataque man in the middle. La herramienta se ha hecho en modo comandos para poder ser lanzada en múltiples entornos y usada incluso en scripts automatizados de PowerShell y  puede descargar desde el blog de Eleven Paths, donde además tenéis un manual de todos los comandos de la herramienta.

Saludos Malignos!