Résumé

  • Le certificat frauduleux de Flame remontait jusqu’à une racine Microsoft sans que la clé privée de cette racine ait été récupérée. Une émission prévisible dans le service de licences Terminal Server et une collision MD5 à préfixes choisis ont permis à une signature légitime de valider un autre certificat, débarrassé de l’extension critique qui bloquait la signature de code sur les Windows récents.
  • La réparation a dû retirer une capacité, pas seulement un fichier : Microsoft a placé toute la hiérarchie de licences dans le magasin non fiable, isolé la nouvelle chaîne sous une racine autonome, supprimé la signature de code, imposé un usage étendu propre aux licences, renforcé le canal de mise à jour et accéléré la diffusion du refus vers les clients.

Une signature correcte posait une question incomplète

En juin 2012, la surprise n’était pas de trouver un composant de Flame sans signature. C’était de voir une signature que Windows pouvait faire remonter vers une racine Microsoft.

Une telle chaîne répond à une question mathématique : la signature correspond-elle à cette clé et cette clé appartient-elle à une chaîne acceptée localement ? Elle ne répond pas seule à la question institutionnelle : cette chaîne avait-elle reçu le droit de parler au nom du canal de mise à jour ? L’incident est né dans l’espace entre ces deux réponses.

L’avis de sécurité 2718704, publié le 3 juin 2012, signalait des attaques actives utilisant des certificats non autorisés dérivés d’une autorité Microsoft. L’enquête remonta au service de licences Terminal Server, destiné à autoriser l’usage de Remote Desktop dans les entreprises. Ce service utilisait un ancien algorithme et délivrait des certificats capables de signer du code.

Le défaut n’était donc pas seulement « MD5 existe encore ». Une fonction administrative étroite disposait d’un chemin vers une racine dont les clients reconnaissaient une portée bien plus large. La proximité au sein d’une même entreprise s’était transformée en équivalence de pouvoir.

Une racine n’accorde pourtant pas une confiance indivisible. Elle ouvre un calcul où interviennent la politique d’émission, les extensions, l’usage de clé, l’usage étendu, les règles de l’application et l’état local de défiance. Si une chaîne de licences peut autoriser un paquet logiciel, le graphe de certificats a laissé une finalité déborder sur une autre.

Une autorité d’émission trop prévisible

Le processus d’inscription aux licences était accessible sans entrer dans la PKI interne de Microsoft. Les périodes de validité étaient connues et les numéros de série pouvaient être prévus avec une forte probabilité. L’autorité signait en md5RSA.

Ces propriétés se renforçaient. Une collision à préfixes choisis ne modifie pas après coup un certificat déjà signé. L’attaquant prépare deux débuts différents : l’un décrit le certificat que l’autorité pense délivrer, l’autre le certificat qu’il veut utiliser. Il calcule ensuite des suffixes afin que les deux objets complets produisent la même empreinte MD5. L’autorité signe l’empreinte du premier ; la même signature se vérifie sur le second.

Pour réussir contre une autorité vivante, il faut anticiper les champs qu’elle insérera. Des numéros de série prévisibles et des dates connues réduisent l’incertitude. L’inscription fournit l’opération de signature. MD5 ne garantit plus qu’une empreinte désigne un message unique. La racine largement reconnue donne une valeur opérationnelle au résultat.

Cette composition explique pourquoi les inventaires par technologie sont insuffisants. Une ligne « algorithme MD5 », une ligne « modèle de certificat », une ligne « point d’inscription » et une ligne « magasin racine » paraissent gérables séparément. Leur produit constitue pourtant une autorité capable de faire exécuter du code.

La suppression d’un seul facteur aurait changé le scénario : un algorithme résistant aux collisions, des champs non prévisibles, une racine de licences non reconnue par les clients ordinaires ou une finalité strictement imposée auraient cassé la chaîne d’exploitation.

La collision n’était pas un vol de clé

Marc Stevens, cryptanalyste au CWI, conclut que Flame utilisait une variante jusque-là inconnue d’une collision à préfixes choisis. Elle différait de la construction publique de 2009, qui avait déjà montré comment un certificat légitime et un certificat d’autorité pirate pouvaient partager une empreinte MD5.

Il faut préserver cette précision. Les sources n’indiquent pas que la clé privée racine de Microsoft, ni celle de l’autorité intermédiaire, ait été extraite. L’autorité légitime a effectué une signature normale avec sa clé. L’attaquant a fait en sorte qu’elle porte simultanément sur un autre contenu.

L’absence de vol matériel ne réduit pas la gravité. La garde des clés n’est qu’une limite parmi d’autres. Quand une autorité signe une empreinte vulnérable calculée sur une structure influencée par l’adversaire, son pouvoir peut sortir du périmètre sans que la clé quitte son module.

RFC 6151 avait déjà déclaré MD5 inacceptable lorsque la résistance aux collisions est nécessaire, notamment pour les signatures numériques. Le texte distingue ce cas de HMAC-MD5. La bonne question d’audit n’est donc pas « où voit-on MD5 ? », mais « quelle propriété attend-on de MD5, qui contrôle les messages et quelle autorité une collision recevrait-elle ? »

Dans un certificat, la résistance aux collisions doit garantir qu’une signature lie l’émetteur à un seul corps examiné. Deux corps différents sous la même empreinte brisent l’unicité de l’intention.

L’extension critique exécutait le refus

Le certificat observé avec Flame ne présentait pas les extensions attendues du système de licences : point de distribution de liste de révocation, accès aux informations de l’autorité et extension critique Microsoft Hydra. L’analyse trouva des données d’extensions structurées dans le champ obsolète d’identifiant unique de l’émetteur. L’absence décisive restait celle de Hydra.

Dans X.509, « critique » ne signifie pas simplement important. Cela ordonne au logiciel qui ne comprend pas l’extension de rejeter le certificat. RFC 5280 formalise ce comportement et décrit aussi l’intersection entre usage de clé et usage étendu.

Windows Vista et les versions suivantes appliquaient le refus pertinent. Le certificat de licences normal ne pouvait donc pas servir tel quel à la signature de code. Selon Microsoft, la collision permit de fabriquer un certificat sans l’extension critique tout en conservant l’empreinte signée. Les systèmes antérieurs à Vista pouvaient être attaqués sans collision ; cette différence appartient à Windows et ne doit pas devenir une généralité sur toutes les bibliothèques X.509.

Une extension dans un modèle n’est pas encore un contrôle. Il faut vérifier qu’elle se trouve dans les octets signés, qu’elle est critique lorsque l’échec doit être fermé, que tous les clients la traitent correctement et qu’aucune variante d’émission ne peut l’omettre. Flame ne persuada pas le client d’ignorer la règle : il présenta un objet différent où la règle avait disparu.

Le certificat avait encore besoin d’un chemin réseau

Posséder un certificat remontant à Microsoft ne livrait pas automatiquement Flame. Microsoft précisa qu’une falsification de Windows Update exigeait à la fois le certificat non autorisé et une position d’interception. Les serveurs centraux de Windows Update ne sont pas décrits comme compromis.

Trois pouvoirs doivent donc rester séparés. La construction du certificat rendait la signature acceptable. La position réseau remplaçait la réponse légitime par le paquet de l’attaquant. Les règles de l’agent de mise à jour décidaient si un paquet signé par une chaîne Microsoft suffisait pour être installé.

Le scénario réussissait par composition. Sans livraison, le certificat restait inutilisé. Sans signature acceptée, l’interception rencontrait le refus du canal. Avec une contrainte supplémentaire propre au produit et au canal, une signature d’entreprise placée au mauvais endroit aurait encore pu échouer.

Microsoft renforça donc Windows Update, WSUS et les outils d’administration associés. La leçon n’est pas de remplacer la signature par la confiance réseau, mais d’exiger plusieurs affirmations bornées : cette clé est autorisée pour ce canal ; la finalité du certificat correspond ; le paquet vise bien ce produit et cette version ; la livraison ne peut pas substituer un objet signé provenant d’un autre domaine d’autorité.

Le refus devait atteindre les machines

Microsoft ne révoqua pas uniquement le certificat connu. L’avis plaça trois intermédiaires de licences dans le magasin non fiable et l’analyse technique décrit l’invalidation de toute la hiérarchie Terminal Server, présente et passée. Cette ampleur réduisait le risque de certificats non observés et de copies de l’attaque.

La décision ne changeait pas les octets des certificats. Elle devenait effective lorsque le nouvel état de confiance atteignait un client et que le code de validation l’exécutait. La mise à jour de juin introduisit aussi, pour Windows Vista et Windows 7, un mécanisme automatique consultant chaque jour une liste de certificats interdits. Auparavant, le déplacement vers le magasin non fiable nécessitait une mise à jour manuelle.

La souplesse de confiance doit donc fonctionner dans les deux sens. Les entreprises savent provisionner une nouvelle racine ; elles mesurent moins souvent la vitesse avec laquelle elles peuvent retirer une capacité. Une liste de défiance est un plan de contrôle négatif. Elle doit rester distribuable et vérifiable même lorsque l’incident touche le canal de mise à jour ordinaire.

Le cadre publié de Heng Lu sur la primauté du code en exécution éclaire ce point sans servir de source historique. Une annonce institutionnelle n’obtient d’effet que dans les systèmes qui appliquent la règle. L’émetteur annonce, la plateforme diffuse, le client prononce le dernier non.

La nouvelle architecture retirait du pouvoir

Microsoft ne se contenta pas d’adopter un autre condensat. La nouvelle chaîne de licences fut placée sous une racine autonome que les clients Windows ordinaires ne reconnaissaient pas. Elle ne délivrait plus de certificats de signature de code et ses certificats recevaient un usage étendu propre aux licences.

Chaque mesure fermait un bord différent. L’algorithme corrigeait la liaison cryptographique. La racine séparée réduisait le rayon d’explosion. La suppression de la signature de code retirait une capacité implicite. L’EKU rendait la finalité exécutable. La défiance achevait l’ancienne chaîne. Le renforcement du canal réduisait la valeur d’une signature d’entreprise hors contexte.

Une simple rotation aurait pu reproduire le même graphe sous une nouvelle clé. Une vraie réparation inventorie les décisions que l’ancienne hiérarchie pouvait provoquer, élimine celles qui ne sont pas nécessaires et reconstruit la fonction légitime sous des pouvoirs plus étroits.

La séparation avait un coût réel

Les licences d’accès client existantes restaient valables. En revanche, les administrateurs qui devaient créer ou réactiver un serveur de licences, ou installer un nouveau lot de CAL, devaient réactiver ce serveur parce que les certificats du centre d’activation avaient changé.

Ce détail matérialise le prix du moindre privilège. Une architecture accumule souvent des pouvoirs pour éviter une gêne dans un ancien processus. Lorsqu’un pouvoir est exploité, la séparation d’urgence arrive sans inventaire et sous contrainte de temps.

Il faut donc connaître avant la crise les serveurs à réactiver, les réseaux isolés qui ne reçoivent pas la défiance, les instances WSUS à renforcer, les clients anciens qui traitent différemment les extensions et les opérations dépendantes de la hiérarchie supprimée.

La continuité de la fonction légitime ne suppose pas la continuité de l’autorité excessive. Microsoft pouvait préserver les CAL tout en rétablissant l’administration des licences sous de nouveaux certificats. Le service Remote Desktop n’avait pas besoin de conserver un droit général de signature logicielle.

Limites des preuves

Les sources primaires établissent l’abus, le chemin de licences, la collision, la différence entre générations Windows et les mesures de Microsoft. Elles ne donnent ni recensement complet des victimes ni attribution vérifiable de l’opérateur de Flame.

La collision n’a pas révélé les clés Microsoft et ne permettait pas de modifier arbitrairement tout certificat déjà émis. Elle exigeait une préparation autour d’une émission prévisible. La falsification de Windows Update exigeait aussi une position d’interception.

La nouvelle hiérarchie utilisait SHA-1 en 2012. La dépréciation ultérieure de SHA-1 appartient à une autre chronologie et ne doit pas être confondue avec l’exploitation MD5 observée. RFC 5280 et RFC 6151 fournissent le cadre technique, non l’attribution. Les notes de Heng Lu sont un cadre analytique déclaré, non une preuve de l’incident.

La conclusion défendable est précise : une chaîne de certificats est un graphe de capacités exécutables. Son autorité dépend de ce que l’émetteur signe, de la finalité encodée, de ce que l’application comprend, de la racine acceptée et de la vitesse avec laquelle le client peut apprendre à refuser.

Sources