Resumen

  • Flame presentó código firmado por un certificado que llegaba a una raíz de Microsoft sin haber robado la clave privada de esa raíz. La emisión previsible del servicio de licencias de Terminal Server y una colisión MD5 con prefijos elegidos hicieron que una firma de la CA verificase también un certificado diferente, sin la extensión crítica que impedía usarlo para firmar código en Windows Vista y posteriores.
  • La respuesta tuvo que retirar facultades en varios lugares: desconfianza de toda la jerarquía de licencias presente y pasada, una nueva raíz independiente no confiada por los clientes ordinarios, eliminación de la firma de código, EKU específico de licencias, refuerzo del canal de actualizaciones y distribución más rápida de listas locales de certificados prohibidos.

La cadena era auténtica; la competencia no

La firma hallada en Flame producía una impresión peligrosa: Windows podía recorrerla hasta una raíz de Microsoft. La criptografía respondía que una clave situada bajo esa raíz había respaldado el resumen. No respondía si una infraestructura creada para licencias de Remote Desktop tenía derecho a autorizar una actualización de software.

El aviso 2718704, publicado el 3 de junio de 2012, informó de ataques activos con certificados no autorizados derivados de una autoridad certificadora de Microsoft. La investigación señaló el servicio de licencias de Terminal Server. El servicio permitía a clientes empresariales autorizar Remote Desktop, empleaba un algoritmo antiguo y entregaba certificados con capacidad de firma de código.

Ahí estaba la primera ampliación de poder. Una función de licencias se hallaba bajo una raíz que los equipos Windows utilizaban en decisiones más amplias. La pertenencia corporativa de dos sistemas había terminado pareciéndose a una delegación técnica entre sus propósitos.

La confianza raíz no es un permiso único. Es el comienzo de una evaluación: qué CA emitió, con qué restricciones, para qué usos, cómo interpreta las extensiones la aplicación y qué estado de confianza conserva el cliente. Cuando una ruta de licencias puede hablar por el canal de software, el árbol ha dejado de ser un registro de identidad y se ha convertido en un mapa de capacidades mal delimitadas.

El oráculo de firma era previsible

El proceso de inscripción no exigía acceso interno a la PKI de Microsoft. La CA firmaba con md5RSA; las fechas de validez eran conocidas y los números de serie podían anticiparse con alta probabilidad. Cada elemento reducía la incertidumbre necesaria para preparar una colisión con prefijos elegidos.

El ataque no tomó un certificado ya emitido para editarlo libremente. Preparó dos cuerpos. Uno podía ser presentado al servicio de licencias como una solicitud normal. El otro representaba el certificado útil para el atacante. Sufijos calculados hicieron que ambos cuerpos completos tuviesen el mismo resumen MD5. La CA firmó el objeto que esperaba; esa firma también verificaba el otro.

El flujo de emisión aportó algo que una lista de algoritmos no muestra: una operación de clave privada sobre datos parcialmente moldeados por quien solicitaba el certificado. La previsibilidad permitió adivinar los campos que la CA añadiría. MD5 permitió igualar los resúmenes. La raíz ampliamente aceptada convirtió el resultado en una credencial valiosa.

La mitigación podía romper la composición en varios lugares. Un resumen resistente a colisiones impediría que dos cuerpos compartiesen la firma. Campos imprevisibles frustrarían la preparación. Una raíz de licencias ajena al almacén general reduciría el alcance. Un uso extendido impuesto por la aplicación negaría la firma de código.

Por eso el riesgo no se mide contando componentes «legacy». Se mide siguiendo la autoridad que adquiere su combinación.

No se recuperó una clave privada

Marc Stevens, del CWI, analizó el certificado y encontró una variante hasta entonces desconocida del ataque de prefijos elegidos. No era simplemente la implementación publicada en 2009, aunque aquel trabajo ya había demostrado el principio con dos certificados X.509 de identidades distintas y un único resumen MD5.

La diferencia entre colisión y robo de clave es esencial. Las fuentes no sostienen que alguien extrajera la clave raíz de Microsoft. La CA realizó una firma legítima con su clave protegida. El atacante hizo ambiguo el mensaje al que esa firma quedaba ligada.

Custodiar bien una clave no basta si el firmante acepta estructuras hostiles bajo un algoritmo incapaz de conservar la unicidad del mensaje. La autoridad puede escapar aunque la clave no abandone nunca el dispositivo que la protege.

RFC 6151 había explicado en marzo de 2011 que MD5 ya no era aceptable cuando se necesitaba resistencia a colisiones, como en firmas digitales. También distinguía esa propiedad de HMAC-MD5. Una auditoría responsable no etiqueta toda aparición de MD5 con el mismo daño. Pregunta quién controla el contenido, qué propiedad requiere el protocolo y qué poder obtendría un segundo mensaje con el mismo resumen.

En X.509, la firma debe vincular la voluntad del emisor a un cuerpo determinado. Si dos cuerpos con competencias distintas reciben el mismo resultado criptográfico, la voluntad deja de seleccionar una sola autoridad.

La extensión crítica era un veto ejecutable

El certificado de Flame carecía aparentemente de extensiones que Microsoft esperaba en la infraestructura de licencias: punto de distribución de CRL, acceso a información de la autoridad y una extensión crítica Microsoft Hydra. El análisis encontró estructura de extensiones dentro de un campo obsoleto de identificador único del emisor. La ausencia operativa de Hydra resultó clave.

En X.509, una extensión crítica obliga a rechazar el certificado cuando el cliente no sabe procesarla. RFC 5280 establece esa conducta y también explica cómo Key Usage y Extended Key Usage pueden limitar conjuntamente los fines autorizados.

Windows Vista y versiones posteriores ejecutaban el rechazo relevante. El certificado normal de licencias no servía para el objetivo de Flame. Según Microsoft, la colisión permitió crear otro sin la extensión crítica, pero con el mismo resumen firmado. En sistemas anteriores a Vista era posible un ataque sin la colisión. Es una diferencia de validación entre generaciones de Windows, no una propiedad universal de todas las implementaciones.

Una política escrita en una plantilla no es todavía un control. Hay que demostrar que la extensión queda dentro del cuerpo firmado, que es crítica cuando corresponde, que las aplicaciones materiales la interpretan igual y que ninguna variante de emisión puede omitirla. Flame no convenció al cliente de aceptar una extensión desconocida: le entregó un objeto donde el veto había desaparecido.

La firma no llevaba por sí sola el paquete

Microsoft aclaró otro límite. Para falsificar Windows Update hacían falta el certificado no autorizado y una posición de intermediario. El atacante aún debía lograr que el agente automático recibiera su paquete firmado. No se documentó una intrusión en los servidores centrales de Windows Update.

El incidente combinó tres planos. El certificado hizo aceptable la procedencia aparente. La posición de red hizo posible sustituir la entrega. La lógica del agente decidió que una firma bajo Microsoft bastaba para tratar el paquete como actualización.

Cada plano conservaba un veto. Sin entrega, la credencial no alcanzaba el objetivo. Sin firma aceptada, la sustitución fallaba. Con reglas adicionales que ligasen producto, canal, versión y firmante, un certificado corporativo fuera de propósito podía ser rechazado.

Microsoft reforzó Windows Update y los sistemas empresariales relacionados. La conclusión no es que la red deba sustituir a la firma, sino que una actualización necesita varias pruebas compatibles: clave autorizada expresamente para ese canal, propósito correcto, metadatos del producto y sesión de entrega incapaz de aceptar un paquete de otro dominio.

Terminar la autoridad exigía distribuir un «no»

El aviso no se limitó al certificado observado. Tres intermediarios de licencias fueron enviados al almacén no confiable, y Microsoft explicó que invalidó toda la jerarquía de Terminal Server, pasada y presente. La acción amplia reducía la incertidumbre sobre certificados no detectados y futuros imitadores.

Sin embargo, declarar una jerarquía no confiable no modifica los objetos ya distribuidos. El efecto aparece cuando cada equipo recibe el nuevo estado y lo aplica al validar. En junio Microsoft añadió para Windows Vista y Windows 7 un actualizador automático de la lista de certificados prohibidos, consultada diariamente. Antes, trasladar un certificado al almacén no confiable requería una actualización manual.

La agilidad de confianza tiene una cara negativa. Crear una raíz o desplegar una clave nueva es solo la mitad del sistema. La otra mitad es poder retirar con rapidez una competencia, medir quién ha recibido la prohibición y sostener ese canal cuando la propia infraestructura de actualización está bajo sospecha.

Las notas públicas de Lu Heng sobre la primacía del código sirven aquí como marco declarado, no como fuente del incidente. La decisión institucional termina en el software que la ejecuta. Microsoft podía anunciar y distribuir; cada cliente materializaba la negativa.

La solución correcta no fue una simple rotación

La nueva infraestructura de licencias dejó de encadenar con la raíz Microsoft usada por los clientes ordinarios. Se colocó bajo una raíz independiente que Windows no confiaba de forma general, dejó de emitir certificados de firma de código y adoptó un EKU no válido para esa finalidad.

La modificación del algoritmo protegía la firma. La raíz separada reducía el radio de impacto. El EKU convertía el propósito en una restricción de máquina. El fin de la firma de código retiraba una competencia innecesaria. La desconfianza cerraba el camino antiguo. El refuerzo del canal impedía que una firma corporativa cualquiera heredase el derecho a actualizar.

Rotar una clave sin revisar estas relaciones habría reproducido la misma arquitectura. La reparación completa pregunta qué decisiones podía causar la jerarquía anterior, cuáles necesitaba de verdad el negocio y qué clientes debían dejar de aceptarla.

El negocio legítimo pagó parte de la reparación

Los CAL de Terminal Server existentes no quedaron anulados. Pero quien necesitaba crear o reactivar un servidor de licencias, o instalar un nuevo paquete de CAL, debía reactivar el servidor porque habían cambiado los certificados del centro de activación.

Esa consecuencia muestra por qué la separación debe diseñarse antes de una crisis. Compartir autoridad abarata una integración antigua; retirarla de emergencia descubre dependencias que nadie había valorado. El inventario debe incluir servidores aislados, administradores, WSUS, generaciones de cliente, centros de activación y procedimientos de recuperación.

Continuidad no significa mantener intacta la autoridad antigua. Era posible conservar el valor de las licencias y restablecer su administración con certificados nuevos sin devolver a la función de licencias poder de firma sobre software.

Límites de la evidencia

Las fuentes describen abuso activo, la ruta de licencias, el mecanismo criptográfico y la respuesta. No proporcionan un censo completo de víctimas ni una atribución verificable del operador de Flame.

La colisión no reveló claves privadas y no permite editar cualquier certificado existente. Exigió preparación ante una emisión influenciable y previsible. La imitación de Windows Update necesitó además una posición de intermediario.

La jerarquía sustituta usó SHA-1 en 2012. Su deprecación posterior es contexto histórico, no prueba de que la decisión de 2012 fuese idéntica al fallo MD5 explotado. RFC 5280 y RFC 6151 explican propiedades generales. Las notas de Lu Heng son un lente analítico declarado.

La conclusión firme es que una cadena de certificados es un grafo de capacidades que se ejecuta. Su seguridad depende de lo que la CA puede firmar, del propósito codificado, de lo que entiende la aplicación, de la raíz que acepta el cliente y de la rapidez con que ese cliente puede aprender a decir que no.

Fuentes