Nuevo Informe: Los errores más comunes a la hora de implementar HPKP, HSTS y condiciones de preload

lunes, 23 de enero de 2017

Hemos recopilado y visitado dos fuentes diferentes de dominios y páginas web, el top de Alexa de un millón de dominios y Shodan. Los resultados proceden de búsquedas realizadas en noviembre de 2016. Dentro de ese conjunto de dominios, hemos acotado la búsqueda para determinar aquellos que usan HSTS o HPKP sobre HTTPS, e incluso aquellos que combinan diferentes combinaciones en las cabeceras. Tratando de determinar no solo la cantidad sino la "calidad" de la implementación. Solo el 0,02% de los dominios más populares implementan actualmente HPKP de la forma más correcta, y solo el 0,74% hacen lo propio con HSTS. Incluso Whatsapp.com o Facebook.com comenten errores en sus implementaciones.

A continuación mostramos un extracto del informe que puede encontrarse aquí.

Número de pins

A la hora de implementar HPKP es importante respetar el número de pins requerido. A pesar de que los valores recomendados establecen usar entre 3 y 4 pins, algunos dominios usan desde un único pin (quebrantando la RFC) hasta 17, que resulta una clara irregularidad que reduce la eficiencia. Del top de un millón de dominios de Alexa, 282 de un total de 450 usan 2 o 3 pins, lo cual es correcto. Sin embargo 89 (19,8%) dominios usan uno o ninguno, lo que resulta inútil desde el punto de vista del navegador porque lo ignorará.

Número de pins del top de un millón de dominios de Alexa que usan HPKP.

Qué certificado escoger para realizar los pins

A la hora de usar HPKP, la elección del certificado apropiado es una decisión importante. Los administradores pueden usar cualquier pin en la cadena del certificado (root, intermediate o leaf) pero esta decisión afectará directamente a la usabilidad y también al grado de seguridad tanto desde su punto de vista como del usuario. Debe alcanzarse también un balance y equilibrio entre seguridad y mantenimiento a la hora de efectuar el pinning.
  • Pinning del certificado raíz (root) ofrece menos seguridad, pero a su vez es el mecanismo más sencillo para el administrador a la hora de lidiar con HPKP. Esto significa que, mientras que el proveedor no cambie su CA, no se requerirán cambios adicionales, por tanto, será necesario un menor mantenimiento. Aunque, si un atacante obtiene un certificado falso de la misma CA, el navegador no detectaría la diferencia ya que el root sigue siendo el mismo.
  • Pinning del certificado intermedio (intermediate) es la mejor opción, probablemente. El atacante debería obtener un certificado de la misma CA subordinada (sub CA) a la raíz para lograr un ataque “perfecto”. El administrador, por otro lado, puede cambiar su certificado hoja (leaf) mientras que proceda de la misma entidad subordinada sin cambio adicional a la hora de modificar los pins.
  • Pinning del certificado hoja (leaf) es la opción más segura, pero también la más arriesgada. Si el certificado expira por alguna razón o si cambia (concretamente la clave pública), incluso si ha sido emitido por la misma CA o una subordinada, el administrador tiene que modificar los pins o usar el de respaldo. Por otro lado, un atacante no podría crear un certificado válido (salvo que la clave privada haya sido robada) si desea diseñar un escenario “perfecto” para un ataque MiTM.
Por tanto, hemos comprobado sobre qué certificados realizan los administradores el pinning, y estos son los resultados. La mayoría de ellos (73,65%) usan el certificado intermedio.
Pinning de certificados en la cadena de confianza del top de un millón de dominios de Alexa usando HPKP.


Reutilización de pins

La reutilización de pins entre los distintos dominios no es una práctica incorrecta. Considerando que la mayoría de los pins usados en HPKP son intermedios y se han fijado sobre sub CAs, es absolutamente normal compartir algunos pins entre los dominios. Pero este proceso supone cierto riesgo. Desde el punto de vista del atacante, conociendo las sub CAs o incluso las CAs raíz que poseen pins, esto podría permitirle planificar un APT específico para ese dominio. Por ejemplo, si un dominio emite su certificado intermedio con una determinada sub CA y realiza el pinning de este certificado, un atacante podría obtener un certificado hoja “rogue” para ese dominio emitido por la misma sub CA, produciendo un escenario MiTM perfecto, ya que el navegador no mostrará ningún mensaje de advertencia. Por tanto, desde el punto de vista del atacante, si puede determinar si el pinning del dominio se ha realizado sobre el certificado intermedio, y además, cual es la sub CA concreta, esto permitiría conocer con mucha mayor precisión el objetivo a alcanzar. Además, si el atacante quiere maximizar su alcance, éste intentaría obtener un certificado “rogue” firmado por esta sub CA más “popular”.

El siguiente mapa representa qué certificados (y sus pines) están pineados a más dominios. Esta lista solo muestra los primeros 25. Ya que el protocolo permite saber solo el pin y no el propio certificado, es necesario realizar un "unhash" para conocerlo. Hemos recogido varios millones de certificados y hemos calculado su hash para compararlos con los pines asociados a los dominios. Los resultados muestran cómo el certificado intermedio de Comodo es el certificado más fijado (klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=). Éste posee pins a 40 dominios diferentes de Alexa y Shodan.
Mapa de reutilización de pins. Haz clic para aumentar.

Precarga

Para evitar el problema del TOFU (Trust on first use), se introdujo el mecanismo de “precarga" (preloading). Este trabajo de precarga funciona como una CA raíz incrustada en el navegador. Básicamente es una lista de dominios dispuesta a ser accesible con HSTS desde el primer momento. Esta lista está mantenida por Google y para pertenecer a ella hay que cumplir con ciertas condiciones como son:
  • Tener una cadena de certificados válida y redirigir de HTTP a HTTPS en el mismo host (por supuesto).
  • Servir todos los subdominios usando HTTPS. WWW es obligatorio si existe en el servidor DNS.
  • Servir la cabecera HSTS vía HTTPS con estas propiedades:
    • max-age de al menos 18 semanas (10886400 segundos).
    • includeSubDomains debe ser incluida.
    • preload debe ser incluida.
    • En caso de proporcionar una redirección adicional del sitio HTTPS, se debe usar obligatoriamente la cabecera HSTS (en vez de la que posea la página a la que redirige).
Si todas esas condiciones se cumplen, el propietario del dominio podría solicitar la inclusión en la lista de Google aquí: htstpreload.appspot.com y el dominio podrá eventualmente ser incluido en ella. Esta página web permite también comprobar si un dominio satisface o no esas condiciones. Existen un total de 18197 dominios precargados en la lista Chromium (compartida con Firefox). A fecha de diciembre de 2016, solo 2056 dominios del top de un millón de Alexa están en esa lista.
Estado de la precarga del top de un millón de dominios de Alexa

Funcionalmente, htstpreload.appspot.com proporciona una API pública que permite comprobar las “razones” de por qué un dominio específico debe ser precargado o no. Hemos contrastado el top de un millón de dominios en Alexa con dicha API y la lista de dominios con precarga habilitada, para saber si estos dominios precargados cumplen o no con las condiciones. Para ejecutar este proceso cada dominio se visita en tiempo real y se comprueban los posibles errores. Resulta muy interesante comprobar que, de esos 2056 dominios precargados del top de Alexa, 662 contienen errores, que, estrictamente hablando, no deberían ser precargados. Incluso hemos detectado que, 67 de esos 2056 precargados que están incluidos en la lista, no contienen ni siquiera la directiva de precarga en la cabecera, lo cual viola una de las condiciones de pertenencia. Whatsapp.com y Facebook.com son ejemplos de dominios que no cumplen las condiciones de precarga, pero pertenecen a esta lista.

Muestra del error a la hora de comprobar Facebook contra la API del sistema de preload



Conclusiones

Aunque los protocolos HSTS y HPKP supuestamente deben proveer una capa adicional de seguridad a las comunicaciones HTTPS, su implementación no se ha generalizado. A nivel de servidor, muchos de los dominios más relevantes de Internet ni siquiera los implementan. Además, entre el reducido número de dominios que lo usan, existe un número significante con errores de implementación, incluso pasando por alto las recomendaciones de las respectivas RFCs. Esta situación muestra tanto el bajo índice de adopción de éstos como, de alguna manera, la malinterpretación de cómo aprovechar completamente las ventajas que proporcionan estos protocolos. Algunas de las figuras más interesantes de nuestro informe son:
  • De Alexa, hemos recopilado 632648 dominios HTTPS, y 901958 dominios HTTP. Hemos recogido 30886979 dominios HTTPS (puerto 443) y 45330802 dominios HTTP (puerto 80). Un total de 76217781) de Shodan.
  • Solo el 1,9% de los dominios en Shodan usan HSTS correctamente sobre HTTPS, mientras que solo un 5,35% de Alexa lo hacen.
  • 4717 (apenas un 0.74%) del top de un millón de dominios de Alexa usando HTTPS (632648) implementan HSTS de la forma más correcta.
  • 175 del top de un millón de dominios de Alexa (apenas el 0,02%) usando HTTPS (632648) implementan HPKP de la mejor forma posible.
  • 20% del top de dominios de Alexa usando HPKP sobre HTTPS usan uno o ningún pin, que resulta inútil desde el punto de vista del navegador ya que lo ignorará. La mayoría de ellos (un 73,65%) usan el certificado intermedio para el pinning.
  • 17% de los dominios de Alexa que implementan HPKP usan un valor max-age erróneo o que se ignorará.
  • El pin más usado (un certificado de Comodo) fija 40 dominios diferentes de Alexa y Shodan.
  • Hay un total de 18197 dominios precargados en la lista de Chromium (compartida con Firefox). A fecha de diciembre de 2016, solo 2056 dominios del top de un millón de Alexa están es esa lista.
  • De esos 2056 dominios precargados en el top de Alexa, 662 contienen algunos errores al comprobarlos contra la API oficial de precarga, por tanto, estrictamente hablando, no deberían ser precargados. Whatsapp.com y Facebook.com son ejemplos de dominios que no cumplen las condiciones de precarga obligatorias, pero pertenecen a dicha lista.
Aquí puede acceder al informe completo (en inglés).





No hay comentarios:

Publicar un comentario en la entrada