Lo que nos enseña CVE-2020-0601 sobre el proceso de verificación de certificados TLS de Microsoft


Por: Jan Schnellbächer y Martin Stecher, McAfee Germany GmbH

Esta semana, las investigaciones de seguridad en todo el mundo estuvieron muy ocupadas trabajando en la principal vulnerabilidad de falsificación de cifrado de Microsoft (CVE-2020-0601), también conocida como Curveball. La mayoría de las investigaciones se centraron en ataques con archivos binarios maliciosos que están firmados con una Autoridad de Certificación (CA) falsificada que, a su vez, confiaba en los sistemas Get10 sin parches. El otro vector de ataque —HTTPS-Server-Certificates— recibió menos atención hasta que Saleem Rashid publicó un primer POC en Twitter, seguido de Kudelski Protection y «Ollypwn», quienes publicaron más detalles sobre cómo se crean las pruebas de conceptos.

Los expertos en seguridad de McAfee siguieron el mismo enfoque y pudieron reproducir el ataque. Además, confirmaron que los usuarios que navegaban a través de sistemas Windows sin parches estaban protegidos, siempre que sus clientes se implementaran detrás de World wide web Gateway o World wide web Gateway Cloud Company de McAfee y ejecutaran la política de verificación de certificados. Por lo normal, esto forma parte del escáner SSL, pero también está disponible como una política separada, incluso si no se debe realizar una inspección SSL (consulte KB92322 para detalles).

En nuestro primer intento, utilizamos la versión falsificada de una CA del almacén de Windows Root CA Rely on para firmar un certificado de servidor y luego solo proporcionamos el certificado del servidor cuando se quería establecer la conexión HTTPS. Ese intento falló y asumimos que no obtuvimos la suplantación correcta. Luego supimos que la CA falsificada realmente debe incluirse junto con el certificado del servidor y que la cadena de certificados es aceptada por un sistema Windows 10 sin parches.

¿Pero por qué es eso? Al enviar la versión falsificada, se hace evidente que este no es el mismo certificado que existe en el almacén de confianza y debe denegarse de inmediato. Además, al principio, tratamos de hacer que la CA falsificada sea lo más comparable posible a la CA primary (el mismo nombre común, el mismo número de serie, etc.). De hecho, descubrimos que nada de eso juega ningún papel cuando Home windows realiza la verificación del certificado.

Los cuadros de diálogo de información de certificados de Home windows ya proporcionan una buena indicación de lo que sucede detrás de escena. Comenzamos con el «Certificado ECT UserTrust» en el catálogo de Home windows Trusted Root CA que lleva el nombre descriptivo «Sectigo ECC». Luego creamos una versión falsa de esa CA y le dimos un nuevo nombre común «CA MALVADA». Con eso, fue fácil configurar un nuevo servidor HTTPS de prueba en nuestra purple de prueba y manipular el enrutamiento de un cliente de prueba para que llegue a nuestro servidor cuando el usuario escribe https://www.google.com en el navegador El servidor de prueba presentaba información de sesión SSL con fines de depuración en lugar de cualquier contenido de Google.

Cuando hace clic en el símbolo de bloqueo, el navegador le dice que la conexión ha sido aceptada como válida y confiable y que la CA raíz first «Sectigo ECC» había firmado el certificado del servidor.

Pero sabemos que este no fue el caso, y en contraste con nuestras propias suposiciones originales, Home windows ni siquiera verificó el certificado del servidor contra el «Sectigo ECC». Lo comparó con la CA falsificada incluida. Eso se puede ver, cuando haces otro clic para «Ver certificados»:

Como muestra la captura de pantalla, todavía estamos en la misma sesión SSL (la clave maestra es la misma en ambas imágenes), pero ahora Windows está mostrando que el emisor (correcto) del certificado del servidor es nuestra «EVIL CA» falsificada.

La verificación de firma criptográfica de Windows funciona correctamente

¡La buena noticia es que Windows realmente no tiene un problema con las funciones criptográficas para validar la firma de un certificado de curva elíptica! Esa verificación funciona correctamente. El problema es cómo se realiza la comparación de la cadena de confianza para demostrar que la cadena de firmas termina correctamente en el catálogo de CA raíz de confianza.

Asumimos que un ataque usaría una CA firmante que apunta a una entrada en el almacén de Root CA confiable y la verificación de la firma sería limitada para que la firma fuera aceptada, aunque no fue firmada con esa CA authentic sino una CA falsificada. Pero, de hecho, Windows está validando la cadena de certificados incrustada, que es perfectamente válida y criptográficamente correcta, y luego hace coincidir el certificado de firma con las entradas en el almacén confiable de Root CA. Esta última pieza es lo que no se ha hecho correctamente (antes del parche del sistema).

Nuestras pruebas revelaron que Home windows ni siquiera intenta igualar los certificados. Solo coincide con la clave pública de los certificados (y algunas comparaciones y verificaciones más), lo que hace que la comparación sea incompleta. Ese fue el mistake authentic de esta vulnerabilidad (al menos en lo que respecta a los certificados del sitio world-wide-web).

Trusted Certificate Retail store es en realidad una Trusted General public Crucial Shop

Cuando hablamos de la cadena de confianza en la comunicación SSL / TLS, nos referimos a una cadena de certificados firmados por una CA hasta que lleguemos a una CA raíz confiable. Pero Microsoft parece ignorar los certificados en su mayor parte y administra una cadena de claves públicas de certificados. La comparación también está comparando el algoritmo. En un momento en que solo se usaban certificados RSA, eso era suficiente. Un atacante no pudo crear su propio par de claves con la misma clave pública que el certificado de confianza. Con la introducción de la criptografía de curva elíptica (ECC), la comparación de Microsoft de solo el algoritmo y la clave pública está fallando. No puede comparar también las características de la curva elíptica misma. Sin este parámetro adicional, simplemente crea la misma clave pública (punto de curva) nuevamente en una curva diferente. Esto es lo que se corrigió en Patch-Tuesday: la comparación de la información de clave pública ahora incluye las características de la curva.

Esta captura de pantalla muestra que el certificado initial en el lado derecho y la CA falsificada a la izquierda son muy diferentes. Nombre común diferente y una curva elíptica totalmente diferente (una curva estándar para la CA initial y una hecha a mano para la versión falsificada), pero la firma que se ve debajo de la entrada «pub» es idéntica. Eso ha sido suficiente para hacer que Home windows crea que la CA falsificada incorporada era la misma que la CA de confianza en el almacén de certificados.

¿Por qué no comparar certificados por nombre o número de serie?

Un algoritmo diferente (y quizás más natural) es comparar los certificados por su nombre común y / o su número de serie y, siempre que tenga una coincidencia, continúe la cadena de confianza y la verificación con el certificado en el almacén de confianza. ¿Por qué Home windows compara las claves públicas en su lugar? Solo podemos especular, pero la ventaja podría ser para las empresas que desean intercambiar sus certificados sin implementar nuevas CA raíz en todos los equipos cliente. Think about una organización que mantiene su propia PKI e instala su propia CA raíz en el almacén de certificados de confianza. Cuando estas compañías pasan por fusiones y adquisiciones y el nombre de la compañía puede cambiar. Este sería un buen momento para cambiar también el nombre común de su certificado de firma. Sin embargo, si no tiene una buena manera de mantener a distancia a todos los clientes y actualizar el certificado en la tienda de confianza, es más fácil decirle a la Cooperación que use el par de claves públicas y privadas originales y cree un nuevo certificado con ese mismo Par de claves. El nuevo certificado seguirá coincidiendo con el anterior y no es necesaria ninguna otra actualización del cliente. ¡Conveniente! ¿Pero es seguro? En este punto, no es realmente una cadena de certificados confiables sino una cadena de claves públicas confiables.

Probamos si esto también podría ser mal utilizado para crear un nuevo certificado cuando el anterior haya expirado, pero ese no es el caso. Después de comparar las claves públicas, Home windows sigue utilizando la fecha de vencimiento del certificado en el almacén de confianza para determinar si la cadena sigue siendo válida, lo cual es bueno.

¿Cómo endurecer el proceso?

El problema raíz de este enfoque es que la verificación criptográfica completa ocurre con los certificados incrustados y solo después de la verificación se realiza la comparación con la entrada en el almacén de CA raíz de confianza. Eso siempre tiene margen para descuidos y algoritmos de coincidencia incompletos, como hemos visto con esta vulnerabilidad. Un enfoque seguro es hacer coincidir primero los certificados (o claves públicas), encontrar la entrada correspondiente en el almacén de Reliable Root CA y luego usar ese certificado de confianza para continuar con la verificación de la firma. De esa manera, la verificación falla en el lado seguro y las cadenas rotas se pueden identificar fácilmente.

No sabemos si eso se ha cambiado con la versión parcheada de Home windows o si solo se ha mejorado el algoritmo de coincidencia. Si no, recomendamos revisar este enfoque alternativo y fortalecer aún más la implementación en el sistema operativo y el navegador.





Enlace a la noticia initial