Un « ransomware ESXi » sévit en France : les choses à savoir

« À tous : si vous utilisez ESXi 6.x, mettez à jour immédiatement, un cryptolock est en train de se propager à toute vitesse ! » Ainsi Arnaud de Bermigham, président-fondateur de Scaleway, avait-il tiré la sonnette d'alarme vendredi 3 février en début d'après-midi.

🚨A tous : Si vous utilisez ESXi 6.x, mettez à jour IMMÉDIATEMENT, un cryptolock est en train de se propager à toute vitesse !
If you're using ESXi 6.x, update IMMEDIATELY, a cryptolock is rolling out fast!

- Arnaud de Bermingham (@a_bermingham) February 3, 2023

Quelques heures plus tard, Octave Klaba, son homologue chez OVHcloud, passait à son tour le message. « Mettez à jour vos ESXi », expliquait-il, billet de blog du CISO à l'appui.

Mettez à jour vos ESXihttps://t.co/S0QLfC0KbH

- Octave Klaba (@olesovhcom) February 3, 2023

Presque en parallèle, le CERT-FR publiait une alerte.

??Alerte CERT-FR??
CERTFR-2023-ALE-015 : Campagne d'exploitation d'une vulnérabilité affectant VMware ESXi (03 février 2023). https://t.co/KN6GDUdXcL

- CERT-FR (@CERT_FR) February 3, 2023

L'alerte CERT évoque des attaques destinées à déployer un ransomware ; sans préciser lequel. La faille exploitée semble être la CVE-2021-21974... pour laquelle un correctif est disponible depuis près de deux ans. Dans les grandes lignes, elle peut permettre d'exécuter du code à distance en passant par le port OpenSLP (427). Sont concernées les versions suivantes d'ESXi :

7.x et antérieures à ESXi70U1c-17325551
6.7.x et antérieures à ESXi670-202102401-SG*
6.5.x et antérieures à ESXi650-202102101-SG*

Dans le cas où on ne pourrait appliquer les correctifs, on désactivera, au possible, OpenSLP, selon le mode opératoire que détaille VMware.

ESXiargs plutôt que Nevada

L'analyse d'OVHcloud a un temps mentionné le ransomware Nevada. Ce n'est plus le cas, faute d'éléments probants. On semble plutôt avoir affaire ESXiargs.

Pourquoi ce nom ? Parce qu'à chaque élément qu'il va chiffrer, le malware associe un fichier .args contenant des directives.

Sur les hôtes ESXi compromis, le chiffrement n'intervient qu'après plusieurs étapes. Un script s'exécute d'abord, et réalise plusieurs tâches. Parmi elles :

- Modifier les fichiers de configuration (.vmx) des VM de sorte que les chaînes « .vmdk » et « .vswp » deviennent « 1.vmdk » et « 1.vswp »

- Forcer l'arrêt des VM en tuant les processus contenant la chaîne « .vmx »

- Obtenir une liste des volumes ESXi et y recherche certaines extensions de fichiers

- Pour chaque élément d'intérêt, créer dans le même dossier, un fichier .args contenant des paramètres (taille des blocs, portions à ne pas chiffrer...) dont certains calculés à la volée

Le chiffrement s'appuie sur une clé publique déployée dans /tmp, une clé privée de 32 octets générée via OpenSSL et l'algorithme Sosemanuk. Une association qui n'est pas sans rappeler le ransomware Babuk, dont le code source avait filtré...

Par après, ESXiargs remplace la page d'accueil de l'hyperviseur (index.html) par une note de rançon. Il la copie aussi, au format texte, dans /etc/motd afin qu'elle s'affiche au moment du login.

Il arrive que le chiffrement échoue au moins partiellement. OVHcloud recommande, pour qui est dans ce cas, une méthode de récupération des .vmdk. À utiliser « à vos risques et périls », elle fonctionne « les deux tiers du temps », d'après l'hébergeur.

* On notera plus globalement que les versions 6.5.x et 6.7.x sont arrivées en fin de vie il y a quelques mois. Elles ne bénéficient plus, en standard, de mises à jour de sécurité.

Photo d'illustration © Nmedia - Fotolia