Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
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.
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.
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)
