Ransomware : comment la menace pèse sur les environnements virtualisés
Certains attaquants s’en prennent sans hésitation aux machines virtuelles, y compris en passant par la console d’administration, voire en chiffrant directement les nœuds de production.
C’était à l’automne 2020. Sur Reddit, un administrateur système exprime son étonnement : « l’environnement d’un client est entièrement tombé et toutes les machines virtuelles ont été éteintes ». Et cela pour un total de 200 VM, dont tous les fichiers s’y rapportant, jusqu’aux images disques, ont été chiffrés.
Initialement, cet administrateur système avançait une hypothèse : « il y avait un serveur Windows 2012R2 qui semble avoir été le point de départ [de toute l’attaque]. Puisqu’il avait accès à l’interface d’administrateur d’ESXi, tout a pu commencer par là ». Mais il se trompait.
La menace de RansomExx
Courant janvier, l’administrateur en question a fourni un compte-rendu plus détaillé de cet incident survenu au Brésil. Après l’intrusion initiale, les assaillants ont réussi à élever leurs privilèges jusqu’à accéder à des systèmes ayant accès au sous-réseau d’administration ESXi – ils avaient déjà mis la main sur le contrôleur de domaine. Les attaquants n’ont pas cherché à s’attaquer au serveur vCenter : ils ont exécuté du code arbitraire sur les hôtes ESXi en exploitant les vulnérabilités CVE-2019-5544 et CVE-2020-3992.
Joint par la rédaction, l’administrateur système souligne la portée de ces vulnérabilités : les attaquants « n’ont pas eu besoin d’aller chercher dans vCenter. Ils n’ont même pas eu à chercher de mots de passe ». C’est donc sans difficulté qu’a pu être « installé et exécuté le code du ransomware ». Ce dernier n’était rien d’autre qu’un script Python. Son exécution sur les hôtes ESXi a conduit « au chiffrement de certaines machines virtuelles ».
En fait, l’administrateur système fait là référence à l’attaque de RansomExx de début novembre 2020 qui a notamment eu des effets de bord sur la Cour Supérieure de Justice brésilienne. À la même période, Kaspersky alertait justement sur la menace que représentait ce rançongiciel pour les systèmes Linux.
Babuk, Conti et Darkside également
Le cas n’est pas isolé et la menace pourrait bien être appelée à s’étendre. Le 21 janvier, les opérateurs de Babuk (qui l’appellent alternativement Babyk, trahissant leur origine russophone, même si cela ne fait guère de surprise) ont indiqué disposer d’un module systèmes Unix/Linux destiné précisément aux hôtes ESXi et systèmes de stockage réseau (NAS).
Le ransomware Darkside s’attaque également à ces systèmes. Mais à l’automne dernier, pour l’une des victimes de ce rançongiciel, tout ne s’est pas déroulé comme prévu. La victime a bien payé la rançon et reçu les outils de déchiffrement. Las, « le déchiffreur n’a pas déchiffré certains fichiers sur l’hôte ESXi », s’est-elle plainte. Un total de 42 fichiers VMDK ont été affectés. Le problème ? Des fichiers trop petits.
Le code de chiffrement pourrait avoir été en cause, produisant des fichiers corrompus indéchiffrables. Mais les assaillants se sont refusés à envisager cette hypothèse. Pour eux, « lorsque vous avez essayé de démarrer les machines virtuelles, l’hyperviseur pourrait avoir endommagé les fichiers chiffrés ».
Les opérateurs de Conti ne chiffrent pas, pour le moment du moins, les systèmes Linux/Unis. Mais cela ne veut pas dire qu’ils ne s’intéressent pas aux environnements virtualisés. Le cas d’une récente victime de ce dernier l’illustre clairement : les attaquants lui ont indiqué avoir mis la main sur le serveur vCenter. De quoi tenir en joug tout un environnement virtualisé VMware.