WannaCry : séchez vos larmes… mais restez prudents !

Temps de lecture estimé : 28 minute(s)

*Attention, ce contenu a été publié il y a 2 années. Il n'est peut-être plus d'actualité.*

La pandémie WannaCry a essentiellement touché des postes de travail dans les entreprises. Mais le ransomware n’a pas épargné les serveurs fonctionnant sous d’anciennes versions de Windows non mises à jour. Face à un tel phénomène, quels sont les moyens d’action d’un hébergeur ? La réponse n’est pas simple, car la responsabilité se situe essentiellement du côté des utilisateurs, lesquels sont les seuls à pouvoir maintenir leurs systèmes à jour. Néanmoins, OVH a tout fait pour freiner l’apparition de WannaCry sur les serveurs vulnérables de ses clients, puis pour contenir cette épidémie particulièrement virulente. L’occasion de rappeler à tous quelques mesures d’hygiène informatique bien utiles pour lutter contre ce type de menace, qui ne risque pas de disparaître.

—Article rédigé avec Hugo Bonnaffé

Nos estimations

Ces derniers jours, il fallait probablement habiter une grotte (ou avoir l’esprit trop occupé par l’actualité politique) pour ne pas entendre parler de WannaCrypt0r. Ce rançongiciel, qui exploite une vulnérabilité dans le partage de fichier des systèmes Windows, s’est propagé comme une traînée de poudre à travers le monde. Les médias se sont emparés du sujet, relayant abondamment les déboires d’entreprises telles que FedEx aux États-Unis, Renault en France ou encore les mésaventures d’hôpitaux publics anglais, contraints de reporter des opérations faute de pouvoir accéder aux dossiers des patients. Comment cette vague de ransomware a-t-elle été repérée et traitée chez OVH ? On vous raconte pourquoi l’équipe sécurité a raté l’investiture du nouveau Président de la République à la télévision et n’a pas beaucoup dormi la semaine dernière.

WannaCry (c’est ainsi que les anglophones ont renommé ce ransomware, sans doute en référence à la réaction des victimes) aurait infecté entre 150 000 et 300 000  machines dans le monde. Ce chiffre est malheureusement en augmentation, car l’épidémie n’est pas tout à fait terminée. Nous avons même, nous y reviendrons, de sérieuses raisons de craindre une recrudescence des infections, du fait de l’apparition de variantes de WannaCry ces derniers jours. Le phénomène demeure toutefois relativement marginal chez OVH, puisque seules 5 000 adresses IP, sur plus de deux millions gérées par nos soins, seraient concernées. Il s’agit là de nos dernières estimations, basées sur notre réseau de honeypots, des machines appartenant à OVH, gérées par l’équipe SOC et volontairement exposées sur le réseau dans le but d’attirer les menaces de tout type (malware, hackers, phishing…) qui pullulent sur le web, permettant ainsi de se faire une idée de leur dangerosité et de leur vitesse de propagation. Si le nombre de machines infectées à l’intérieur du réseau OVH semble faible en regard de la taille notre parc de serveurs, nous n’en sommes pas moins totalement mobilisés pour empêcher la contamination de nouvelles machines vulnérables (entendons-nous bien : nous évoquons ici des machines fournies par OVH à ses clients, et vulnérables car non mises à jour par ceux qui en ont la responsabilité. Les serveurs du système d’information d’OVH n’ont quant à eux pas été touchés par WannaCry, nous y reviendrons en détail).

WannaCry : la rançon de la gloire

D’abord, rappelons ce qu’est WannaCry. Il s’agit d’un ransomware, traduit par rançongiciel. Ce type de logiciel malveillant (malware) prend en otage les données de ses victimes, souvent en les chiffrant, avant de réclamer une somme d’argent afin d’en recouvrer l’accès. Une rançon payable en bitcoins la plupart du temps pour complexifier la traçabilité des flux financiers. Ce procédé n’est pas nouveau. Il est même en plein essor depuis 2005, car il s’agit d’un business très lucratif. Le FBI a estimé le marché du ransomware à un peu plus 830 millions de dollars en 2016. Pour vous donner une idée, c’était la taille du marché anglais de la SVOD (vidéo à la demande avec abonnement) en 2015… ou l’équivalent des pertes d’Uber au 3e trimestre 2016 – choisissez la comparaison qui vous parle, on n’a pas trouvé mieux.

Capture d’écran de la fenêtre qui apparaît sur l’écran des victimes lorsque la machine est contaminée par WannaCry.
Capture d’écran de la fenêtre qui apparaît sur l’écran des victimes lorsque la machine est contaminée par WannaCry.

Généralement, les ransomwares sont propagés par des e-mails malicieux, comportant en pièce jointe une fausse facture par exemple, souvent sous forme de fichier Word ou de .pdf. Une fois ouverte, la pièce jointe exécute un code malveillant (JavaScript, macro,VBScript…) qui récupère sur un serveur la charge active, laquelle se chargera de chiffrer les données de la victime.

Dans le cas de la récente épidémie de WannaCrypt0r, il est important de noter qu’il s’agissait de la version 2.0 de ce ransomware. Les concepteurs du logiciel ne publient évidemment pas de release note, mais pour faire court : la version initiale du malware, dont la propagation était assurée par des e-mails malicieux, n’a pas eu le succès escompté par ses créateurs. Plus efficace, la version 2.0 s’appuie sur l’exploitation d’une vulnérabilité dans le partage de fichiers Windows (SMB). Cette faille, corrigée par Microsoft le 14 mars 2017 dans le bulletin MS17-010 permet d’exécuter du code arbitrairement sur une machine distante exposant au public le service de partage de fichiers Windows. C’est par ce biais que les machines non mises à jour, tournant majoritairement sous Windows Server 2008 et les versions antérieures du système d’exploitation de Microsoft, ont pu être infectées. Notons que ce n’est qu’à partir de Windows Server 2012 et Windows 10 que le pare-feu est configuré afin de ne pas exposer ce service à tous par défaut expliquant le nombre plus faible de victimes. Pour comprendre la suite de l’histoire, notez que le service de partage de fichier s’expose par le port TCP/445.

Dans la famille des malwares, ou logiciels malveillants, nous distinguons plusieurs sous-types. Nous venons d’aborder le ransomware, qui a pour objectif de prendre en otage l’utilisateur en chiffrant ses données. Mais dans le cas de WannaCry, il y a exploitation d’une vulnérabilité pour propager un ransomware. Or, l’exploitation de vulnérabilité, c’est l’apanage des vers informatiques (worm). WannaCry est donc un package hybride, alliant un ver informatique et un ransomware. Et si WannaCry est la rançon de la gloire, il s’agit évidemment de la gloire de Microsoft, dont le système a inondé les postes de travail des entreprises.


Flashback : Inglorius Blaster

Vous souvenez-vous du ver informatique Blaster ? Plusieurs centaines de milliers d’ordinateurs sous Windows 2000 et Windows XP avaient été infectés en août 2003 par ce ver informatique exploitant une vulnérabilité non patchée par Microsoft après plusieurs semaines, forçant l’ordinateur à redémarrer au bout de 60 secondes. Blaster se mettait alors à scanner l’Internet à la recherche d’autres ordinateurs à contaminer, sa propagation s’appuyant, comme dans le cas de WannaCry, sur un vecteur d’infection en Peer to peer (P2P)


Quand nos pots de miel se sont mis à bourdonner

Vendredi 12 mai, quelques tweets de la part de @MalwareHunterTeam circulaient déjà concernant une nouvelle menace du nom de WannaCry qui se diffusait très largement. Dans la soirée, des articles ont commencé à paraître, faisant mention de l’exploitation de la faille précédemment corrigée par Microsoft. Puis, aux environs de 21 h, l’équipe de notre support technique au Canada s’est étonnée de recevoir un nombre anormal de tickets pour cause de ransomware.

Si nous luttons, à notre échelle de cloud provider, contre la prolifération des ransomwares et malwares, il s’agit d’un combat de longue haleine, discrètement mené par l’équipe SOC d’OVH (Security Operations Center), qui nécessite des enquêtes complexes pour remonter jusqu’aux filiales criminelles qui en sont à l’origine et les dénoncer aux autorités en vue de leur démantèlement. Reste qu’il est, au quotidien, impossible d’éradiquer le phénomène grâce à des actions prophylactiques autres que la prévention pour réduire le risque principal que constitue le facteur humain. En pratique, les responsables informatiques le savent bien, il faut veiller à mettre à jour son parc informatique, avec toutes les difficultés que cela représente, lorsqu’il faut prendre en compte l’éventuelle incompatibilité des applications utilisées avec la nouvelle version d’un OS (raison pour laquelle il n’est pas si étonnant (1) de voir encore autant de machines tourner sous des versions de Windows inférieures à 2008). Il faut, en parallèle, sensibiliser sans cesse les collaborateurs sur un second vecteur de contamination que constituent les fichiers attachés aux e-mails qu’ils reçoivent (quitte à mener, comme c’est le cas chez OVH, des campagnes de test à l’aide de faux e-mails piégés pour mesurer la vulnérabilité des employés et former encore et encore les imprudents à une meilleure hygiène informatique). Enfin, face à un ransomware, comme face à la majorité des catastrophes informatiques ayant un impact sur les données, il existe une parade élémentaire, mais diablement efficace : disposer d’une sauvegarde de ses données !

Tout ça pour vous expliquer qu’il est tout de même assez rare de devoir annuler un dîner romantique le vendredi soir en raison d’une campagne de ransomware. Mais celle-ci était un peu spéciale. Nous avions l’information que Wannacry se répandait via EternalBlue, l’exploitation d’une faille en attaquant le port TCP/445. Or, sans doute ne le saviez-vous pas, mais depuis de très nombreuses années, le port TCP/445 utilisé pour le partage de fichiers Windows (CIFS) est filtré au niveau des routeurs de bordure du réseau OVH pour des raisons de sécurité (2). En effet, le port TCP/445 (SMB) s’est déjà révélé être un vecteur de propagation de malwares et OVH a considéré que ce port ne devrait être exposé que dans un réseau privé ; si un utilisateur souhaite communiquer via ce port à distance, il doit envisager de le faire via un VPN (« Réseau Privé Virtuel »). En conséquence, il est impossible de se connecter à une machine hébergée chez OVH sur le port TCP/445, à moins de le faire depuis une IP appartenant à OVH (le filtrage du port n’est pas opérant à l’intérieur du réseau OVH, ceci parce que le partage de fichiers peut être utilisé par des clients pour des raisons légitimes). OVH était donc à l’abri de voir des machines contaminées sur son réseau…

Pourtant, dans la nuit de vendredi à samedi, nos honeypots ont sonné l’alerte en raison de l’augmentation soudaine du nombre de scans provenant d’IP appartenant au réseau d’OVH. Nous avons alors immédiatement ouvert plusieurs chantiers en parallèle : la recherche méthodique du patient zéro, celui par qui WannaCry était parvenu à pénétrer à l’intérieur du réseau OVH pour y propager l’infection ; le reverse-engineering du ransomware pour en comprendre le fonctionnement ; la mise en place de mesures pour empêcher la contagion vers d’autres machines vulnérables et bien sûr la vérification scrupuleuse des machines de notre système interne.

Comment fonctionne WannaCry et pourquoi a-t-il touché davantage les entreprises que les particuliers ?

En procédant au reverse-engineering de WannaCry, notre priorité était d’identifier comment le ver se propage et quelle est sa stratégie pour parcourir Internet à la recherche de machines vulnérables à contaminer. Nous avons observé que deux méthodes de scan sont initialisées par WannaCry, puis lancées de façon concurrente (multithreading). La première méthode consiste à scanner le réseau local afin d’infecter les machines qui y sont connectées. Afin de ne pas affoler les outils de détection d’intrusion (IDS), le code n’excède pas la limite de dix tentatives d’intrusion simultanées. Une précaution qui semble indiquer que les réseaux internes des entreprises étaient particulièrement ciblés.

La seconde méthode permet de scanner l’Internet en créant une IP v4 valide, ceci de façon aléatoire en générant un à un les quatre octets composant l’adresse et en éliminant les IP commençant par 127 ou par un octet >= 224. Fait intéressant, quand une IP est détectée vulnérable, il semble que le ver tente de scanner l’intégralité de la /24 (ce qui correspond aux 254 IPs voisines). D’après nos observations, les machines infectées sont capables de scanner environ 30 IP/seconde.

Monitoring d’un VPS infecté par WannaCry le 15 mai 2017 : le chiffrement sollicite beaucoup le processeur et consomme de la mémoire, puis le scan de l’Internet maintient une légère activité CPU.
Monitoring d’un VPS infecté par WannaCry le 15 mai 2017 : le chiffrement sollicite beaucoup le processeur et consomme de la mémoire, puis le scan de l’Internet maintient une légère activité CPU.

Autre fait intéressant : le délai d’expiration de la tentative de compromission. En effet, une technique utilisée par les experts en sécurité pour ralentir la propagation de ce type de malware est de monopoliser volontairement la connexion pour empêcher l’un des threads de scanner (il passe son temps à attendre la réponse du serveur). Statistiquement, il est ainsi possible de mettre tous les threads à l’arrêt et de stopper les scans. Cette technique s’appelle le « tarpit« . Ici, il semble que le concepteur du ver ait pris la peine de mettre un délai d’expiration d’une heure afin de relâcher la connexion si le serveur ne répond pas. Enfin, autre élément révélé par l’autopsie du code : une machine compromise se voit également infectée par DoublePulsar, une backdoor (porte dérobée) utilisée possiblement par l’Equation Group pour injecter des malwares sur la machine cible. Cette backdoor semble être elle-même réutilisée pour réinfecter une machine ultérieurement d’après le code de WannaCry.

Que faut-il retenir du fonctionnement de WannaCry ? D’abord, que son code fait des entreprises des vecteurs de transmission privilégiés. Certains choix dans les algorithmes nous font pencher en ce sens. En effet, les parcs de machines des entreprises sont en général relativement homogènes ; aussi il y a de bonnes chances de trouver très rapidement sur un réseau local des machines vulnérables, alors que le scan de tout l’Internet est statistiquement moins efficace. Ceci dit, si l’infection de serveurs est moins massive que celles des postes de travail en entreprise, elle est également critique du point de vue de la propagation du ransomware. Car un serveur possède des ressources et une bande passante plus importantes, décuplant sa capacité à rechercher sur Internet des machines vulnérables.

Charité bien ordonnée…

Quand le singe veut monter au cocotier, il faut qu’il ait les fesses propres. Autrement dit, avant de vouloir sauver le monde face à WannaCry, il était indispensable de vérifier les machines de notre système interne, pour s’assurer qu’aucune d’entre elles n’avait été compromise.

Nous avons naturellement une politique interne de mise à jour des machines très stricte, qui consiste à appliquer sur chacune de nos machines les patches et mises à jour immédiatement après leur publication. Toutefois, personne n’est jamais à l’abri d’une faille : la sécurité informatique requiert une certaine hygiène, mais aussi une bonne dose de modestie. Ne jamais se croire invulnérable. Ce n’est pas tant l’infection d’une machine en production de notre système interne qui nous inquiétait (peu sont sous Windows, et elles sont surveillées de très près). La crainte était plutôt de découvrir une VM utilisée pour un test qui n’aurait pas été correctement détruite. Le problème n’est alors pas le chiffrement de données par le ransomware, puisque ces serveurs sont généralement dépourvus de contenus intéressants, mais à la fois la backdoor DoublePulsar qui permettrait une intrusion sur nos systèmes, ainsi que la capacité du serveur à infecter d’autres machines vulnérables en scannant les ports TCP/445 ouverts à l’intérieur du réseau OVH. Et même si la presse relate beaucoup les exploits de WannaCry, n’oublions pas que ce n’est pas le seul malware à exploiter ces vulnérabilités.

Portrait type des machines infectées et vulnérables

N’ayant rien trouvé à signaler sur les machines internes, nous nous sommes appuyés sur les données recueillies par notre réseau de honeypots pour dresser le portrait type des serveurs, susceptibles d’être infectés par WannaCry. Nous avons ainsi décelé plusieurs typologies de serveurs équipés de systèmes d’exploitation Windows vulnérables : des VPS, commercialisés en direct ou via des revendeurs, des serveurs dédiés ainsi que les VM Private Cloud tournant sous des versions de Windows 2008 ou antérieures.

OS Version%OS Category%
Hyper-V Server 7601 Service Pack 11,2%Hyper-V Server1,2%
Windows 7 Enterprise 7601 Service Pack 10,3%Windows 73,5%
Windows 7 Home Premium 76000,5%
Windows 7 Professional 7601 Service Pack 10,7%
Windows 7 Ultimate 7601 Service Pack 11,9%
Windows 8.1 Pro 96000,3%Windows 80,3%
Windows Server 2003 3790 Service Pack 10,3%Windows Server 20030,3%
Windows Server 2008 R2 Datacenter 76000,5%Windows Server 200894,1%
Windows Server 2008 R2 Datacenter 7601 Service Pack 14,3%
Windows Server 2008 R2 Enterprise 760015,7%
Windows Server 2008 R2 Enterprise 7600 Service Pack 10,3%
Windows Server 2008 R2 Enterprise 7601 Service Pack 118,8%
Windows Server 2008 R2 Standard 76006,8%
Windows Server 2008 R2 Standard 7601 Service Pack 145,9%
Windows Web Server 2008 R2 76000,3%
Windows Web Server 2008 R2 7601 Service Pack 11,4%
Windows Server 2012 R2 Standard 96000,5%Windows Server 20120,5%

Répartition des OS scannant l’Internet tombés dans notre réseau de honeypots (lorsque les machines infectées contactent le honeypot, elles annoncent quelle est la version de leur OS dans les premiers échanges). On observe majoritairement des Windows Server 2008.

Cela nous a conduits à passer en revue les images fournies par OVH pour la préinstallation/réinstallation de systèmes d’exploitation. Nous nous sommes alors rendu compte que certaines images mises à disposition n’incluaient pas le patch de sécurité de Microsoft corrigeant la faille exploitée par EternalBlue. Certes, les images Windows fournies par OVH sont fournies configurées pour réaliser chaque jour les mises à jour automatiques fournies par Microsoft, mais dans le cas de Windows Server 2008, le port étant exposé au public au démarrage de l’OS, le serveur peut être infecté avant même d’avoir le temps de se mettre à jour. Il nous fallait donc endiguer ce risque, en corrigeant sans attendre les images Windows proposées. L’occasion de constater, étant donné les débits très faibles sur la plateforme Microsoft Update, que nous n’étions pas seuls à être en quête du fameux patch…

La mise à jour des templates Windows a été longue le samedi 13 mai.. Très longue puisque le débit sur la plateforme Microsoft Update était inférieur à 100 octets/seconde.
La mise à jour des templates Windows a été longue le samedi 13 mai.. Très longue puisque le débit sur la plateforme Microsoft Update était inférieur à 100 octets/seconde.

Les tâches travaux relatant la mise à jour des images Windows ont été publiées en temps réel (3), et la création d’un robot a été décidée, de sorte à automatiser la mise à jour et l’intégration des patchs de sécurité liés aux templates Windows à l’avenir. Par ailleurs, nous avons relevé l’ensemble des adresses IP des machines qui avaient tenté de compromettre nos honeypots, et avons suspendu les serveurs en question immédiatement après en avoir averti les clients concernés – une démarche qui se poursuit actuellement. Nous avons songé à couper temporairement les échanges réalisés sur le port TCP/445 sur l’ensemble du réseau OVH, mais cette mesure était trop radicale et risquait d’impacter des clients qui utilisent le partage de fichiers Windows et avaient bien appliqué le patch de sécurité proposé par Microsoft il y a deux mois. Nous avons donc pris la décision de couper le service des utilisateurs dont le serveur avait été compromis, en leur adressant un message informatif (blocage de l’IP ou serveur placé en mode rescue). Le message en question :

« Votre serveur a participé à une cyberattaque de diffusion de rancongiciel, nous avons dû le redémarrer en mode rescue pour stopper l’attaque. Si vous utilisez une IP fail-over, cette IP a été bloquée. »

La « bonne nouvelle », c’est qu’aucun des serveurs infectés n’a pu contaminer le reste d’Internet, à l’extérieur du réseau OVH, étant donné que le filtrage appliqué par OVH sur le port TCP/445 empêchait le ver de recevoir la réponse de sa victime potentielle (le SYN-ACK ne peut pas être reçu, car il est droppé en bordure, la connexion TCP ne peut donc pas s’établir).

Principe de fonctionnement du filtrage sur le routeur de bordure dans le cas d’une tentative d’infection depuis une machine située sur le réseau OVH.
Principe de fonctionnement du filtrage sur le routeur de bordure dans le cas d’une tentative d’infection depuis une machine située sur le réseau OVH.

À la recherche du patient zéro

Comment des scans du port TCP/445 de machines hébergées chez OVH ont bien pu débuter à l’intérieur de notre réseau alors que nous bloquons le port en entrée de notre backbone ? C’est la question que nous nous sommes rapidement posée. Bien entendu, notre premier réflexe a été de vérifier les règles sur les routeurs. En vain : le filtrage était opérationnel. Nous avons alors remonté le temps, en scrutant les événements consignés dans les NetFlows de notre système de protection anti-DDoS (VAC) afin d’identifier l’IP qui a inoculé WannaCry sur notre réseau. Nous avons dû remonter plusieurs jours en arrière pour trouver le coupable. Ou plutôt les coupables, car il s’agit de plusieurs PC infectés connectés à Internet via des accès xDSL fournis par OVH. Nous avons observé que, indépendamment, plusieurs IP derrière lesquelles se trouvent des accès xDSL, ont commencé à scanner Internet pendant plusieurs heures à la recherche de machines vulnérables dans la matinée du vendredi 12 mai. Progressivement, comme le graphique suivant le montre, ces IP ont commencé à infecter des VPS, puis des serveurs dédiés. Vous comprendrez aisément qu’une connexion xDSL n’a pas la même force de frappe qu’un serveur dédié, en termes de bande passante notamment. Ainsi, dès la première infection d’un serveur dédié, nous avons vu une véritable explosion des scans lancés par des machines infectées : la réaction en chaîne était amorcée.

Graphique présentant le nombre d’IP utilisant le port TCP/445 (en bleu) et le nombre de paquets cumulés observés (en gris). On observe un léger sursaut un peu avant 12 h le 12 mai, correspondant aux accès xDSL infectés, avant que des serveurs ne soient infectés entre 15 et 17h et provoquent une véritable réaction en chaîne. À 20 h, c’est un service de VPN qui a fait exploser le nombre d’IP scannant le réseau avant d’être partiellement bloqué. Puis, de nouveau, le lendemain vers 15 h, un service de VPN a acheminé un très grand nombre de scans sur notre réseau tandis que nous appliquions nos contre-mesures dès 12 h. La situation était sous contrôle dès 20 h le samedi 13 mai, avec une situation revenue à la normale le 14 mai à 5 h du matin.
Graphique présentant le nombre d’IP utilisant le port TCP/445 (en bleu) et le nombre de paquets cumulés observés (en gris). On observe un léger sursaut un peu avant 12 h le 12 mai, correspondant aux accès xDSL infectés, avant que des serveurs ne soient infectés entre 15 et 17h et provoquent une véritable réaction en chaîne. À 20 h, c’est un service de VPN qui a fait exploser le nombre d’IP scannant le réseau avant d’être partiellement bloqué. Puis, de nouveau, le lendemain vers 15 h, un service de VPN a acheminé un très grand nombre de scans sur notre réseau tandis que nous appliquions nos contre-mesures dès 12 h. La situation était sous contrôle dès 20 h le samedi 13 mai, avec une situation revenue à la normale le 14 mai à 5 h du matin.

Phénomène prévisible, les VPN sont ensuite entrés en jeu. En créant un tunnel sécurisé entre l’extérieur et une machine OVH, le VPN permet logiquement de by-passer les règles en entrée de réseau (et donc la fameuse interdiction du port TCP/445). Les serveurs hébergeant des services VPN ont commencé à émettre un trafic très dense, les IP étant généralement mutualisées dans la mise en place d’un tel service. Notre service de détection automatique de scan de ports a été souvent déclenché, sortant les machines concernées du réseau (redémarrage en mode rescue).

Ainsi, même si les règles de filtrage à l’entrée de notre réseau n’ont pas eu 100 % d’efficacité face à cette épidémie particulièrement virulente, ces règles ont permis de ralentir la propagation, nous laissant davantage de temps pour déployer les mesures qui ont permis de contenir le phénomène dès le milieu d’après-midi du samedi 13 mai.


Killswitch : la ruse ultime des malwares pour passer sous les radars des équipes de sécurité

Vous avez sans doute lu l’histoire de cet expert en sécurité, racontant avoir stoppé la propagation de WannaCry en acquérant un domaine qui permettait de neutraliser le ransomware. Beaucoup se sont interrogés sur ce mécanisme d’urgence, autrement appelé « killswitch », contenu à l’intérieur même du code du ransomware, et qui permettrait d’en neutraliser la propagation. Il faut savoir que ce « bouton d’urgence » est présent au sein de nombreux malwares. Contrairement aux apparences, ce « killswicth » ne sert pas à neutraliser le ransomware ; il s’agit plutôt d’un mécanisme de défense destiné à compliquer son analyse par les équipes de sécurité. Une fois le ransomware capturé (on parle alors de sample), les experts exécutent le fichier au sein d’une sandbox (un environnement sécurisé, isolé du réseau), pour s’adonner au reverse-engineering du code, et en comprendre le fonctionnement. C’est là que le killswitch intervient : en effectuant un appel réseau, qui consiste par exemple à vérifier l’inexistence d’un domaine (en général généré aléatoirement), le ransomware va pouvoir détecter s’il est exécuté à l’intérieur d’une sandbox (qui simulera une réponse positive à cet appel, étant isolée du réseau et devant se préparer à d’autres appels réseau qui, eux, seront cruciaux dans l’analyse du sample). S’il se sait exécuté dans une sandbox et donc scruté par un ensemble d’outils de profilage, le ransomware ne s’activera alors pas… empêchant nos outils de cartographier son fonctionnement. D’ailleurs, si vous installez les VMware Tools (généralement présents sur les machines virtuelles) sur vos postes de travail, il y a des chances pour que certains malwares vous laissent tranquille, car c’est un marqueur fréquemment détecté par bon nombre d’entre eux.

Dans le cas de WannaCry et du mécanisme utilisé en guise de killswitch, le domaine n’était pas généré aléatoirement, expliquant pourquoi dès le dépôt du domaine, sa propagation a été freinée. Mais il est à noter que celle-ci pourrait très bien reprendre si d’aventure le domaine était relâché dans la nature. Ou, comme cela est en train de se produire, si des variantes de WannaCry apparaissent, avec un code similaire, mais un mécanisme de Killswitch un peu différent.


Vous avez été contaminé ? Ne payez pas !

Payer revient à alimenter des réseaux criminels, et donc donner les moyens à ces groupes de développer des malwares toujours plus perfides. Même s’il en va de la « réputation » des auteurs de rendre les données après paiement (ce dont ils se vantent dans le message de relance qu’ils ont récemment envoyé à leurs victimes, pas assez nombreuses à avoir payé à leur goût), sachez qu’il y a des personnes beaucoup moins scrupuleuses, qui n’hésitent pas à surfer sur la vague afin de se faire facilement de l’argent…  Ainsi, certains ont contrefait l’interface graphique de WannaCryt0r, propageant un ransomware qui vous incite à payer alors que vos fichiers ne sont même pas chiffrés. Prudence donc face à ces arnaques !

Dans l’immédiat, réinstaller vos systèmes Windows avec la dernière version disponible et les patchs de sécurité fournis par Microsoft est la meilleure façon d’endiguer WannaCry.
Notez que, si vous êtes chanceux, quelques outils ont vu le jour pour vous permettre de déchiffrer vos données. Nous pouvons notamment citer un projet français parmi eux, WannaKiwi, qui inspecte la mémoire de votre machine pour trouver le précieux sésame. De façon plus large, la société Kaspersky Lab a créé une plateforme référençant différents logiciels permettant de vous sortir de l’embarras lorsque vous êtes victime d’un ransomware.

Vous pouvez également vous rapprocher du commissariat ou de la brigade de gendarmerie la plus proche de chez vous pour déposer plainte et/ou obtenir davantage d’information sur la réponse pénale envisageable. Enfin, on ne le répétera jamais assez : n’oubliez pas de faire des copies de vos données sensibles.

Aussi, lors de cette attaque, nombreux sont ceux qui ont fait état de sites web complètement hors service. Si votre site a pu être dans un état similaire, nous vous recommandons de changer chacun de vos mots de passe, sans exception ! Pourquoi ? Vos fichiers, même s’ils étaient chiffrés, étaient téléchargeables par tout le monde. Ainsi, si votre activité ou vos données le justifient, pourquoi une personne ne s’amuserait pas en tentant de déchiffrer votre « config.php » pour obtenir un accès privilégié à votre base de données ? Ne tardez pas !

La menace n’a pas disparu. Profitez de la médiatisation de cette épidémie pour mettre la sécurité informatique en tête des priorités de votre entreprise !

Connais ton ennemi et connais-toi toi-même ; eussiez-vous cent guerres à soutenir, cent fois vous serez victorieux.  L’art de la guerre, Sun Tzu

Vous l’aurez compris, quand bien même les médias auront bientôt détourné leur attention de WannaCry, la menace n’en demeurera pas moins toujours présente. Le graphique précédent montrait ainsi une recrudescence des tentatives de compromission ces derniers jours, réalisées par des machines compromises. Et pour cause : des variantes de WannaCry sont apparues et continuent à contaminer de nouvelles machines vulnérables. D’ailleurs, WannaCry n’est pas le premier à exploiter la faille présente dans les systèmes Windows. Bien avant lui, « Adylkuzz » exploitait déjà ces vulnérabilités afin de compromettre la machine en vue de miner du Monero, une cryptomonnaie alternative au Bitcoin. De nombreux malwares sont actuellement en circulation en se basant certes sur EternalBlue, mais égalements ses petits cousins: EternalSynergy, EternalChampion & EternalRomance. L’apparition d’un botnet utilisant cette même vulnérabilité pour se propager puis lancer de larges attaques DDoS comme MIRAI en septembre dernier est plus que probable dans les heures à venir.

Exemple d’un VPS infecté par Adylkuzz aux environs de 20 h : le minage consomme beaucoup de CPU et de bande passante, tandis que l’arrêt du service Samba libère de la mémoire.
Exemple d’un VPS infecté par Adylkuzz aux environs de 20 h : le minage consomme beaucoup de CPU et de bande passante, tandis que l’arrêt du service Samba libère de la mémoire.

N’oubliez pas également que lorsque votre machine a été compromise, la backdoor DoublePulsar a été installée sur celle-ci. Ainsi, même si le patch Microsoft MS17-010 est appliqué, votre machine reste vulnérable sur l’Internet. De nombreux outils ont été publiés afin de savoir si votre machine a été compromise, comme celui de l’éditeur du fameux outil d’exploration du réseau « nmap ».

Nous savons ici, chez OVH, qu’il est utopique de croire que la menace va disparaître dans les prochains jours. Cette menace va s’inscrire dans la durée. Il restera des machines vulnérables sur l’Internet à compromettre, comme ça a pu être le cas avec la faille sur le service NTP révélée en 2013 et qui continue, aujourd’hui encore, à être utilisée pour réaliser des attaques par déni de service.

Alors, quand vous aurez patché jusqu’à la dernière machine de votre réseau, dites-vous qu’à toute chose malheur est bon. La couverture médiatique dont a bénéficié WannaCry a ouvert les yeux de tous sur la nécessite d’investir davantage dans la sécurité informatique, car c’est un enjeu critique. Le capital d’une entreprise, ce ne sont plus seulement ses actifs immobiliers, ses ressources humaines ou encore sa réputation. Les données, et par extension le système d’information d’une entreprise, sont également des actifs précieux d’une société. Vos collègues, les membres de votre comex ont les yeux braqués sur vous ? Profitez-en, avant qu’ils ne détournent leur attention…jusqu’à la prochaine épidémie.


Notes :

(1) Windows XP : les banques vont payer Microsoft pour avoir des patchs, par Julien Lausson sur numerama.com le 25 mars 2014.

(2) Le blocage du port TCP/445 en bordure du réseau OVH pour des raisons de sécurité a été rappelé par Octave Klaba, fondateur et CEO d’OVH, dans un message sur la mailing-list sd-pro@ml.ovh.net le 27 Juin 2016. Il y expliquait que ce blocage était en place depuis 11 ans, et le serait pour toujours. En quelque sorte, la mise à jour que Microsoft a apportée par la suite à son système d’exploitation va dans ce sens, puisqu’elle consiste à ne plus exposer par défaut ce port, dont l’usage a été conçu pour l’échange de fichiers au sein d’un réseau local.

(3) Les tâches travaux publiées :
http://travaux.ovh.net/?do=details&id=24741
http://travaux.ovh.net/?do=details&id=24738
http://travaux.ovh.net/?do=details&id=24740
http://travaux.ovh.net/?do=details&id=24742
http://travaux.ovh.net/?do=details&id=24743

Security Analyst