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).





Un hacker en Corea IV

jueves, 19 de enero de 2017

El Paralelo 38 Norte, Joint Security Area, Panmunjom o DMZ son términos con los que la mayoría de las personas no están familiarizadas, pero sin embargo era uno de los motivos principales de mi visita a Corea del Sur y una de las experiencias más extrañas que he tenido en mi vida, incluso con la nieve que marcó mi llegada al lugar.

Ubicada solo a 50 Km de Seúl, la DMZ o Zona Desmilitarizada es una franja de aproximadamente 240 km de largo por 4 km de ancho que divide la Península de Corea, separando Corea del Norte de Corea del Sur. Recibe su nombre debido a que es una zona sin actividad militar activa y (casi) sin civiles. Los 240 km corresponden al ancho de la Península y los 4 km corresponden a que, durante el armisticio de Paz, cada país debió retraer sus tropas 2 km del frente de batalla, creando una barrera neutral de 4 kilómetros de ancho sobre el paralelo 38.

El Paralelo de Corea fue el antiguo límite entre EEUU y la URSS durante la Segunda Guerra Mundial, antes de la formación de la República Democrática de Corea (Norte) y la República de Corea (Sur) en 1948, y quizás una de las zonas más calientes durante la guerra fría. Actualmente, la parte sur de la DMZ está administrada por Estados Unidos en representación de la ONU, y la parte norte está administrada por Corea del Norte. Por su parte, Panmunjom (hoy en territorio Norte) es el nombre de la villa donde en 1953 se firmó el armisticio; alberga unas pocas familias herederas de aquellas que fueron testigo de tal acto.

Aunque se considera una zona neutral, cientos de veces se han intentado incursiones militares por encima y por debajo de la DMZ, incluso con escaramuzas que se han cobrado algunas vidas. Actualmente se pueden visitar algunos de los túneles que habrían permitido ataques de infantería liviana. Este también es el motivo por el cual el Rio Han (del que hablé en la primera entrega) se encuentra delimitado con tejido y vallas para detectar cualquier tipo de incursión costera o terrestre, ya que con -20° centígrados, el río se congela y es posible vadearlo a pie. En la “zona turística” de visita pública y en el infaltable shopping se encuentra personal militar de los dos países y todavía existe -a modo de recuerdo indeleble- una línea demarcatoria que, curiosamente pasa por el medio de la sala y la mesa donde se firmó el acuerdo en el punto denominado Joint Security Area (JSA). Para una mejor idea se puede leer y ver el libro y la película homónimos.


De esta historia (muy resumida) viene mi fascinación por la DMZ. ¿Quién diría que cuando configuramos servicios, redes y servidores con DMZ, nos caería toda esa historia encima?

Volviendo al mundo de la seguridad, tradicionalmente los tipos de controles se agrupan en físicos, técnicos/lógicos y administrativos. En la DMZ se los puede ver a todos y los mismos son tangibles:

• Vigilancia física: personal militar, perros y cámaras en todo el perímetro.
• Proceso de autorización (AAA): Identificación, mediante la solicitud repetitiva del pasaporte en distintas zonas; Autenticación, contra una base de datos de acceso al país y solicitud de visita a la Zona; Autorización, permiso expreso para visitar la zona por un par de horas; Accountability, registro de las actividades.
• Identificación de personal, administración de roles y permisos, control de acceso de personal no autorizado.
• Procesos para autorización y otorgamiento de privilegios.
• Rotación de personal y tareas.
Firewall físico de 4 km de ancho: división de zona de confianza de la que no lo es:
Need to Know: privilegio para ver y conocer sólo lo que desean y necesitan mostrarte.
• Menor privilegio: todo lo que no está permitido está denegado. Por ejemplo, no se puede usar cámara fotográfica ni teléfonos móviles en la zona.

Seguramente hay cientos de operaciones de control que se me escapan en este momento, pero las mencionadas sirven de ejemplo para confirmar que todas las actividades que desarrollamos en el mundo de la seguridad de la información tienen su fundamento en el mundo físico y siempre es un buen espejo donde mirar.

Otra provincia de interés en Corea del Sur es Jeju. Ubicada al sur del país, en el estrecho de Corea, es la isla más grande de la península y, desde 2011, es considerada una de las Siete maravillas naturales del mundo por la belleza de sus volcanes y la preservación de la biosfera. Su tamaño, aislamiento natural y cantidad de habitantes hace que sea campo de estudio ideal para (el cultivo de mandarinas exquisitas y) diferentes experimentos tecnológicos que luego son extrapolados en el territorio continental. En Jeju, por ejemplo, nació la empresa del mensajero Kakao Talk -que ya mencioné en otra entrega- y se encuentra el Korean Space Wheater Center, responsable del monitoreo de la actividad solar en oriente, tan importante en la detección de radiación y partículas dañinas para el ser humano y las comunicaciones.

Como mencioné en la segunda parte, Jeju es el campo de experimentación de SmartGrid más importante del mundo. SmartGrid es un sistema “inteligente” (porque ahora todo es inteligente) que permite controlar la generación, distribución y consumo de electricidad. A través del intercambio de datos y de técnicas de Data-Minning permite “conocer” los hábitos del usuario para mejorar su experiencia de consumo, aumentar la eficiencia, disminuir la emisión de dióxido de carbono y evitar el calentamiento global.

La combinación de dispositivos de hardware y software hace necesario también la creación de tecnología de control como Latch, el cual permite la protección de concentradores que se encargan de gestionar los Contadores PLC desde el propio diseño de los dispositivos. Con esto en mente, en la Isla de Jeju se encuentran Korea Electric Power Corporation (KEPCO) y Korea Southern Power (KOSPO) que buscan -mediante distintos acuerdos nacionales e internacionales y la instalación de miles de paneles solares y molinos eólicos- llevar adelante una ciudad verde e inteligente que sirva de base para futuros emplazamientos tecnológicos eficientes en Corea, Japón y China.

Seguimos disfrutando de la isla y ya llegamos al final de nuestro recorrido. Pero antes, ningún amante de la tecnología (friki o techie) puede dejar de visitar un museo de computadoras. Para ello fui a Nexon Computer Museum, inaugurado en 2013 y que tiene más de 6.500 aparatos y miles de programas de “aquellos tiempos”. Este museo hace las delicias de quienes crecimos programando en una TI-99, Commodore 64, MSX (existe una discusión si es de origen japonés o coreano) o Apple I o Apple II (en el museo hay una original reconstruida y firmada por Woz); matamos marcianos en el Galaga; caímos cinco pisos en el Prince of Persia; rompimos e intentamos arreglar un Family Game o tildamos un Pinball.


Finalmente, nos mudamos a Busan, ubicada al Sudeste de la península, es la segunda ciudad del país, después de Seúl y dispone de uno de los puertos más importante del mundo por tonelaje de carga y transporte.

Mi llegada a Busan fue en tren a 300 Km/hora, el mismo que aparece en la película de zombies (recomendada para los amantes del género) “Train to Busan”, traducida por el marketing como “Estación zombie” o “Invasión zombie”. Para compensar el ataque de nostalgia tecnológico del museo, y dejando por una vez la seguridad de la información de lado, mi interés por esta ciudad era turístico, por sus playas y belleza natural.

Con esto me despido de Corea del Sur y también de esta crónica en la cual intenté remarcar las principales observaciones realizadas en un país, donde la tecnología es omnipresente y la seguridad es una necesidad de estado, ya sea por la paranoia heredada de la guerra fría o el estado de alerta permanente en el que viven los países de la zona.

En mis tres meses viviendo en Corea aprendí mucho, pero lo más importante es lo siguiente: pretender que conocemos la solución a problemas que no tenemos (por ejemplo, la ciberguerra) es un gran error. En Internet, debemos comenzar a mirar el mundo como un gran globo sin fronteras que, sin embargo, está dividido por barreras tan fijas y firmes como la DMZ.



Cristian Borghello
ElevenPaths Argentina