O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Jose Torres y Sergio De Los Santos - Exploiting Certificate Transparency blind spots [rootedvlc4]

530 visualizações

Publicada em

Google ya anunció que Certificate Transparency será obligatorio en Chrome (a partir de octubre) para todos los nuevos certificados que se emitan. Esto ha forzado a todos los actores involucrados en este ecosistema (CAs, administradores de dominios, o incluso otros navegadores …) a prepararse de forma precipitada para este deadline.

En esta charla detallaremos, por un lado, quién y cómo está usando Certificate Transparency realmente. A día de hoy no tenemos constancia de que se haya realizado ningún estudio a nivel global de este tipo. Por otro lado, realizaremos una profunda incursión en los puntos ciegos de la especificación de CT, con el objetivo de explotarlos, desde el punto de vista del atacante que pretende crear un “rogue certificate” y realizar un bypass de Certificate Transparency junto con las limitaciones que supone este mecanismo ante la ejecución de ataques tradicionales como por ejemplo MiTM.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Jose Torres y Sergio De Los Santos - Exploiting Certificate Transparency blind spots [rootedvlc4]

  1. 1. JOSE TORRES SERGIO DE LOS SANTOS Innovation Analyst Head of Lab @jose7orres @ssantosv Starring Área de Innovación y Laboratorio
  2. 2. Certificate Transparency • Diseñado por Google. • Presentado y definido en el RFC 6962 • Será obligatorio en Chrome en octubre 2017 • Pretende convertirse en una de las soluciones más efectivas para reforzar la seguridad del ecosistema TLS (HTTPS incluido) abril 2018
  3. 3. Certificate Transparency Existen otras aproximaciones de propósito similar: • HPKP • HSTS • CAA Aunque todas pueden funcionar de forma simultánea sin problemas No requieren infraestructura adicional
  4. 4. Certificate Transparency
  5. 5. • Será adoptado por otros navegadores como Firefox. ¿Están preparados el ecosistema TLS y el resto de actores implicados? Certificate Transparency Dentro del movimiento #movingtoHTTPS que Google espera trasladar a todo internet Es una propuesta prometedora pero...
  6. 6. • Pretende la exposición pública de todo nuevo certificado emitido (de cualquier tipo) • Basado en los Árboles de Merkle Una caja fuerte con el contenido a simple vista! Certificate Transparency
  7. 7. Veamos cómo funciona …
  8. 8. Integración en el ecosistema TLS tradicional Certificate Transparency
  9. 9. Logs Auditors CT Logs Logs Monitors SSL Certificates Website Owner Purchases Subscribes to Uploaded to Verifies their activity Looks for certificates Issues www. Checks Actores Implicados Certificate Transparency https://ct.grahamedgecombe.com/
  10. 10. Actores Implicados ¿Existe toda la infraestructura? ¿Funcionan todos los actores? Monitores Logs CAs Auditores Certificate Transparency
  11. 11. No necesariamente… Certificate Transparency
  12. 12. Conseguir evitar la protección adicional que supone CT para conseguir ejecutar ataques típicos como MiTM… Objetivo
  13. 13. Necesitamos un plan … ¿Cómo evitar Certificate Transparency?
  14. 14. Necesitaremos: • Emitir certificados asociados a un determinado dominio sin ser descubiertos (Emulando RogueCerts) • Estar presentes en los logs de CT y controlando en CUÁLES queremos estar • Pasar desapercibidos antes los monitores. ¿Cómo evitar Certificate Transparency?
  15. 15. Para ello será necesario: ¿Cómo evitar Certificate Transparency? El diseño de la arquitectura es bastante fiable. Lo ideal será buscar fallos de implementación de los actores implicados Evaluar los posibles problemas en el ecosistema, detectando posibles puntos ciegos que puedan ser explotables
  16. 16. Almacenan y publican los certificados recopilados, sin embargo: • No todos los logs tienen la misma cantidad de certificados. • Igual que los navegadores, los logs solo aceptan certificados de ciertas CAs. • Los monitores, solo vigilan ciertos log • Los navegadores (Chrome) solo acepta como válidos “LOG CONFIABLES” Entonces, ¿Hay CAs discriminadas? + Si, las hay. Actores implicados – CT Logs https://www.certificate-transparency.org/known-logs https://sslmate.com/labs/ct_growth/ LOGS CAS MONITORES
  17. 17. Actores implicados – CT Logs
  18. 18. Actores implicados - Monitores • Funcionan bajo demanda. • Un usuario puede solicitar la vigilancia de determinados dominios (no necesariamente propios) • Prácticamente solo existen dos: • Cert Spotter. (SSLMate) • Facebook Certificate Transparency Monitoring tool
  19. 19. El “tiempo de mergeo” es especialmente importante Hay que tener en cuenta el tiempo que transcurre desde que se emite el certificado, hasta que aparece en los logs
  20. 20. Podríamos ser detectados por los monitores… ¿Cómo evitarlo?
  21. 21. ¿Qué logs vigilan? ¿Cada cuánto tiempo? ¿Cuánto tardan en notificar? Actores implicados – Monitores ¿Estos logs comparten info?
  22. 22. Sin embargo, no están funcionando del mejor modo… Facebook no está comunicando ninguna aparición Actores implicados – Monitores
  23. 23. Algunas están vetadas por los logs y a su vez estos en el navegador. Podrían ayudar significativamente al ecosistema mediante dos “simples acciones”: • Subir el certificado a los logs inmediatamente después de emitirlos. • Ofrecer el SCT vía OCSP o incrustado en el navegador. Sin embargo, la mayoría no lo hace (al menos para los certificados no EV) Actores implicados – CAs
  24. 24. Con todo lo anterior se hicieron pruebas prácticas. • Se crearon varios dominios: - ct-11p.com - certransp.com - .elevenpaths.com • Seleccionamos varias CAs para emitir certificados: - Comodo CA - Let’s Encrypt ¡Manos a la obra! (Solo aceptada en ICARUS)
  25. 25. Y por si fuera poco Aún no hemos hablado del navegador…
  26. 26. El código fuente Implementación en Chrome Los logs aceptados, están ¿hardcodeados?
  27. 27. Implementación en Chrome
  28. 28. File: sth_set_component_installer.h
  29. 29. Expect-CT Implementación en Chrome Expect-CT: enforce; max-age=1440; report-URI=https://blah.com/CTReport/ enforce: El navegador espera un SCT válido o aborta la conexión max-age: Tiempo de caché de esta directiva en el navegador (en seg.) report-URI: URL a la que el navegador deber enviar reportes de fallos
  30. 30. Resultados El número mínimo de log, no está definido, aunque se recomendaban 3 2 Hemos conseguido estar en 2 logs (Venafi y Digicert) con altas posibilidades de 3 o más - Es posible aparecer en un log pendiente de inclusión y esperar Los logs aceptados (en Chrome), aparecen y desaparecen continuamente, creando nuevas combinaciones por probar y posibilidades de repetir el experimento. https://sslmate.com/labs/ct_growth/ En julio 2017 Chrome (M60) incluyó 2 nuevos logs de Comodo en su lista de confianza
  31. 31. ¿Más problemas? No funciona del todo bien en Chrome Aún no se sabe nada de Firefox • ¿Y el resto de navegadores?¿MS Edge?
  32. 32. Conclusiones
  33. 33. UN ATACANTE TENDRÍA POTENCIALMENTE 40 HORAS ANTES DE SER DETECTADO UNA VEZ DETECTADO, EL TIEMPO DE REACCIÓN, PODRÍA SER MUCHO MAYOR
  34. 34. Conclusiones Hay que tener en cuenta que: • CT NO se usará para revocar certificados. Solo para ayudar a detectar con más rapidez su uso indebido. • Una vez reportado, un certificado, deberá ser revocado mediante los mecanismos tradicionales. Tras esto, el certificado seguirá pasando la validación de CT para el navegador (estar en X logs) • El conocimiento general de CT por los administradores/usuarios, es muy bajo y su uso poco extendido (solo el 12% de certificados de Alexa están en 3 logs)  Baja probabilidad de reporte
  35. 35. ¿Significa todo esto que CT no es una buena opción? Todo lo contrario, es una solución muy prometedora, pero aún debe estabilizarse. Retrasado a ¿2018?: https://www.thesslstore.com/blog/certificate- transparency-requirement/ Conclusiones
  36. 36. Gracias por vuestro tiempo! ¿Preguntas?

×