WannaCry et MS17-010 : fenêtre d’exposition et correctifs

Le 12 mai 2017, WannaCry chiffre plus de 200 000 machines dans 150 pays en se propageant seul par EternalBlue, un exploit de SMBv1 (Server Message Block version 1). Le correctif MS17-010 existait depuis le 14 mars. La leçon tient en une ligne : la fenêtre d’exposition, c’est le délai entre le correctif publié et le correctif déployé, et un exploit public ramène la marge de ce délai à zéro.

→ Lire l’explication complète de la marmotte

Chronologie de MS17-010 à WannaCry : la fenêtre d’exposition

Le bulletin MS17-010 corrige six vulnérabilités de SMBv1, de CVE-2017-0143 à CVE-2017-0148. Une CVE (Common Vulnerabilities and Exposures) est l’identifiant public d’une vulnérabilité. EternalBlue exploite CVE-2017-0144 : une exécution de code à distance, sans authentification, sur le service de partage de fichiers. C’est la pire catégorie possible, sur le service le plus répandu des réseaux Windows.

Un mois après le correctif, le 14 avril, les Shadow Brokers publient un lot d’outils attribués à l’Equation Group, un groupe lié à la NSA (National Security Agency). Le lot contient EternalBlue et la porte dérobée DoublePulsar. À partir de ce jour, la vulnérabilité n’est plus théorique : un outil opérationnel circule librement. Le schéma montre que la fenêtre d’exposition ne commence pas le 12 mai, mais dès le 14 avril, pour tout parc qui n’a pas encore déployé le correctif.

Entre le bulletin et la vague, un parc géré au rythme mensuel classique (recette, comité de changement, déploiement par vagues) avait le temps de passer MS17-010. Beaucoup ne l’ont pas fait. Renault arrête la production de plusieurs usines françaises, dont Sandouville, le week-end du 13 mai. Telefónica est touchée en Espagne, les panneaux d’affichage des gares de Deutsche Bahn affichent la note de rançon, FedEx est atteint. Brad Smith, président de Microsoft, compare la fuite au vol de missiles Tomahawk dans un arsenal de l’armée américaine. La comparaison est juste, à ceci près que les missiles avaient reçu leur antidote un mois avant le vol.

Propagation par EternalBlue sur SMBv1 et le port 445

WannaCry n’a pas besoin d’un clic. C’est un ver : une fois installé sur une machine, il cherche le port TCP (Transmission Control Protocol) 445 sur le réseau local et sur des adresses Internet tirées au hasard. Si le service SMBv1 répond et n’est pas corrigé, EternalBlue y exécute du code, DoublePulsar sert de point d’injection, la charge chiffrante s’installe, et la nouvelle victime reprend le balayage. La progression est géométrique tant que chaque saut trouve une cible.

Le schéma identifie les deux conditions qui doivent être réunies à chaque saut : le correctif absent et le port 445 joignable. Retirer l’une des deux suffit à couper la chaîne.

L’ironie la plus instructive vient des statistiques de Kaspersky : la grande majorité des machines chiffrées tournaient sous Windows 7, pas sous Windows XP. Sur XP, l’exploit faisait le plus souvent planter la machine avant le chiffrement. Le récit qui circule encore (« WannaCry a frappé les vieux systèmes ») est donc faux. Le problème n’était pas l’âge du système, c’était un système supporté dont personne n’avait installé le correctif disponible. Ce qui est nettement moins confortable à présenter en comité de direction.

La rançon, elle, était de 300 dollars en bitcoins, doublée après trois jours. Les recettes sont restées faibles au regard des dégâts : comme modèle économique, le rançongiciel qui chiffre des panneaux de gare sans canal fiable de déchiffrement relève plus du sabotage que du commerce. En décembre 2017, les gouvernements américain et britannique attribuent l’attaque au groupe Lazarus, lié à la Corée du Nord.

Kill switch et correctif Windows XP : ce qui a stoppé WannaCry

Avant de chiffrer, le ver tentait de joindre un nom de domaine non enregistré. Si le domaine répondait, il s’arrêtait. Le 12 mai, Marcus Hutchins (MalwareTech) enregistre ce domaine, et chaque nouvelle infection qui arrive à le joindre s’éteint d’elle-même. La propagation ralentit dans la journée.

Deux enseignements d’architecture en sortent. D’abord, le kill switch ne fonctionne que si la machine infectée résout le nom par DNS (Domain Name System) et joint le domaine en direct. Les analyses publiées ont montré que cette vérification ne passait pas par un proxy explicite : sur un réseau qui impose un proxy pour sortir, le domaine restait injoignable et le ver continuait. Pendant la crise, la mesure efficace était de faire résoudre le domaine en interne vers un serveur qui répond, plutôt que de compter sur l’accès Internet des postes. Ensuite, un arrêt d’urgence dépend de la bonne volonté de l’auteur du code. Les variantes suivantes ont retiré ou modifié ce domaine. Ce n’est pas une défense, c’est un accident heureux.

Le soir même, Microsoft publie un correctif exceptionnel pour Windows XP, Windows Server 2003 et Windows 8, tous hors support. Ce geste ne doit pas être lu comme une garantie future : un système hors support se défend par l’isolement réseau, pas par l’espoir d’un correctif de crise.

Prioriser les correctifs exploités : CVE, KEV et délai de déploiement

Le compromis central est celui-ci : un cycle de déploiement lent achète de la stabilité (moins de régressions applicatives, moins d’incidents de production) et le paie en durée d’exposition. Pour l’immense majorité des correctifs, le cycle mensuel reste le bon choix. Pour un correctif dont un exploit fonctionnel est public, la règle à tenir est inverse : le déploiement sort du cycle et passe en procédure d’urgence, en jours, pas en semaines. Une régression sur un poste se répare ; un parc chiffré se reconstruit.

Le tri ne se fait pas sur le score CVSS (Common Vulnerability Scoring System) seul, qui mesure une gravité théorique. Trois signaux comptent davantage :

Exploitation constatée : le catalogue KEV (Known Exploited Vulnerabilities) de la CISA (Cybersecurity and Infrastructure Security Agency), créé en 2021, liste les vulnérabilités exploitées dans la nature. Une CVE qui y entre change de file d’attente.
Exploit public : la disponibilité d’un outil comme EternalBlue supprime le délai de développement côté attaquant. Le 14 avril 2017 aurait dû déclencher la procédure d’urgence partout où MS17-010 manquait.
Exposition réseau : une exécution de code à distance sans authentification sur un service écouté par tous les postes (SMB, RDP pour Remote Desktop Protocol) se propage en ver. Elle passe devant une élévation locale de privilège, même mieux notée.

Le prérequis de tout ce qui précède est l’inventaire. Un correctif ne se déploie que sur des machines connues, avec leur version de système et leur canal de mise à jour (WSUS pour Windows Server Update Services, Intune, Configuration Manager ou autre). Vingt ans de métier apprennent que le poste qui manque à l’inventaire est toujours celui qui pilote une machine-outil, dans un atelier où personne n’ose redémarrer quoi que ce soit. La démarche de priorisation et de déploiement par anneaux est détaillée dans le guide sur la gestion des correctifs d’un parc hétérogène.

Piège fréquent de vérification : contrôler la présence d’un numéro de KB (Knowledge Base) précis. Les correctifs Windows sont cumulatifs ; un rollup mensuel ultérieur remplace celui de mars 2017, et un audit qui cherche le KB d’origine déclare vulnérable une machine à jour (ou l’inverse, si la liste de KB est incomplète). Le contrôle fiable porte sur le niveau de build du système ou sur un scanner qui teste la vulnérabilité, pas sur un nom de fichier.

Retrait de SMBv1 et filtrage du port 445 entre postes

Le correctif ferme une vulnérabilité ; la segmentation ferme une classe de propagation. Les deux mesures sont complémentaires, et la seconde aurait arrêté WannaCry même sur un parc non corrigé.

SMBv1 date des années 1980, ne chiffre pas, ne signe pas par défaut et n’a aucune raison d’être actif sur un parc moderne. Il n’est plus installé par défaut sur les installations neuves depuis Windows 10 version 1709 (automne 2017), mais une mise à niveau en place peut l’avoir conservé. Son retrait se pilote par GPO (Group Policy Object), selon la logique décrite dans la page sur les stratégies de groupe. Le seul frein réel est l’équipement ancien (copieurs, NAS pour Network Attached Storage, automates) qui ne parle que SMBv1, d’où l’audit préalable montré plus bas. Le cas des imprimantes réseau est un classique.

Le filtrage du port 445 suit une règle sans exception : jamais d’entrée depuis Internet, et jamais entre postes de travail. Un poste n’a pas à servir de partage à un autre poste ; les services de partage vivent sur des serveurs, et seuls les serveurs de fichiers et les contrôleurs de domaine reçoivent du SMB, depuis les réseaux qui en ont besoin. Dans la topologie suivante, il faut regarder où le trafic 445 est autorisé (vers les serveurs) et où il est refusé (entre postes, et depuis l’extérieur).

Le blocage entre postes ne se fait pas qu’au pare-feu de cœur : deux postes sur le même VLAN (Virtual LAN) échangent sans le traverser. Il faut donc le doubler par le pare-feu Windows, déployé par GPO, et si le commutateur le permet, par l’isolation de ports. Bloquer 445 entre postes coupe aussi une partie des mouvements latéraux classiques, dont le relais NTLM.

Exemple : auditer puis retirer SMBv1 sur un parc Windows

Retirer SMBv1 à l’aveugle casse le scanner du troisième étage le lundi matin. La bonne séquence est d’activer l’audit, d’attendre quelques semaines, de lire qui se connecte encore en SMBv1, puis de retirer le protocole. Le schéma suit cette séquence sur un serveur ou un poste Windows : il faut y lire que la désinstallation n’arrive qu’après la période d’observation, et que chaque client SMBv1 encore vu repart dans une branche de traitement avant le retrait.

La dernière étape désinstalle le composant, ce qui vaut mieux que de le désactiver : un composant désinstallé ne se réactive pas par une modification de registre malheureuse. Le redémarrage est nécessaire ; il se planifie avec le reste de la campagne. Les clients SMBv1 relevés dans le journal se traitent un par un : mise à jour du micrologiciel, remplacement, ou isolement dans un segment dédié avec un serveur relais.

Ce que MS17-010 ne garantit pas

Le correctif protège contre CVE-2017-0143 à CVE-2017-0148, et contre rien d’autre. Un parc corrigé reste exposé à la propagation par identifiants volés : en juin 2017, NotPetya combinait EternalBlue avec la réutilisation de mots de passe administrateur récupérés en mémoire, et franchissait ainsi les machines corrigées. Contre ce vecteur, il faut des comptes d’administration locaux uniques (LAPS pour Local Administrator Password Solution), un tiering des comptes privilégiés et le même filtrage du 445 entre postes.

Le correctif ne restaure pas non plus les données déjà chiffrées. Seule une sauvegarde hors ligne, ou immuable, déconnectée des identités du domaine, permet la reprise. Une sauvegarde joignable en SMB depuis les postes est chiffrée avec le reste ; une sauvegarde jamais restaurée en test est une hypothèse, pas une sauvegarde. Enfin, il ne couvre pas les systèmes hors support ni les équipements dont le fournisseur interdit la mise à jour : ceux-là vont dans un segment isolé, sans SMB vers le reste du réseau, avec une liste explicite des flux autorisés. Pour le cas où l’alerte arrive mais n’est pas traitée, la page sur Target et l’alerte ignorée montre que la détection seule ne vaut rien sans réponse.

Exploitation : supervision du correctif, de SMB et de la reprise

La conformité aux correctifs se mesure en continu, pas lors d’un audit annuel. L’indicateur qui compte est l’âge de la plus ancienne vulnérabilité KEV encore présente sur le parc, pas le pourcentage moyen de postes à jour : 98 % de conformité laisse 2 % de cibles, et un ver n’a besoin que d’une.

Côté réseau, une alerte sur le volume de connexions TCP 445 émises par un même poste vers de nombreuses adresses détecte un balayage en quelques secondes ; c’est le comportement le plus bruyant d’un ver, et il est rare qu’un poste légitime le produise. Les journaux d’audit SMBv1 restent actifs après le retrait, pour repérer un équipement neuf qui réintroduirait le protocole. Côté reprise, les sauvegardes hors ligne se testent par restauration complète d’un échantillon à intervalle fixe, et les secrets d’accès au système de sauvegarde sont séparés de l’annuaire principal, faute de quoi un attaquant administrateur du domaine supprime les sauvegardes avant de chiffrer. D’autres retours sur des vulnérabilités exploitées faute de correctif figurent dans la section failles.

🐝 Ce qui arrive si on s’en passe

Sans priorisation des correctifs exploités, une vulnérabilité dont l’exploit est public attend le cycle mensuel, et chaque jour d’attente laisse un service réseau exécuter le code de n’importe qui. Sans filtrage du port 445 entre postes, une seule machine compromise suffit pour que l’infection franchisse tout le réseau local sans intervention humaine, plus vite que toute équipe d’astreinte. Sans retrait de SMBv1, un équipement ancien rouvre le protocole sans que personne ne le sache. Sans sauvegarde déconnectée, la reprise dépend de la clé de déchiffrement de l’attaquant, qui ne l’envoie pas toujours.

🦫 Explication de la marmotte 🍫

Les ordinateurs Windows partagent des fichiers grâce à un service appelé SMB, qui attend des demandes sur une porte réseau numérotée 445. Une ancienne version de ce service contenait une erreur : en lui envoyant un message mal formé, un inconnu pouvait lui faire exécuter n’importe quel programme. Le 14 mars 2017, Microsoft publie une mise à jour qui corrige cette erreur. Le 14 avril, un outil qui exploite cette erreur, attribué à une agence de renseignement américaine et dérobé, est publié sur Internet. Le 12 mai, le programme WannaCry s’en sert. Il fonctionne seul : il cherche les ordinateurs dont la porte 445 répond, entre dans ceux qui n’ont pas installé la mise à jour, bloque leurs fichiers en les rendant illisibles, réclame de l’argent, puis cherche de nouvelles cibles depuis chaque machine touchée. Des usines, des gares et des opérateurs téléphoniques s’arrêtent. Un chercheur découvre que le programme s’arrête si une certaine adresse Internet répond ; il l’enregistre à son nom, et la propagation ralentit. Les machines touchées n’étaient pas surtout les plus vieilles : c’étaient surtout des ordinateurs récents dont la mise à jour attendait. Pour éviter cela, il faut connaître chaque ordinateur, installer d’abord les mises à jour contre les failles déjà utilisées par des attaquants, supprimer l’ancienne version du service, fermer la porte 445 entre ordinateurs de bureau, et garder des copies des fichiers débranchées du réseau.

Pages voisines

WannaCry et MS17-010 : fenêtre d'exposition et correctifs

Elle cite