Certificate Pinning ¿Tenemos el c...ertificado roto? Lic. Cristian Borghello, CISSP – CCSK – MVP www.segu-info.com.ar [email protected] @seguinfo @CursosSeguInfo Sobre Cristian Borghello • Licenciado en Sistemas UTN desde 2000 • Desarrollador desde los 8 años • CISSP (Certified Information Systems Security Professional) desde 2008 • Microsoft MVP Security (Most Valuable Professional) desde 2010 • CCSK (Certificate of Cloud Security Knowledge) desde 2014 • Creador y Director de Segu-Info • Consultor independiente en Seguridad de la Información www.segu-info.com.ar 1 Línea de tiempo 07/1988 X.509 1.0 06/1991 05/ 1995 PGP 2.6.2i PGP 1.0 02/1995 12/1998 SSL 2.0 OpenSSL 05/2008 RFC 5280 01/1999 TLS 1.0 09/1999 X.509 GPG 1.0 v3 10/1999 OpenSSH 08/2000 PGP 6.5.8 GPG www.segu-info.com.ar 2 Autoridad de Certificación 5. La AC chequea que el certificado sea válido 2. La AC certifica la identidad de BANCO y le entrega el certificado 6. La AC informa al usuario sobre la validez del certificado de BANCO AC 4. El Usuario no conoce a BANCO. Consulta a la AC para que verifique su identidad 1. BANCO contacta a AC para obtener un certificado a su nombre 3. BANCO presenta el certificado con su identidad al Usuario 7. El Usuario ahora confía en BANCO BANCO USUARIO Autoridad de Certificación • Organismos encargados de generar Certificados Digitales de cualquier tipo • Entidades autorizadas y reconocidas que generan certificados • En cada certificado se establece un Emisor (issuer) como entidad que ha generado el certificado http://w3techs.com/technologies/overview/ssl_certificate/all www.segu-info.com.ar 3 ¿Confianza? ¿Cómo saber si el certificado descargado es real y no se ha generado de forma fraudulenta? • Verificando la Autoridad de Certificación (issuer) y los certificados involucrados en la cadena • Si un certificado se ha emitido por una Autoridad de Certificación reconocida, se establece una cadena de confianza • Esta información está almacenada en los navegadores www.segu-info.com.ar 4 Dejense de joder Confianza del Emisor • Los campos del emisor (issuer) pueden parecer útiles para identificar la entidad pero… • Pueden ser establecidos a gusto, por lo que no suponen ninguna garantía de procedencia y autenticidad del Certificado Digital www.segu-info.com.ar 5 Confianza del Emisor https://dev.mozilla.jp/localmdc/localmdc_822.html Cadena de confianza jerárquico www.segu-info.com.ar 6 Cadena de confianza jerárquico ¿Entidades de confianza? 03/2001: emitió dos certificados a alguien que se hizo pasar por personal de Microsoft 03/2011: uno de sus partners fue comprometido y se firmaron certificados sin la correspondiente verificación 09/2011: se violó su seguridad y se generaron certificados falsos 01/2013: emitió dos certificados de CA subordinada y esta uno para *.google.com Emitieron un certificado para live.fi (MS), a través de email de administración mal configurado MCS Holdings (China) emitió certificados falsos en nombre de Google 03/2015 www.segu-info.com.ar 7 ¿Entidades de confianza? Vulnerabilidades (IV) 2011 BEAST 2014 2012 • HeartBleed • POODLE • ShellShock CRIME 2013 2015 • BREACH • Lucky13 • Freak • Bar Mitzvah http://resources.infosecinstitute.com/beast-vs-crime-attack/ https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-againstssltls http://www.isg.rhul.ac.uk/tls/Lucky13.html https://community.qualys.com/blogs/securitylabs/2013/08/07/defending-against-the-breach-attack http://blog.segu-info.com.ar/2014/09/faq-de-shellshock-exploit-rce-ddos-y.html http://blog.segu-info.com.ar/2015/03/bar-mitzvah-attack-otro-ataques-rc4.html www.segu-info.com.ar 8 CRL y OSCP • Las CA utilizan dos protocolos para ofrecer a los mecanismos de validación y revocación de certificados: – CRL (Certificate Revocation List) – OCSP (Online Certificate Status Protocol) CRL (Certificate Revocation List) • Para validar un certificado, se descarga la lista CRL actualizada del repositorio de la CA, se verifica la validez de la firma, y se comprueba el identificador del certificado • Si el certificado se encuentra en la CRL (está revocado), no es aceptado como válido • La CRL se publica periódicamente y almacena localmente • Si se emplea una versión obsoleta de CRL se podría considerar válido un certificado que ya no lo es • Nota: MS además usa Certificate Trust List (CTL) http://support2.microsoft.com/kb/931125/en-us www.segu-info.com.ar 9 CRL (Certificate Revocation List) Verificación del certificado revocado de Malayan Banking, el mayor banco y grupo financiero de Malasia http://toolbar.netcraft.com/site_report?url=https://emdm.maybank.com.my OSCP (Online Certificate Status Protocol) • OCSP (RFC 2560) elimina la necesidad de que los clientes tengan que obtener y procesar las CRL, pero requiere conexión permanente con el “OCSP Responder” • Se realiza una petición con el identificador del certificado que se requiere validar http://randomoracle.wordpress.com/2009/07/31/ocsp-thisfail-brought-to-you-by-the-number-three/ www.segu-info.com.ar 10 OSCP en los navegadores Estado actual de CRL y OCSP Google dice Symantec/Verising Firefox 32 www.segu-info.com.ar Firefox 33 11 HSTS (HTTP Strict Transport Security) • HSTS (RFC 6797) es una política por la cual el servidor indica al navegador que sólo deben interactuar a través de HTTPS • La política HSTS se comunica a través del campo HTTP "Strict-Transport-Security” y se especifica un período de tiempo • La cabecera HSTS sólo se debe enviar a través de HTTPS y no cuando se utiliza HTTP (mmm...) http://tools.ietf.org/html/rfc6797 https://crypto.stanford.edu/forcehttps/ https://hstspreload.appspot.com/ Funcionamiento de HSTS 1. La primera vez se realiza una petición HTTPS 2. Luego, el browser realiza una petición HTTP al servidor (podría ser HTTPS) 3. Si el servidor devuelve HSTS, se redirecciona a HTTPS:// durante el tiempo especificado 4. Si el certificado es “confiable” se continúa 5. Si la seguridad de la conexión no se puede asegurar, se informa al usuario y no se permite el ingresa al sitio Nota: En [1], se podría utilizar HTTPS EveryWhere para garantizar siempre el ingreso vía HTTPS www.segu-info.com.ar 12 Campo HSTS Certificate Pinning • Pinning es el proceso de asociar un Host con su respectivo certificado X.509 y/o su Clave Pública • Pinned” asociar certificado o Clave Pública • Se asocia un certificado digital a un dominio concreto • Como en SSH, cada Host se identifica a través de su PK • El Pinning elimina la “confianza en el otro”: una aplicación “pineada” no necesita confiar en un tercero (se vuelve a confiar en los pares) • El pineo se agrega en el primer encuentro entre el cliente y el servidor https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning https://www.owasp.org/index.php/Pinning_Cheat_Sheet https://tools.ietf.org/html/draft-ietf-websec-key-pinning www.segu-info.com.ar 13 Pinning en el código fuente (Hardcoded) A B B A http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json www.segu-info.com.ar 14 Probar Pinning en Chrome chrome://net-internals/#hsts www.segu-info.com.ar 15 Public Key Pinning dinámico (HTTP) • Nueva cabecera HTTP (HPKP Header ) que permite a un servidor indicar cuáles son sus “certificados habituales” y su tiempo de validez • Permite al dueño de un sitio declarar qué certificados le son propios • Si se produce un ataque MitM y/o suplantación de certificados, el navegador avisa de que no se corresponde con el indicado por el servidor • Aún no totalmente soportado por los browsers https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 Public Key Pinning dinámico (HTTP) https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 www.segu-info.com.ar 16 ¿Quién pinea? • Chrome: de forma nativa pinea desde su código fuente (hardcoded) y HPKP • Firefox: a partir de su v32 pinea desde su código fuente y HPKP • IE: pinea a través de EMET • Spartan (Windows 10): nativo • Opera: soportado desde la v26 • Safari: soportado desde OS X 10.9 y iOS 7 http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-tointernet-explorer.aspx https://www.veracode.com/blog/2014/03/security-headers-on-the-top-1000000-websitesmarch-2014-report/ Ejemplos de Pinning Chrome https://pinningtest.appspot.com/ www.segu-info.com.ar 17 Ejemplos de Pinning Firefox Ejemplos de Pinning Internet Explorer - EMET http://www.microsoft.com/en-us/download/details.aspx?id=43714 www.segu-info.com.ar 18 Otras propuestas y “soluciones” (I) • Certificate Transparency (SCT): framework en desarrollo que permitiría tener un “log” público donde cada CA debe registrar los certificados emitidos para realizarle auditorías periódicas • El propietario de un sitio puede consultar periódicamente qué certificados hay en circulación http://tools.ietf.org/html/rfc6962 http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf http://www.certificate-transparency.org/original-proposal Otras propuestas y “soluciones” (II) • Convergence: proyecto de Moxie (2011) que pretende sustituir las CA a través de un anillo de claves público llamados “notarios” http://convergence.io/ • TACK: proyecto de Moxie (2013) que pretende crear una extensión a TLS para permitir el registro de la cadena de certificación a nivel de conexión, sin CAs http://tack.io/draft.html www.segu-info.com.ar 19 Otras propuestas y “soluciones” (III) • DANE/TLSA: vincula TLS a dominios específicos. Se realizan modificaciones al protocolo DNS para vincular DNSSEC a los certificados y a los nombres de dominio http://tools.ietf.org/html/rfc6698 http://dane.verisignlabs.com/ http://www.dnssec-validator.cz/ https://www.huque.com/bin/gen_tlsa http://blog.huque.com/2012/10/dnssec-and-certificates.htm https://github.com/shuque/tlsa_rdata Registro DNS TLSA 1. Generar registro DNS TLSA openssl x509 -in huque.crt -outform DER | openssl sha256 (stdin) = 0013BEF11B875A58F3B0B1D7A0D439A608277F... 2. Actualizar registro DNS (nsupdate) 3. Consultar registro DNS TLSA http://blog.huque.com/2012/10/dnssec-and-certificates.html www.segu-info.com.ar 20 Otras propuestas y “soluciones” (IV) • SSLCOP: herramienta que permite bloquear CAs que no son de interés debido a su procedencia geográfica http://www.securitybydefault.com/2012/03/sslcop-10.html • Certificate Patrol: extensión que verifica cualquier modificación de la cadena de certificación https://addons.mozilla.org/en-US/firefox/addon/certificatepatrol/ Certificate Patrol https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/ www.segu-info.com.ar 21 Conclusiones • Las cadenas de certificación no son confiables • Cada empresa crear su propia “solución” no compatible • Cada una de las “soluciones” es vulnerable • No se brinda un mensaje claro al usuario sobre lo que es “seguro” • Es necesario un gran cambio, que además sea compatible con lo existente y fácil de entender Gracias! Lic. Cristian Borghello, CISSP – CCSK – MVP www.segu-info.com.ar [email protected] @seguinfo @CursosSeguInfo www.segu-info.com.ar 22