Worm Wannacry : le déroulement de l’attaque en détail

Joe Levy, le CTO de Sophos, grâce à une analyse minutieuse, dissèque le phénomène Wannacry et donne ses conseils techniques sur ce qu’il faut faire à présent.

Vendredi dernier, l’épidémie déclenchée par le ransomware worm Wannacry, a pris en otage des centaines de milliers d’ordinateurs à travers le monde.

Une attaque par ransomware classique commence par un email d’hameçonnage contenant une pièce jointe ou un lien malveillant, que l’utilisateur est incité à ouvrir. Mais le SophosLabs a découvert que la cyberattaque lancée par le worm WannaCry n’a probablement pas démarré de cette façon.

Hier, le CTO de Sophos Joe Levy a disséqué cette épidémie. Il a montré comment le worm Wannacry s’est propagé en profitant d’un exploit pour Microsoft Windows SMB émanant de la NSA, et qui avait été divulgué le mois dernier par le groupe de hackers Shadow Brokers. Levy a donné un point de vue technique sur le déroulement des faits, comment l’attaque s’est déroulée, la chronologie des événements, comment cette dernière attaque aurait pu être évitée, et ce qu’il faut faire maintenant.

Vous pouvez visionner la présentation complète sur la page du webinaire de Sophos.

Chronologie et méthodes

Levy est entré dans les détails de la chronologie des événements et comment cette épidémie a pu se propager si rapidement.

L’enquête a fait apparaitre une attaque en trois étapes, en commençant par l’exécution de code à distance avec des malwares obtenant des privilèges d’utilisateurs avancés. A partie de là, le payload a été déballé et exécuté. Une fois que les ordinateurs piratés, il a chiffré les documents et affiché un message concernant la rançon.

Comme nous l’avons noté précédemment, l’attaque a exploité une vulnérabilité Windows que Microsoft a patché en mars dernier. Cette faille se trouvait au sein du service Windows Server Message Block (SMB), que les ordinateurs Windows utilisent pour partager des fichiers et des imprimantes au niveau des réseaux locaux. Microsoft a traité ce problème dans son bulletin MS17-010.

Ce worm générait des adresses IP aléatoires. Une fois que les adresses IP avaient été définies, le worm envoyait des paquets SMB malveillants à l’hôte distant, lui permettant de se propager.

Les leçons à tirer :

Cette épidémie a fait comprendre aux entreprises la nécessité de surveiller de près les mises à jour de sécurité et l’importance de les installer immédiatement.

Certains critiqueront les entreprises qui tardent à patcher leurs systèmes ou utilisent encore d’anciennes versions de Windows. Il est assez facile de blâmer les victimes. Mais le fait de patcher tardivement ou d’utiliser des versions obsolètes de Windows ne résultent pas toujours d’une forme de paresse ou d’apathie, comme le souligne Levy dans sa présentation.

Il est fréquent de voir des services de sécurité informatique bloquer certaines mises à jour car ils doivent modifier au préalable leur système pour des raisons de compatibilité. Sans cette précaution, ils risqueraient de déployer un patch mettant en danger d’autres programmes. En parallèle, certaines entreprises ont continué d’utiliser d’anciennes versions de Windows car :

• Ils n’ont pas les ressources financières et humaines nécessaires pour la mise à niveau.
• Leurs systèmes existants ne sont pas encore équipés pour fonctionner avec, par exemple, Windows 10.

Il existe d’autres raisons, mais ces dernières sont les 2 principales.

Les défaillance de mode commun

Mais dans un récent article de Naked Security, Levy a déclaré qu’il existait des cas où un patch ne devrait pas être considéré comme facultatif, et ce quelle que soit la politique de mises en jour de l’entreprise, comme lorsque les vulnérabilités tombent dans la catégorie des “défaillances de mode commun”.

L’expert cybersécurité réputé Dan Geer a analysé le problème dans une colonne qu’il a écrite après la découverte en 2014 de Heartbleed. Entre autres choses, Geer a écrit :

Seules les monocultures favorisent les échecs au niveau d’internet dans sa globalité. Tous les autres échecs ne sont que le résultat de tragédies locales. Pour les législateurs, le seul aspect de la monoculture qui compte, c’est que ces monocultures sont la condition sine qua non de l’exploitation des masses. Dans le langage statistique, il s’agit d’une “défaillance de mode commun”, et elle est due à une dépendance mutuelle sous-estimée.  

Le National Institute of Standards and Technology (NIST) définit la “défaillance de mode commun” de cette façon :

Une défaillance de mode commun est le résultat d’un seul défaut (ou d’un ensemble de défauts). Les systèmes informatiques sont vulnérables vis-à-vis des défaillances de ressources de mode commun, si elles dépendent d’une seule source d’alimentation, de refroidissement ou d’E/S. Une source plus insidieuse de défaillance de mode commun est un défaut de conception qui génère des copies redondantes du même processus qui échouent dans des conditions identiques.  

Comment cela s’applique-t-il à ce qui s’est passé vendredi ? Levy a expliqué :

Lorsqu’un échec (et son patch associé) implique l’intersection de composants communs comme SMB (qui sont présents sur tous les systèmes Windows) et l’exécution de code à distance, c’est une combinaison qui devrait transcender les règles.  

En d’autres termes, dans le cas de ces vulnérabilités SMB de Windows, le patch ne doit pas être considéré comme facultatif, et ce indépendamment de votre politique (ou non-politique) sur les mises à jour. Le danger en bloquant ces correctifs est que les attaques comme WannaCry auront beaucoup plus de facilité à parcourir le globe.

Billet inspiré de WannaCry: how the attack happened, sur Sophos nakedsecurity.