Certificate pinning. El qué, el cómo y el porqué (III)Sergio de los Santos 3 septiembre, 2013 Después de aclarar conceptos en las entradas anteriores de esta serie sobre certificate pinning (las cuales puedes encontrar al final de este post) acerca de las debilidades de las PKI, el TLS/SSL en general y la solución propuesta por EMET, veamos cómo han implementado el concepto los diferentes fabricantes: es el turno de Chrome. Chrome es el primero que se preocupó por integrar el pinning en su navegador. No es de extrañar cuando fue uno de los dominios suplantados en el conocido ataque de 2011. Además, Google es un objetivo muy goloso para cualquiera que quiera espiar comunicaciones cifradas. Chrome usa fundamentalmente dos tecnologías diferentes que parece que se complementan. La primera es el estándar HTTP Strict Transport Security o HSTS. Se trata de una especificación que permite obligar a que, en una página, se use siempre HTTPS aunque el usuario no lo escriba en la barra del navegador. Para ello, el servidor que lo desee debe enviarle una cabecera al navegador, del tipo: Strict-Transport-Security: max-age=16070400;includeSubDomains Chrome (en realidad todos los navegadores populares menos Internet Explorer) entenderán que la página que envía esta cabecera quiere que se navegue por ella siempre con HTTPS (aunque el usuario no lo haya especificado) y durante el tiempo definido. Hasta aquí, no se habla de certificados, así que, ¿por qué lo unen a la funcionalidad de pinning? HSTS y pinning La respuesta a la pregunta anterior es la siguiente: porque esta opción de la página para ser navegada por HTTPS (lo quiera o no el usuario) la envía el servidor y se guarda en local. Se da un primer contacto del usuario al servidor en el que todavía no se ha recibido esa cabecera, esa petición no está protegida, hasta que se reciba la respuesta y la recuerde el navegador. ¿Y si un atacante ya controla la red desde esa primera solicitud sin HTTPS, intercepta esa primera petición y desvía el tráfico o elimina la cabecera? Siempre habrá una ventana de tiempo inicial en la que un ataque es posible. Así que Chrome ha incorporado en su código fuente páginas que siempre funcionarán con HTTPS activo, desde el principio: «Preloaded HSTS sites» las llama. Esa lista se comparte con Firefox y cualquier dominio puede solicitar que se le incluya en el código fuente como «precargado con HSTS», enviando un email a alg@chromium.com. Ya hay muchos (se ve en el código fuente). Con esto se consigue que, nada más arrancar Chrome, se vaya al dominio HTTPS de la página, y a partir de ahí (que se supone que es el sitio autenticado) continuar. Esto también es una especie de pinning. Si el dominio lo desea, puede dejar de enviar la cabecera en cualquier momento, y el navegador ya no obligará al uso de HTTPS. Este sistema es interesante, pero el hecho de utilizar el código fuente como «repositorio» de páginas que quieren usar «HSTS precargado» desde el primer momento no parece muy sostenible a largo plazo. ¿Están cubiertos todos los flancos? Ahora bien, sigue existiendo un punto débil. ¿Y si, aunque siempre se contacte desde el primer momento con estos dominios con HSTS (y por tanto con SSL activo) en una red muy hostil, ya se ha producido el ataque MiTM y se le redirige a una web cifrada diferente? Puede ocurrir que se la víctima visite un dominio HSTS preinstalado, pero pase por una red donde la cadena de certificación sea válida pero no la original (se le esté espiando)… ¿Y si cuando el navegador acude obligatoriamente al dominio autenticado, la autenticación no es real porque se están usando certificados intermedios diferentes o se han emitido falsos? Ahí entra el certificate pinning propiamente dicho. El navegador, además de exigir SSL desde el primer momento, independientemente de que el usuario escriba HTTPS en la barra de direcciones, recordará qué claves públicas le son reconocidas y rechazará el resto. ¿Cómo funciona todo esto en la práctica? Veremos algunos ejemplos técnicos de cómo funciona el «pinneo» de Chrome en la siguiente entrega: Certificate pinning: el qué, el cómo y el porqué (IV) Y no te pierdas los posts anteriores de esta serie sobre certificate pinning: Certificate pinning: el qué, el cómo y el porqué (I) Certificate pinning: el qué, el cómo y el porqué (II) Más contenido sobre certificados digitales en este post: https://empresas.blogthinkbig.com/todo-necesitas-saber-sobre-certificados-ssl-tsl/ Certificate pinning: el qué, el cómo y el porqué (II)Certificate pinning: el qué, el cómo y el porqué (IV)
Daniel Pous Montardit Resiliencia, clave en sistemas Cloud-Native En el primer post de la serie Cloud-Native, ¿Qué significa que mi software sea Cloud Native?, presentamos la resiliencia como uno de los atributos fundamentales que nos ayudan a...
Telefónica Tech Boletín semanal de Ciberseguridad, 21 – 27 de enero Killnet apunta contra objetivos en España Esta semana el grupo hacktivista Killnet anunció una campaña de ataques contra Alemania, dando lugar a la realización de ataques de Denegación de Servicio...
Gonzalo Fernández Rodríguez ¿Qué significa que mi aplicación sea Cloud Native? El término Cloud Native es algo que va más allá de mover las aplicaciones alojadas en un data center a una infraestructura proporcionada por un proveedor Cloud, sea Cloud...
Telefónica Tech Boletín semanal de Ciberseguridad, 14 – 20 de enero Vulnerabilidades críticas en los router Netcomm y TP-Link Se han descubierto una serie de vulnerabilidades en los routers Netcomm y TP-Link. Por un lado, los fallos, identificados como CVE-2022-4873 y CVE-2022-4874, se tratan de un...
Jorge Rubio Álvarez Consecuencias de un ciberataque en entornos industriales Podemos encontrar entornos industriales en cualquier tipo de sector que nos podamos imaginar, ya sea en empresas de tratamiento de agua, transporte, farmacéuticas, fabricación de maquinaria, eléctricas, alimentación o...
Telefónica Tech Boletín semanal de Ciberseguridad, 7 – 13 de enero Microsoft corrige 98 vulnerabilidades en su Patch Tuesday Microsoft ha publicado su boletín de seguridad correspondiente con el mes de enero, donde corrige un total de 98 vulnerabilidades. Entre estas...