Ransomware : comment la menace pèse sur les environnements virtualisés

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.