Seguridad de la infraestructura de llaves pública (PKI)

Historial

Crear certificados no autorizados

Es posible crear certificados para “nombres” (dominios o IPs) que no te pertenecen de distintas maneras. De esta manera, podés interceptar conexiones y así romper TLS (la seguridad a nivel “transporte”), la base de toda la seguridad de la Web.

Pero ¿como? Primero hay que entender como funciona la “infraestructura de llaves pública” (PKI, Public Key Infrastructure).

Las “autoridades de certificados” son las organizaciones que verifican los dominios y otorgan certificados válidos a quienes le pertenecen. Los sistemas operativos y los navegadores confían en una lista de autoridades de distintos países y distintos estados (con y sin fines de lucros, etc). Si se duda la confianza de estas, se les saca de las listas y los certificados que otorgan paran de ser válidos (esto es importante más abajo :).

La forma que se verifica que “sos el nombre que decís” es distinta de cada autoridad. La forma más “moderna” y la que solemos usar es un sistema de verificación y otorgación automático llamado “ACME” (Automatic Certificate Management Environment). Esta fue desarrollada por Let’s Encrypt, pero luego fue implementada por otros servicios. Acá solo voy a dar ejemplos de vulnerabilidades en este sistema, pero seguro existen otros en las otras autoridades con sus propios métodos.

ACME verifica a través de distintos “métodos”, los más comúnes siendo http-01 y dns-01.

  1. http-01 busca tu dominio en DNS generalmente desde varios servidores1 (esto es importante después) y hace un pedido al servidor en esa IP. Si todos los pedidos contestan con la llave compartida que te dijo ACME, estás verificadx, y obtenes un certificado.
  2. dns-01 busca tu dominio en DNS y busca la llave compartida en el registro de DNS mismo.

dns-01 generalmente es más seguro porque no confía en la IP registrada en el DNS en si, sino solo en el registro mismo (del que confias de todas maneras en http-01).

Lo que pasa es que es posible interceptar conexiones entre los servidores de la autoridad y los del dominio verificado:

Por ejemplo, consideremos un sitio web hosteado en una conexión residencial. Un actor malicioso dentro del proveedor de internet, o un hacker, podría interceptar las conexiones a la dirección IP y hacer pedidos de certificados para ese dominio. Esto sería posible sin necesidad de comprometer a los registradores de dominio o proveedores DNS que manejan la cadena de DNS del dominio.

En conexiones con IP dinámica (común en conexiones residenciales), la dirección IP puede cambiar aleatoriamente y ser reasignada a otro cliente. Aunque existen soluciones como programas de actualización automática de DNS que mantienen los registros actualizados con la IP actual, estos sistemas tienen intervalos de actualización (típicamente algunos minutos) durante los cuales la IP podría ser reasignada. En ese intervalo, el nuevo cliente que recibe la IP podría ejecutar este tipo de ataque.

Este es un ejemplo específico, pero es un ataque viable, y de hecho ya ejecutado. Abajo comento de un caso en el que se hace BGP hijacking para interceptar las conexiones de un servidor, crear un certificado y insertar malware en el sitio para robar 1,9 millones de dolares.

Otro ataque es más “simple” pero requiere “una conspiración mayor” para ejecutar: que una autoridad de certificados comprometida cree un certificado bajo el nombre de nulo.lol sin verificación. Esto ya pasó varias veces, muchas veces por errores de la autoridad en su software. sslmate.com mantiene una lista con muchos incidentes de esta índole de las autoridades.

Previamente, la única forma de verificar que una autoridad había falsificado un certificado era obteniendo el certificado falsificado y compartiendolo. Esto es problematico porque un ataque teorico podría solo utilizar los certificados falsificados a las victimas a las que se quieren interceptar específicamente.

Sin embargo, hoy en día los navegadores (en Google Chrome desde 20182) requieren que los certificados estén registrados en un registro de transparencia (Certificate Transparency - Wikipedia). De esta manera, se puede inspeccionar estos registros públicos por certificados inusuales. crt.sh es un sitio que permite acceder a estos registros fácilmente.

(Notese, igualmente, que otras cosas que no son navegadores web pueden no estar chequeando los registros de transparencia. Aún hoy en día no es un requerimiento para las autoridades de certificados reportar todos los certificados generados a los registros de transparencia.)

Casos

  • February 2022: Attackers hijacked BGP prefixes that belonged to a South Korean cryptocurrency platform, and then issued a certificate on the domain via ZeroSSL to serve a malicious JavaScript file, stealing $1.9 million worth of cryptocurrency.31

    de BGP hijacking - Wikipedia

Soluciones o mitigaciones

Monitorear Certificate Transparency

Esto nos deja saber si se sacaron certificados inautorizados, pero no nos deja prevenirlos. Una posibilidad sería monitorear los Certificate Transparency logs revisando que solo haya certificados nuestros, pero no conozco software OSS que lo haga.

Restringir metodos de verificación via registros CAA

Gracias a RFC8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding, podemos pedirles a los servidores de expedición de certificados que solo saquen certificados bajo ciertos proveedores y métodos. Esto nos permite limitar la expedición a un proveedor y al método dns-01. De esta manera, aún si pueden interceptar las conexiones a nuestra IP (via BGP hijacking o comprometiendo a nuestro ISP o…) no pueden generar certificados (tendrían que hackear nuestro DNS).

Let’s Encrypt lo implementó en su entorno de prueba en 2018 y en producción en diciembre 2022. Osea: ¡ya lo podemos usar!

Mas consejos de implementación por uno de los autores del RFC: Let’s Encrypt now supports ACME-CAA: closing the DV loophole

GrapheneOS usa esto pero usa http-01. Esto reduce las posibilidades de ataque (al menos solo tenés que confiar en Let’s Encrypt) pero no es perfecto.

CAA Mandated by CA/Browser Forum