Protección de la emisión de certificados mediante la validación de control de dominio multitrayecto

Esta publicación de blog forma parte de Crypto Week 2019.

La confianza en internet se debe fundamentalmente a la infraestructura de clave pública (PKI, Public Key Infrastructure). La PKI ofrece a los servidores la capacidad de brindar servicios a sitios web de forma segura mediante la emisión de certificados digitales, brindando así la base para la comunicación encriptada y auténtica.

Para permitir el cifrado HTTPS, los certificados usan la clave pública que contienen para verificar la identidad del servidor. HTTPS es especialmente importante para los sitios web que transmiten datos confidenciales, como credenciales bancarias o mensajes privados. Afortunadamente, los navegadores modernos, como Google Chrome, marcan los sitios web no protegidos mediante HTTPS como “No seguros”, lo que permite a los usuarios tener más cuidado con la seguridad de los sitios web que visitan.

En esta publicación del blog se presenta una nueva herramienta gratuita que Cloudflare ofrece a las CA (autoridades de certificación) para que puedan elevar el nivel de protección de la emisión de certificados. Pero antes de ahondar en el tema, hablemos de la procedencia de los certificados.

Las autoridades de certificación (CA, Certificate Authorities) son las instituciones que tienen a su cargo la emisión de certificados.

Al emitir un certificado para un dominio determinado, usan la validación de control de dominio (DCV, Domain Control Validation) para comprobar que la entidad que solicita un certificado para el dominio sea la propietaria legítima de este último. Con la DCV, el propietario del dominio puede hacer lo siguiente:

1. crear un registro de recursos del sistema de nombres de dominio (DNS, Domain Name System) para un dominio;

2. cargar un documento en el servidor web ubicado en ese dominio; O

3. probar la propiedad de la cuenta de correo electrónico administrativo del dominio.

El proceso de DCV evita que los adversarios obtengan pares de claves privadas y de certificados para dominios que no son propiedad del solicitante.

Evitar que los adversarios adquieran este par es fundamental: si un certificado emitido incorrectamente y un par de clave privada terminan en manos de un adversario, este podría hacerse pasar por el dominio de la víctima y gestionar el tráfico HTTPS confidencial. Esto vulnera nuestra actual confianza en internet y compromete los datos privados a una escala potencialmente masiva.

Por ejemplo, un adversario que engaña a una autoridad de certificación (CA) para que emita erróneamente un certificado para gmail.com luego podría ejecutar protocolos de enlace de seguridad de la capa de transporte (TLS, Transport Layer Security) y hacerse pasar por Google para filtrar cookies e información de inicio de sesión a fin de obtener acceso a la cuenta de Gmail de la víctima. Los riesgos de la emisión errónea de certificados son evidentemente graves.

Para evitar ataques como este, las CA solo emiten un certificado después de la DCV. Una forma de validar la propiedad del dominio es a través de la validación HTTP, que se hace mediante la carga de un archivo de texto en un extremo HTTP específico en el servidor web que se desea proteger.  Otro método de DCV es la verificación por correo electrónico. Se envía un correo electrónico con un vínculo de código de validación al contacto administrativo del dominio.

Supongamos que Alice compra el nombre de dominio aliceswonderland.com y desea obtener un certificado específico para este dominio. Alice elige usar Let's Encrypt como su entidad de certificación. En primer lugar, Alice debe generar su propia clave privada y crear una solicitud de firma de certificado (CSR, Certificate Signing Request). Envía la CSR a Let's Encrypt, pero la CA no emitirá un certificado para esa CSR y la clave privada hasta que sepan que Alice es la propietaria de aliceswonderland.com. Alice puede optar por probar la propiedad de este dominio a través de la validación HTTP.

Cuando Let's Encrypt hace la DCV a través de HTTP, le solicita a Alice que coloque un archivo de nombre aleatorio en la ruta /.well-known/acme-challenge para su sitio web. La CA debe recuperar el archivo de texto mediante el envío de una solicitud HTTP GET a http://aliceswonderland.com/.well-known/acme-challenge/<random_filename>. Para que la DCV se haga correctamente, este punto de conexión debe tener el valor esperado.

Para la validación HTTP, Alice subiría un archivo a  http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz,

que en el cuerpo tendría lo siguiente:

curl http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz

GET /.well-known/acme-challenge/YnV0dHNz
Host: aliceswonderland.com

HTTP/1.1 200 OK
Content-Type: application/octet-stream

YnV0dHNz.TEST_CLIENT_KEY

La CA les indica que utilicen el token Base64 YnV0dHNz. TEST_CLIENT_KEY en una clave vinculada a la cuenta que solo conocen el solicitante del certificado y la CA. La CA utiliza esta combinación de campos para verificar que el solicitante del certificado posee realmente el dominio. ¡Finalmente, Alice puede obtener el certificado para su sitio web!

Para validar la propiedad del dominio, los usuarios también pueden añadir un registro DNS TXT que contenga una cadena de verificación o token de la CA para los registros de recursos de su dominio. Por ejemplo, este es un dominio para una empresa que se valida en Google:

$ dig TXT aliceswonderland.com
aliceswonderland.com.	 28 IN TXT "google-site-verification=COanvvo4CIfihirYW6C0jGMUt2zogbE_lC6YBsfvV-U"

Aquí, Alice opta por crear un registro de recursos DNS TXT con un valor de token específico. Una CA de Google puede verificar la presencia de este token para validar que Alice realmente es propietaria de su sitio web.

La emisión de certificados es necesaria para que los servidores se comuniquen de forma segura con los clientes. Por este motivo, es importante que el proceso que se encarga de emitir certificados también sea seguro. Lamentablemente, no siempre es el caso.

Investigadores de la Universidad de Princeton descubrieron recientemente que los métodos comunes de DCV son vulnerables a los ataques ejecutados por adversarios a nivel de red. Si el protocolo de puerta de enlace de frontera (BGP, Border Gateway Protocol) es el “servicio postal” de internet encargado de enviar datos a través de las rutas más eficientes, entonces los sistemas autónomos (AS, Autonomous Systems) son las sucursales de las oficinas de correos individuales que representan una red de internet administrada por una sola organización. A veces, los adversarios a nivel de red anuncian rutas falsas en el BGP para robar tráfico, especialmente si ese tráfico contiene algo importante, como un certificado de dominio.

Engañar a las autoridades de certificación con BGP destaca cinco tipos de ataques que se pueden organizar durante el proceso de DCV para obtener un certificado de un dominio que el adversario no posee. Después de implementar estos ataques, los autores pudieron (de manera ética) obtener certificados para dominios de los que no eran propietarios de parte de las cinco principales CA: Let’s Encrypt, GoDaddy, Comodo, Symantec y GlobalSign. Pero, ¿cómo lo hicieron?

Hay dos métodos principales para atacar el proceso de DCV con el secuestro de BGP:

1. Ataque de subprefijos

2. Ataque de prefijos igualmente específico

Estos ataques generan vulnerabilidad cuando un adversario envía una solicitud de firma de certificado para el dominio de una víctima a una CA. Cuando la CA verifica los recursos de la red mediante una solicitud HTTP GET (como se analizó anteriormente), el adversario utiliza los ataques de BGP para secuestrar el tráfico al dominio de la víctima de manera que la solicitud de la CA se redirija al adversario y no al propietario del dominio. Para entender cómo se realizan estos ataques, primero tenemos que hacer algunos cálculos matemáticos.

Cada dispositivo en internet utiliza una dirección IP (protocolo de internet) como identificador numérico. Las direcciones IPv6 contienen 128 bits y siguen una barra oblicua para indicar el tamaño del prefijo. Por lo tanto, en la dirección de red 2001:DB8:1000::/48, “/48” se refiere a la cantidad de bits que contiene la red. Esto significa que quedan 80 bits que contienen las direcciones de host, para un total de 10 240 direcciones de host. Cuanto menor sea el número de prefijo, más direcciones de host permanecen en la red. Ahora que ya hablamos de esto, pasemos a los ataques.

Ataque uno: Ataque de subprefijos

Cuando el BGP anuncia una ruta, el enrutador siempre prefiere seguir la más específica. Así que si se anuncian 2001:DB8::/32 y 2001:DB8:1000::/48, el enrutador utilizará esta última, ya que es el prefijo más específico. Esto se convierte en un problema cuando un adversario hace un anuncio de BGP a una dirección IP específica mientras utiliza la dirección IP del dominio de la víctima. Supongamos que la dirección IP de nuestra víctima, leagueofentropy.com, es 2001:DB8:1000::1 y se anuncia como 2001:DB8::/32. Si un adversario anuncia el prefijo 2001:DB8:1000::/48, entonces capturará el tráfico de la víctima, lanzando un ataque de secuestro de subprefijo.

En un ataque IPv4, como el ataque de abril de 2018, fueron anuncios de /24 y /23, y el más específico /24 fue anunciado por la entidad maliciosa. En IPv6, podría haber sido un anuncio /48 y /47. En ambos casos, /24 y /48 son los bloques más pequeños que se pueden enrutar a nivel global. En el siguiente diagrama, /47 es Texas y /48 es el más específico, Austin, Texas. Las nuevas (pero maliciosas) rutas anularon por partes las rutas existentes de internet. A continuación, el atacante ejecutó un servidor DNS malicioso en las direcciones IP normales con registros DNS direccionando a algún nuevo servidor web malicioso en lugar del servidor existente. Esto atrajo el tráfico destinado al dominio de la víctima a la zona en la que se estaban propagando las rutas maliciosas. La razón por la que este ataque tuvo éxito fue porque los enrutadores receptores siempre prefieren un prefijo más específico.

Ataque dos: Ataque de prefijos igualmente específico

En el último ataque, el adversario secuestró el tráfico ofreciendo un anuncio más específico, pero ¿qué sucede si el prefijo de la víctima es /48 y un ataque de subprefijo no es viable? En este caso, un atacante lanzaría un secuestro de prefijo igualmente específico, donde el atacante anuncia el mismo prefijo que la víctima. Esto significa que el AS elige la ruta preferida entre la víctima y los anuncios del adversario en función de características como la longitud de la ruta. Este ataque solo intercepta una parte del tráfico.

Hay ataques más avanzados que se tratan con más profundidad en el artículo. Son ataques fundamentalmente similares, pero son más imperceptibles.

Una vez que un atacante ha obtenido un certificado falso para un dominio que no posee, puede realizar un ataque convincente donde se hace pasar por el dominio de la víctima y es capaz de descifrar e interceptar el tráfico TLS de la víctima. La capacidad de descifrar el tráfico TLS permite al adversario realizar un ataque de intermediario (MITM, Monster-in-the-Middle) sobre el tráfico TLS cifrado y redirigir el tráfico de internet destinado al dominio de la víctima a sí mismo. Para hacer que el ataque sea aún más imperceptible, el adversario continuará enrutando el tráfico a través del dominio de la víctima para realizar el ataque de una manera indetectable.

Otra forma en que un adversario puede obtener el control de un dominio es redireccionando el tráfico DNS mediante una dirección IP de origen que pertenece a un servidor de nombres DNS. Debido a que cualquier persona puede modificar las direcciones IP salientes de sus paquetes, un adversario puede falsificar la dirección IP de cualquier servidor de nombres DNS que participa en la resolución del dominio de la víctima y hacerse pasar por un servidor de nombres al responder a una CA.

Este ataque es más sofisticado que simplemente enviar spam a una CA con respuestas DNS falsificadas. Como cada consulta DNS tiene sus propios identificadores de consulta y puerto de origen aleatorios, una respuesta DNS falsa debe coincidir con los identificadores de la consulta DNS para ser convincente. Como estos identificadores de consulta son aleatorios, dar una respuesta falsa con los identificadores correctos es sumamente difícil.

Los adversarios pueden fragmentar los paquetes DNS del protocolo de datagramas de usuario (UDP, User Datagram Protocol) de modo que la identificación de la información de respuesta DNS (como el identificador de consulta DNS aleatorio) se entregue en un paquete, mientras que la sección de respuesta real sigue en otro paquete. De esta manera, el adversario hace pasar la respuesta DNS por una consulta DNS legítima.

Supongamos que un adversario desea obtener un certificado mal emitido para victim.com forzando la fragmentación de paquetes y redireccionando la validación de DNS. El adversario envía a un servidor de nombres DNS para victim.com un paquete de “fragmentación necesaria” ICMP con una pequeña unidad de transmisión máxima o un tamaño de byte máximo. Esto hace que el servidor de nombres comience a fragmentar las respuestas DNS. Cuando la CA envía una consulta DNS a un servidor de nombres para victim.com solicitando los registros TXT de victim.com, el servidor de nombres fragmenta la respuesta en los dos paquetes que se describen anteriormente: el primero contiene la identificación (ID) de consulta y el puerto de origen, que el adversario no puede falsificar, y el segundo contiene la sección de respuesta, que el adversario puede falsificar. El adversario puede enviar continuamente una respuesta redireccionada a la CA durante el proceso de validación de DNS, con la esperanza de deslizar su respuesta redireccionada antes de que la CA reciba la respuesta real del servidor de nombres.

Al hacerlo, se puede falsificar la sección de respuesta de una respuesta DNS (¡la parte importante!) y un adversario puede engañar a una CA para que emita erróneamente un certificado.

A primera vista, se podría pensar que un registro de transparencia de certificado podría denunciar un certificado erróneamente emitido y permitir que una CA lo revoque rápidamente. Sin embargo, los registros CT (registro de transparencia), pueden tardar hasta 24 horas en incluir certificados recién emitidos, y se puede generar una incoherencia en el seguimiento de la revocación de certificados entre diferentes navegadores. Necesitamos una solución que permita a las CA abordar estos ataques de manera preventiva, no abordarlos en forma retroactiva.

Nos complace anunciar que Cloudflare proporciona a las CA una API gratuita para aprovechar nuestra red global y realizar DCV desde múltiples posiciones estratégicas en todo el mundo. Esta API refuerza el proceso DCV contra el secuestro de BGP y los ataques DNS fuera de ruta.

Como Cloudflare administra más de 175 centros de datos en todo el mundo, estamos en una posición única para realizar DCV desde múltiples puntos estratégicos. Cada centro de datos tiene una ruta de acceso única a servidores de nombres DNS o extremos HTTP, lo que significa que el secuestro exitoso de una ruta BGP solo puede afectar a un subconjunto de solicitudes DCV, lo que dificulta aún más los secuestros de BGP. Y como usamos RPKI, en realidad firmamos y verificamos las rutas BGP.

Este verificador de DCV también protege a las CA contra ataques de redireccionamiento de DNS fuera de ruta. Una característica adicional que hemos integrado al servicio y que ofrece protección contra los atacantes fuera de ruta es la asignación aleatoria de IP de origen de consulta de DNS. Al hacer que la IP de origen sea impredecible para el atacante, resulta más difícil redireccionar el segundo fragmento de la respuesta DNS falsificada al agente de validación de DCV.

Al comparar varios resultados de DCV recopilados en varias rutas, nuestra API de DCV hace que sea prácticamente imposible para un adversario engañar a una CA para que piense que posee un dominio cuando en realidad no es así. Las CA pueden usar nuestra herramienta para asegurarse de que solo emiten certificados a propietarios de dominio legítimos.

Nuestro verificador de DCV multitrayecto consta de dos servicios:

1. Agentes de DCV responsables de realizar DCV fuera de un centro de datos específico, y

2. Un orquestador de DCV que gestiona las solicitudes DCV multitrayecto de las CA y las distribuye a un subconjunto de agentes de DCV.

Cuando una CA desea asegurarse de que la DCV se produjo sin ser interceptada, puede enviar una solicitud a nuestra API especificando el tipo de DCV que se va a realizar y sus parámetros.

A continuación, el orquestador de DCV reenvía cada solicitud a un subconjunto aleatorio de más de 20 agentes de DCV en diferentes centros de datos. Cada agente de DCV realiza la solicitud de DCV y reenvía el resultado al orquestador de DCV, que agrega lo que cada agente observó y lo devuelve a la CA.

Este enfoque también se puede generalizar para realizar consultas multitrayecto sobre registros DNS, como registros de autorización de la autoridad de certificación (CAA, Certificate Authority Authorization). Los registros de CAA autorizan a las CA a emitir certificados para un dominio, por lo que redireccionarlas para engañar a las CA no autorizadas para que emitan certificados es otro vector de ataque que la observación multitrayecto evita.

Mientras desarrollábamos nuestro verificador multitrayecto, estuvimos en contacto con el grupo de investigación de Princeton, que presentó la prueba de concepto (PoC) de la emisión incorrecta de certificados a través de ataques de secuestro de BGP. Prateek Mittal, coautor del ensayo Bamboozling Certificate Authorities with BGP , escribió lo siguiente:

“Nuestro análisis demuestra que la validación de dominio desde múltiples puntos estratégicos mitiga de manera significativa el impacto de los ataques de BGP localizados. Recomendamos que todas las autoridades de certificación adopten este enfoque para mejorar la seguridad web. Una característica particularmente atractiva de la implementación de esta defensa de Cloudflare es que Cloudflare tiene acceso a una gran cantidad de puntos estratégicos en internet, lo que mejora en gran medida la solidez de la validación del control de dominio”.

Nuestro verificador de DCV sigue nuestra idea de que la confianza en internet debe ser distribuida y examinada por análisis de terceros (como el que ofrece Cloudflare) para garantizar la coherencia y la seguridad. Esta herramienta se asocia a nuestrocontrol preexistente de transparencia de certificados como un conjunto de servicios que las CA están invitadas a usar para mejorar la responsabilidad de la emisión de certificados.

Desarrollar nuestro verificador de DCV multitrayecto también nos permitió probar varios productos Cloudflare.

El orquestador de DCV como simple recuperador y agregador fue un candidato fantástico para Cloudflare Workers. Implementamos el orquestador en TypeScript usando esta publicación como guía y creamos un servicio de orquestador digitado y confiable que fuera fácil de implementar y reiterar. ¡Celebramos que ya no tenemos que mantener nuestro propio servidor dcv-orchestrator!

Utilizamos Argo Tunnel para permitir que Cloudflare Workers se ponga en contacto con agentes de DCV. Argo Tunnel nos permite exponer de forma fácil y segura a nuestros agentes de DCV al entorno de Workers. Como Cloudflare tiene aproximadamente 175 centros de datos que ejecutan agentes de DCV, presentamos muchos servicios a través Argo Tunnel, y hemos tenido la oportunidad de hacer pruebas de carga de Argo Tunnel como usuario experto con una amplia variedad de orígenes. ¡Argo Tunnel manejó fácilmente este influjo de nuevos orígenes!

Si usted y/o su organización están interesados en probar nuestro verificador DCV, envíe un correo electrónico a [email protected] y háganoslo saber. Nos gustaría obtener más información sobre cómo la solicitud y la validación multitrayecto refuerzan la seguridad de su emisión de certificados.

Como una nueva clase de ataques de suplantación de BGP e IP amenazan con socavar los fundamentos de la infraestructura de clave pública (PKI), es importante que los propietarios de sitios web aboguen por la validación multitrayecto cuando se emiten certificados. Sugerimos que todas las CA a utilicen la validación multitrayecto, ya sea de Cloudflare o la propia. Jacob Hoffman-Andrews, jefe de tecnología de Let's Encrypt, escribió lo siguiente:

"El secuestro de BGP es uno de los grandes desafíos que la PKI web todavía necesita resolver, y creemos que la validación multitrayecto puede ser parte de la solución. Estamos probando nuestra propia implementación y sugerimos a otras CA que apliquen también la validación multitrayecto”

Esperemos que en el futuro los propietarios de sitios web consideren el soporte de validación multitrayecto cuando seleccionen una CA.Criptosemana Cripto Criptografía DNS BGP