CurveBall: un juego de palabras sin imaginación pero un error devastador


Los clientes empresariales que buscan información sobre cómo defenderse de Curveball pueden encontrar información aquí.

2020 llegó con una explosión este año, y no fue por el número récord de fuegos artificiales en exhibición en todo el mundo para celebrar el nuevo año. En cambio, poco más de dos semanas en la década, el mundo de la seguridad se vio sacudido por una solución para CVE-2020-0601 introducido en el primer parche de Microsoft el martes del año. El error fue enviado por la Administración de Seguridad Nacional (NSA) a Microsoft, y aunque inicialmente se consideró solo «importante», no pasó mucho tiempo para que todos descubrieran que este mistake debilita fundamentalmente todo el concepto de confianza en el que confiamos sitios internet seguros y validar archivos. La vulnerabilidad se basa en ECC (criptografía de curva elíptica), que es un método muy común para firmar certificados digitalmente, incluidos los incrustados en los archivos y los utilizados para proteger las páginas internet. Representa una combinación matemática de valores que producen una clave pública y privada para el intercambio confiable de información. Ignorando los detalles íntimos por ahora, ECC nos permite validar que los archivos que abrimos o las páginas world wide web que visitamos han sido firmadas por una autoridad reconocida y confiable. Si se rompe esa confianza, los actores maliciosos pueden «falsificar» archivos y sitios net firmados y hacer que se vean para la persona promedio como si todavía fueran de confianza o legítimamente firmados. La falla radica en la biblioteca de Microsoft crypt32.dll, que tiene dos funciones vulnerables. El mistake es sencillo en el sentido de que estas funciones solo validan el valor de la clave pública cifrada, y NO los parámetros de la curva ECC en sí. Lo que esto significa es que si un atacante puede encontrar la combinación matemática correcta de clave privada y la curva correspondiente, puede generar el valor de clave pública idéntico a la autoridad de certificación de confianza, sea quien sea. Y dado que este es el único valor verificado por las funciones vulnerables, los parámetros «maliciosos» o inválidos serán ignorados, y el certificado pasará la verificación de confianza.

Tan pronto como nos enteramos de la falla, el equipo de Investigación Avanzada de Amenazas de McAfee se propuso crear una prueba de concepto (PoC) que nos permitiera activar el error y, en última instancia, crear protecciones en una amplia gama de nuestros productos para asegurar a nuestros clientes Pudimos lograr esto en cuestión de horas, y en un día o dos aparecieron los primeros signos de PoC públicas a medida que la vulnerabilidad se comprendía mejor y los investigadores descubrían la relativa facilidad de explotación.

Hagamos una pausa por un momento para celebrar el hecho de que (aparte de las teorías de la conspiración) el gobierno y el sector privado se unieron para informar, parchar y divulgar públicamente una vulnerabilidad antes de que fuera explotada en la naturaleza. También queremos llamar Programa de protección activa de Microsoft, que proporcionó algunos detalles básicos sobre la vulnerabilidad, lo que permitió a los profesionales de seguridad cibernética obtener un poco de ventaja en el análisis.

A continuación se proporcionan algunos detalles técnicos básicos y un cronograma del trabajo que hicimos para analizar, realizar ingeniería inversa y desarrollar exploits de trabajo para el error. Este weblog se centra principalmente en los esfuerzos de investigación detrás de los certificados de firma de archivos. Para un análisis más profundo del vector net, consulte esta publicación.

Creando la prueba de concepto

El punto de partida para simular un ataque era tener una comprensión clara de dónde estaba el problema. Un atacante podría falsificar un certificado raíz ECC con la misma clave pública que una CA raíz de ECC de Microsoft, como la Autoridad de certificación raíz de producto ECC 2018, pero con diferentes «parámetros», y aún sería reconocido como una CA de Microsoft confiable. La API usaría la clave pública para identificar el certificado, pero no verificará que los parámetros proporcionados coincidan con los que deben ir con la clave pública de confianza.

Ha habido muchos casos de ataques de criptografía que aprovecharon el fracaso de una API para validar parámetros (como estas dos) y atacantes que explotan este tipo de vulnerabilidad. Al enterarse de los parámetros no válidos, debe aparecer una bandera roja de inmediato.

Para minimizar el esfuerzo, un paso inicial importante es encontrar el nivel correcto de abstracción y detalles que debemos preocuparnos. Los detalles mínimos sobre el error se refieren a parámetros de clave pública y curva y nada sobre detalles específicos de firma, por lo que probablemente leer sobre cómo generar clave pública / privada en la criptografía de curva elíptica (CE) y cómo definir una curva debería ser suficiente.

La primera parte de esto Artículo de Wikipedia determine la mayor parte de lo que necesitamos saber. Hay un punto G que está en la curva y se united states of america para generar otro punto. Para crear un par de claves públicas / privadas, tomamos un número aleatorio k (la clave privada) y lo multiplicamos por G para obtener la clave pública (Q). Entonces, tenemos Q = k * G. Cómo funciona esto realmente no importa para este propósito, siempre y cuando la multiplicación escalar se comporte como es de esperar. La plan aquí es que conociendo Q y G, es difícil recuperar k, pero conociendo k y G, es muy fácil calcular Q.

Reformulando esto en la perspectiva del error, queremos encontrar una nueva k &#39(una nueva clave privada) con diferentes parámetros (una nueva curva, o tal vez una nueva G) para que la matemática ECC devuelva la misma Q. La solución más fácil es considerar un nuevo generador G &#39que sea igual a nuestra clave pública objetivo (G&#39 = Q). De esta manera, con k ’= 1 (una clave privada igual a 1) obtenemos k’G’ = Q que satisfaría las restricciones (encontrar una nueva clave privada y mantener la misma clave pública).

El siguiente paso es verificar si realmente podemos especificar una G personalizada mientras especificamos la curva que queremos usar. La documentación de Microsoft no es especialmente clara sobre estos detalles, pero OpenSSL, una de las bibliotecas de criptografía más comunes, tiene un página que explain cómo generar pares de claves y certificados EC. El siguiente comando muestra los parámetros estándar de la curva P384, la utilizada por Microsoft ECC Root CA.

Valores de parámetros de curva elíptica

Podemos ver que uno de los parámetros es el generador, por lo que parece posible modificarlo.

Ahora necesitamos crear un nuevo par de claves con parámetros explícitos (para que todos los parámetros estén contenidos en el archivo de claves, en lugar de simplemente incorporar el nombre estándar de la curva) y modificarlos siguiendo nuestra hipótesis. Reemplazamos el generador G &#39por la Q del certificado de Microsoft, reemplazamos la clave privada k&#39 por 1 y, por último, reemplazamos la clave pública Q &#39del certificado que acabamos de generar por la Q del certificado de Microsoft.

Para asegurarnos de que nuestra modificación sea funcional y que la clave modificada sea válida, utilizamos OpenSSL para firmar un archivo de texto y verificar con éxito su firma.

Firmar un archivo de texto y verificar la firma con el par de claves modificado (k ’= 1, G’ = Q, Q ’= Q)

A partir de ahí, seguimos un par de tutoriales para crear un certificado de firma usando OpenSSL y firmamos binarios personalizados con signtool. Finalmente, nos saludan con un ejecutable firmado que parecía estar firmado con un certificado válido.

Certificado falsificado / falsificado aparentemente firmado por Microsoft ECC Root CA

Usando Sysinternal’s SigChecker64.exe junto con Rohitab Keep track of de API (que, irónicamente, está en un sitio que no usa HTTPS) en un sistema sin parches con nuestro PoC, podemos ver claramente la vulnerabilidad en acción por los valores de retorno de estas funciones.

Rohitab API Keep an eye on – Llamadas API para verificación de certificados

Las vulnerabilidades de toda la industria parecen estar ganando masa crítica y aumentando la visibilidad incluso para usuarios no técnicos. Y, por una vez, el nombre «lindo» de la vulnerabilidad apareció relativamente tarde en el proceso. La visibilidad es crítica para el progreso, y una comprensión y un respeto saludable por el impacto potencial son factores clave para que las empresas y las personas apliquen rápidamente parches y reduzcan drásticamente el vector de amenazas. Esto es aún más esencial con un error que es tan fácil de explotar y que probablemente tenga un impacto inmediato de explotación en la naturaleza.

Respuesta de McAfee

McAfee desarrolló agresivamente actualizaciones en todas sus líneas de productos. Detalles específicos se pueden encontrar aquí.





Enlace a la noticia first