¿Qué falla criptográfica fue explotada por Flame, para obtener su código firmado por Microsoft?

Hay dos vulnerabilidades aquí:

• Firma de código sin restricciones. Microsoft brindó a los usuarios de Servicios de Terminal Server la capacidad de obtener un certificado de firma que se encadena a la raíz de Microsoft. De manera inadvertida, permitieron que este certificado se usara para firmar el código. Por lo tanto, los usuarios pueden firmar cualquier código que les guste y hacer que parezca que fue aprobado por Microsoft. ¡Ay! Muy mal.

  Esta vulnerabilidad se puede explotar en sistemas anteriores a Windows Vista (por ejemplo, en Windows XP). Sin embargo, debido a las nuevas medidas de fortalecimiento introducidas en Vista, esta vulnerabilidad ya no es explotable para la firma de código en Windows Vista o posterior, por sí sola.

• Ataques de colisión. Uno de los certificados de la cadena usa MD5 . Se sabe que MD5 es vulnerable a los ataques de colisión, y se sabe cómo usar estos ataques para explotar cualquier autoridad de certificación que use MD5. Esto hizo posible que el atacante obtuviera cualquier código de su elección firmado, de manera que pareciera que fue aprobado por Microsoft. (Consulte la respuesta de @ Hendrik para obtener más información). Esto también es muy malo.

  Esta vulnerabilidad les permitió evitar el endurecimiento relacionado con Vista. Por lo tanto, la combinación de estas dos vulnerabilidades permitió a los atacantes atacar con éxito a todos los sistemas operativos de Windows: pudieron firmar su código malicioso para que pareciera que provenía de Windows.

Estas son dos vulnerabilidades separadas (pero relacionadas). Flame usa los dos en combinación, lo que permite a Flame atacar con éxito todas las plataformas de Windows. Estas vulnerabilidades han estado presentes durante muchos años. Alguien podría haber explotado con la misma facilidad la vulnerabilidad anterior, aunque solo tendría éxito contra las plataformas pre-Vista.

Recursos para leer más:

• Una excelente publicación de blog que explica todo esto con más detalle: enlace

• Microsoft escribió :

    

  El malware Flame utilizó un ataque de colisión criptográfico en combinación con los certificados del servicio de licencias del servidor de terminal para firmar el código como si fuera de Microsoft. Sin embargo, la firma de código sin realizar una colisión también es posible.

• Microsoft también escribió :

    

  de forma predeterminada, el certificado del atacante no funcionaría en Windows Vista o en versiones más recientes de Windows. Tuvieron que realizar un ataque de colisión para falsificar un certificado que sería válido para la firma de código en Windows Vista o versiones más recientes de Windows. En los sistemas que son anteriores a Windows Vista, es posible un ataque sin una colisión de hash MD5.

• El ataque de colisión aparentemente implicó el desarrollo de un nuevo ataque de colisión en MD5, diferente de los que se conocían anteriormente en la literatura de investigación abierta. Consulte los informes de Ars Technica ( los avances de criptografía Flame fue diseñado por científicos de clase mundial ) y < a href="http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware"> análisis de Marc Stevens .

  

Actualización: Microsoft publicó un informe que confirma las conjeturas en esta publicación y brinda un gran nivel de detalles.

Propósito del certificado

Hay varios propósitos para los que se puede usar un certificado. Por ejemplo, se puede utilizar como prueba de identidad de una persona o servidor web. Se puede utilizar para la codificación de códigos o para firmar otros certificados.

En este caso, un certificado destinado a firmar la información de la licencia pudo firmar el código.

Podría ser tan simple como que Microsoft no comprueba el indicador de propósito de los certificados de clientes que firmaron:

  

Específicamente, cuando un cliente de empresa solicita una licencia de activación de Servicios de Terminal Server, el certificado emitido por Microsoft en respuesta a la solicitud permite la firma del código.

Ataque de colisión MD5

La referencia a un algoritmo antiguo podría indicar un ataque de colisión en el proceso de firma: hubo una charla en CCC 2008 llamada MD5 considerada dañina hoy - Creación de un certificado de CA deshonesto

• sitio web
• Diapositivas
• Video

En esa charla, las investigaciones explicaron cómo generar dos certificados con el mismo hash.

El generó una solicitud de certificación de aspecto inofensivo y la envió a una CA. La CA lo firmó y generó el certificado válido para servidores https.

Pero este certificado tenía el mismo hash que otro certificado generado que tenía el propósito CA-certificado. Por lo tanto, la firma CA del certificado inocuo también fue válida para el peligroso.

Las investigaciones explotaron una debilidad en MD5 para generar colisiones. Para que el ataque funcionara, tenían que predecir la información que la CA escribiría en el certificado.

¿Lecciones aprendidas?

• Microsoft ya verifica que la raíz de los certificados de firma de código para Windows Update sea una CA de Microsoft. Por lo tanto, los certificados firmados por otras entidades emisoras de certificados no pueden utilizarse.

• No olvide el código y los servicios heredados

• Si hay suficiente motivación, incluso las debilidades teóricas poco prácticas, serán explotadas. (El título original de la charla fue "Hacer lo posible teóricamente").

Actualizar

Microsoft ha confirmado ambos problemas (un solo problema es suficiente para un exploit):

  

El malware Flame utilizó un ataque de colisión criptográfico en combinación con los certificados del servicio de licencias del servidor de terminal para firmar el código como si fuera de Microsoft. Sin embargo, la firma de código sin realizar una colisión también es posible.

Actualización 2

Microsoft publicó los detalles :

• La vulnerabilidad de no verificar la finalidad del certificado solo afecta a las versiones anteriores de Windows.
• El ataque de colisión se usó para manipular las extensiones de certificado, de modo que las versiones actuales de Windows también se engañen.

Actualización 3

Los investigadores del ataque de colisión md5 original publicaron que los atacantes utilizaron una nueva variante del conocido ataque de prefijo elegido md5 , lo que implica que tienen un conocimiento muy profundo sobre la criptografía.

Buena pregunta :) No estoy seguro si hay una respuesta obvia.

No pensé que era un alogoritmo que se rompió como tal sino un certificado robado.

Supongo que una lección es que el modelo de CA está roto pero probablemente ya lo sabías antes. Así que parece que se utilizó un certificado real de "Microsoft" para firmar Flame. SANS ha publicado lo siguiente: enlace . Actualmente, nadie parece saber cómo fue robado, etc. o quién lo hizo todavía, pero si el gobierno de los Estados Unidos (que muchos sospecharon originalmente) realmente robaría un certificado de Microsoft, ¿quién sabe?

Me encanta la parte del enlace que proporcionó donde dice Microsoft -

"Además, la mayoría de los productos antivirus detectarán y eliminarán este malware".

Creo que el incidente de Flame es una prueba más de que la industria AV es completamente reaccionaria, muy orientada a la comercialización y ya no es efectiva (incluso Mikko Hyponnen dijo que fue un fallo en Wired durante el fin de semana - enlace ).

Hyponnen publicó una foto de cómo se verían los certificados robados utilizados en Flame en Windows 7 antes de revocarlos - enlace .

Alguien que sabe mucho más que yo sobre certs, etc. (Moxie Marlinspike) hizo una gran publicación sobre ese tema el año pasado: enlace . He estado jugando un poco con Convergence (http://convergence.io) y probablemente lo buscaré más, aunque es esencialmente para navegar y, lamentablemente, no será de ayuda. La gran mayoría de los usuarios no saben cómo verificar certificados en su navegador o entienden cómo funciona, por no hablar de los certificados de controladores. Supongo que es otro ejemplo de la importancia de comprender realmente lo que usted (o sus usuarios) están ejecutando, haciendo y lo que es el tráfico normal. Crear una política que permita un buen tráfico conocido y negar todo lo que no se permite explícitamente (a Internet) ayuda a reducir la superficie y las capacidades de ataque.

  

Este consejo es para aquellos que requieren la mayor seguridad, y no para el usuario de Internet informal

Una lección que podemos aprender es reducir el área de superficie de confianza pública . No sé qué jerarquía raíz específica se vio comprometida, pero en general, la confianza PKI pública fuera de la caja es demasiado amplia en mi opinión.

Sugeriría eliminar todos los certificados raíz no esenciales de sus hosts excepto los que se enumeran aquí :

Issued to                              Issued by                            Serial number                   Expiration date Intended purposes   Friendly name                        Status
Microsoft Root Authority               Microsoft Root Authority         00c1008b3c3c8811d13ef663ecdf40  12/31/2020  All                     Microsoft Root Authority                R
Thawte Timestamping CA                 Thawte Timestamping CA           00                              12/31/2020  Time Stamping           Thawte Timestamping CA                  R
Microsoft Root Certificate Authority   Microsoft Root Certificate Authority 79ad16a14aa0a5ad4c7358f407132e65 5/9/2021   All                     Microsoft Root Certificate Authority    R

Luego pida a Microsoft que limite esas raíces confiables al mínimo de EKU, como la firma de código, etc. Incluso la lista restringida de 3 certificados tiene demasiado permiso.

Los usuarios ocasionales que insisten en eliminar los certificados de raíz deben consultar esta respuesta en relación con el motivo por el que se colocaron las CA. La metodología y los requisitos de seguridad de cada raíz, aproximadamente.