WannaCry, vu d’un serveur SMB

Le 12 mai 2017, un ver informatique nommé WanaCrypt0r 2.0, ou WannaCry, infectait en masse des ordinateurs du monde entier. Nous vous proposons de revenir sur les dessous de l’affaire avec notre dossier sur ce malware inquiétant.

(Re)lire la partie 3 : WannaCry, chronologie des évènements

(Re)lire la partie 4 : WannaCry, à qui profite le crime ?

Avertissement

Pour ce premier article de la série sur le malware WannaCry, nous faisons l’analyse de logs de l’un de nos serveurs Samba (SMB), qui a vu augmenter le nombre d’IP le scannant suite à l’attaque.

Dans le cadre de l’une de nos recherches portant sur un sujet totalement étranger à WannaCry, nous avions déployé un serveur Samba de test. Samba est un logiciel de partage de fichiers pour serveurs Unix et Linux, qui implémente le protocole SMB/CIFS de Microsoft. Il n’est donc pas concerné par la faille de sécurité EternalBlue, qui ne cible que les systèmes d’exploitation Windows. Nous avons pourtant eu la surprise de découvrir une augmentation conséquente des tentatives de connexion en direction de notre serveur lorsque, le 13 mai au matin, nous avons consulté les logs du serveur pour une vérification de routine. Nous avons donc décidé de partager le résultat de l’analyse des logs sur la période qui précède et qui suit le pic de connexions.

Rappelons rapidement le principe de fonctionnement de ce malware. WannaCry est un “cryptoworm”, un ver informatique rançongiciel. Il infecte ses victimes grâce à une faille dans le protocole de partage de fichier de Microsoft, SMB/CIFS. Une fois installé dans la machine, il lance le chiffrement des documents, et en parallèle, génère une liste aléatoire d’adresses IP qu’il va ensuite scanner, envoyant à l’hôte distant des paquets SMB malveillants contenant le code lui permettant de s’auto-répliquer. Notre serveur Samba, s’il n’est pas vulnérable à la faille EternalBlue, a tout de même été scanné par le ver qui recherche des serveurs ouverts sur le port 445 (port réservé au protocole SMB) ; il n’a toutefois pas été compromis. Par ailleurs, nous avions désactivé le droit d’écriture du serveur de test pour laisser simplement celui de lecture. Notre travail se concentre donc sur les tentatives de connexions ayant visées notre serveur, et non pas sur les agissements du ver.

Pour des raisons de confidentialité et de protection des résultats de la recherche qui n’est pas encore publiée, nous ne donnerons pas de valeur absolue. Les valeurs indiquées sont donc relatives, et le calcul a été réalisé suivant un coefficient proportionnel aux nombres de connexions totales reçues. La courbe a été lissée suivant ce coefficient et les valeurs qui y apparaissent reflètent une proportionnalité des connexions, non leur nombre exact.

Un pic de connexions significatif

Nous avons été particulièrement intéressés de voir le pic de connexions provenant d’adresses IP uniques que notre serveur a reçu lors de l’attaque. Celles-ci ont été jusqu’à 50 fois plus importantes que le nombre de connexions moyen journalier avant l’attaque.

Comme on peut le voir sur la courbe ci-dessous, le nombre de connexions antérieures à l’attaque est en dents de scie, mais correspond globalement à une tendance stable sans augmentation ni diminution. La dépression aux alentours du 07 mai est dûe à la fermeture temporaire du serveur pour les besoins de notre recherche et n’est donc pas significative, le serveur ayant été ouvert de nouveau le 10 mai.

L’attaque WannaCry débute le 12 mai, et se déroule ainsi :

  • Le premier jour de l’attaque, notre serveur affiche son premier pic de connexions, avec 13 fois plus d’adresses IP uniques tentant de se connecter qu’avant l’attaque.
  • Le 13 mai, le nombre de connexions uniques est 50 fois plus important que le nombre moyen avant l’attaque.
  • Le 14 mai, le nombre de connexions chute brutalement, et retrouve provisoirement son niveau d’avant l’attaque.
  • Le 16 mai, le nombre de connexions recommence sa progression, à un niveau deux fois plus important qu’avant l’attaque.
  • Les jours suivants, le niveau de connexions uniques semble avoir retrouvé sa tendance d’avant l’attaque : un étalonnage des connexions en dents de scies, mais globalement stable, à un niveau toutefois 2 à 5 fois plus important qu’auparavant. Ainsi, le 29 et le 30 mai se caractérisent par un pic de connexions uniques 5 fois plus important que le nombre moyen d’avant WannaCry. Les niveaux les plus bas, outre “l’après-pic” du 14 mai qui caractérise le retour à la normal, représentent toujours un nombre 2 fois plus important de connexions qu’avant le 12 mai.

wannacry-smb-server-connexion

Graphique représentant un coefficient proportionnel au nombre de connexions par jour. On y voit clairement le pic du 12 mai, ainsi que l’augmentation importante du nombre moyen de connexions après l’attaque.

En se concentrant précisément sur les journées du 12 et du 13 mai, nous avons découvert que l’augmentation des premières connexions commençait vers 14h UTC le 12 mai, pour se poursuivre en régulière progression jusqu’au 13 mai à 11h UTC, apogée du pic. Ensuite, le nombre de connexions va en diminuant, pour s’arrêter définitivement vers 21h, en revenant au taux de connexions d’avant l’attaque.

Il est intéressant de mettre ce fait en parallèle avec le killswitch découvert par le chercheur MalwareTech.1 Ce killswitch est un nom de domaine que le ver arrivant dans un nouvel environnement requête avant de lancer son processus d’installation. Si le nom de domaine n’est pas accessible, alors le ver télécharge sa charge utile. S’il est accessible, le ver arrête là son activité. Il a été supposé que ce killswitch soit une sécurité qui ait pour but d’empêcher l’étude du malware. En effet, ce nom de domaine semble composé d’une chaîne de caractères totalement aléatoire, ce qui diminue la probabilité qu’il soit enregistré (donc accessible). Or si le ver se retrouve piégé dans un environnement d’étude installé par un chercheur en cybersécurité (une sandbox par exemple), l’environnement répondra positivement à chaque requête du ver, quand bien même le nom de domaine n’est pas accessible. S’assurer que le nom de domaine ne soit pas accessible peut être un bon moyen de vérifier que le ver se trouve bien dans une machine vulnérable et non dans une machine de test.

Le nom de domaine a été enregistré par le chercheur approximativement vers 14h UTC, soit l’heure à laquelle les premières connexions vers notre serveur se sont établies. Le pic de connexions a prit fin le 13 à 11h. Il aura donc fallu 24h environ pour que le killswitch fasse effet. On sait, grâce à l’analyse du chercheur, que peu de temps après avoir enregistré le nom de domaine, aucune infection par l’échantillon initial de WannaCry n’était possible. Le fait que le pic de connexion sur notre serveur ait eu lieu a posteriori de l’enregistrement du nom de domaine pourrait révéler une certaine inertie dans le processus de propagation du ver.

Les jours suivants, les connexions ont de nouveau légèrement augmenté pour se poursuivre ensuite à un rythme rampant, bien moins soutenu que lors des débuts de l’attaque, mais plus important qu’avant le 12 mai. Cela pourrait être le signe que l’attaque d’un WannaCry libéré de tout killswitch se poursuit, de manière plus discrète toutefois. Ces connexions pourraient aussi venir de serveurs compromis par d’autres malwares utilisant les mêmes failles Windows que WannaCry, comme par exemple EternalRocks ou Adylkuzz. Une troisième hypothèse serait que la médiatisation des failles du protocole SMB ait attiré sur lui l’intérêt des pirates. Quoiqu’il en soit, cette attention accrue pour les serveurs SMB est relativement inquiétante, compte tenu de ses nombreuses vulnérabilités, partagées par The Shadow Brokers, et du grand nombre de serveurs de ce type mal-configurés, ouverts tant à la lecture qu’à l’écriture.

Des connexions très localisées

A notre grand étonnement, nous avons constaté que la majorité des connexions semblait venir du Canada et de France. Or, selon MalwareTech (1) très peu de machines ont été infectées au Canada. Etant donné que les adresses pouvaient être couvertes par des proxies, il nous est difficile d’inférer la moindre conclusion de cette constatation.

wannacry-ip-scan-smb

Graphique exposant la provenance des adresses IP ayant scanné le serveur SMB. On voit une forte représentation du Canada, de la France, et dans une moindre mesure, des États-Unis et du Royaume Uni.

Pour autant, nous nous interrogeons sur la modalité d’infection de WannaCry. Selon les chercheurs ayant décortiqué le fonctionnement du ver (2), celui-ci envoie pour se répandre des paquets SMB malveillants aux adresses IP issues d’une liste générée aléatoirement au préalable. Pourtant la prééminence de connexions émanant a priori de France ou de Canada pourrait révéler un schéma particulier dans le processus d’infection du ver. Il se pourrait, par exemple, que les adresses IP soient générées par aire géographique et que les infections se fassent selon une certaine règle de proximité, notre serveur test ayant été déployé en France. Nous ne possédons cependant pas assez d’informations pour en tirer des conclusions significatives.

Ce coup d’oeil aux logs de notre serveur SMB a l’avantage de présenter l’impact de WannaCry de l’intérieur. Pour autant, on ne peut généraliser les résultats présentés ici aux serveurs SMB. Pour notre prochain article, nous avons donc repris les principaux éléments de l’attaque, que nous avons ordonnés dans l’ordre chronologique, pour une approche plus globale du sujet.

(1) https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html

(2) https://nakedsecurity.sophos.com/2017/05/17/wannacry-the-ransomware-worm-that-didnt-arrive-on-a-phishing-hook/

Suggestions