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

ElevenPaths  23 enero, 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).

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *