Une tempête de rançongiciels s’abat sur les serveurs VMWare
07 fév. 2023 - 09:14,
Tribune
- Charles Blanc-RolinIl y a dix jours, nous apprenions que le groupe LockBit s’était doté d’un nouvel outil de chiffrement, après LockBit Red et LockBit Black, il propose désormais une version Green [2], qui a peut-être, au-delà de son nom, un petit côté « écolo » dans le sens où il semblerait qu’il s’agisse du code source de l’outil de Conti qui aurait été recyclé [3].
On note également qu’une version dédiée au chiffrement des serveurs ESXi est toujours disponible.
La semaine dernière également, Bleeping Computer présentait le rançongiciel Nevada, qui a fait son apparition il y a deux mois et qui, lui aussi propose une version Windows, ainsi qu’une version ESXi de son outil de chiffrement [4].
Dimanche, on apprenait que le groupe d’anciens affiliés de Conti qui se cachent derrière le rançongiciel Royal Ransomware, se mettait lui aussi au chiffrement des serveurs VMWare [5].
Difficile d’être passé à côté ce week-end, ou à minima en ce début de semaine, la campagne baptisée « ESXiArgs » qui fait tomber comme des mouches pas mal de serveurs ESXi exposés sur internet depuis la fin de semaine dernière. Le CERT-FR de l’ANSSI l’annonçait dès vendredi dans un bulletin d’alerte [6].
Certains ont peut-être découvert une demande de rançon en se connectant en ce lundi matin à l’interface web d’administration de leurs serveurs.
D’autres le découvriront peut-être plus tard…
La bonne nouvelle, c’est qu’il est possible de récupérer les données à partir de la procédure proposée par deux membres de l’équipe technique du groupe turque Yöre [7], le CERT-FR à lui-même confirmé dimanche en mettant à jour l’avis émis vendredi.
Le nombre de machines compromises est assez impressionnant, la société ONYPHE en recensait plus de 2000 dimanche dans l’après-midi [8] et les chiffres continuent d’augmenter, plus de 2000 nouveaux résultats dans la journée du 6 février sur Onyphe (attention les résultats n’indiquent pas un nombre d’adresses IP unique).
Sur Shodan, pour la France, on passe de 214 machines affectées tôt lundi matin à 358 en fin de soirée, et même si la majorité des machines était hébergées chez OVH, suivi de loin par Scaleway, des machines situées chez d’autres hébergeurs commencent à émerger.
En fin de soirée, Shodan semble encore être loin du compte par rapport à ONYPHE, puisqu’il ne recense que 1300 machines infectées.
Alors comment autant de machines ont-elles pu être compromises en aussi peu de temps ?
On peut tout d’abord supposer que l’attaque a été automatisé en exploitant une vulnérabilité dans un service exposé sur internet. Les premières investigations indiquent qu’une vulnérabilité dans OpenSLP aurait été exploitée, soit la CVE-2021-21974, soit la CVE-2020-3992, on pourrait également penser à la CVE-2019-5544. Ces trois vulnérabilités permettent une exécution de code arbitraire à distance. Des correctifs ont été publiés par VMWare en temps et en heure, ce qui veut dire que tous ces serveurs compromis n’ont pas été « patchés » depuis février 2021. C’est ce que semble confirmer VMWare qui indique que l’ampleur de l’attaque n’est pas due à une vulnérabilité 0 day, mais bien à une obsolescence des serveurs compromis [9].
Exposer l’interface web d’administration d’un serveur VMWare sur internet ne semble pas être une très bonne idée, exposer le service SSH (désactivé par défaut) non plus, mais même si je n’approuve absolument pas, je peux éventuellement comprendre l’intérêt au-delà des risques que cela engendre. Mais exposer le service SLP, j’avoue que j’ai un peu de mal à comprendre… Il est déjà assez difficile de trouver des informations relatives à son utilisation sur les serveurs ESXi, l’hypothèse la plus probable que j’ai pu trouver serait de permettre à serveur vSphere de remonter les informations concernant le matériel utilisé par les serveurs ESXi. Le protocole a l’air tellement utile et utilisé que VMWare a décidé de le désactiver par défaut en 2021 avec l’arrivée des versions ESXi 7.0 U2c et 8.0 [9]. La préconisation de VMWare est de le désactiver pour les versions antérieurs, ce qui nous conforte un peu plus sur sa faible utilité. On supposera que ces machines sont exposées directement chez des hébergeurs sans aucun filtrage des services démarrés, ajouté à l’absence d’application des correctifs de sécurité, forcément, ça peut faire mal. Restons modestes si nos serveurs ne sont pas exposés sur internet, un attaquant ayant un pied dans un SI pourrait lui aussi utiliser une de ces vulnérabilités pour compromettre les hyperviseurs.
Comme le protocole ne semble pas spécialement utilisé, une réponse d’un serveur ESXi à une sollicitation sur ce protocole et pour un de ces services bien spécifique pourrait être une information intéressante à avoir lorsqu’elle passe sur le réseau. Je vous propose donc une règle de détection Suricata que j’ai ajoutée à la collection PAW Patrules [10] pour en être alerté.
[1] /article/4345/les-serveurs-vmware-une-cible-de-choix-pour-les-attaquants.html
[2] https://twitter.com/vxunderground/status/1618885718839001091
[6] https://www.cert.ssi.gouv.fr/alerte/CERTFR-2023-ALE-015/
[8] https://twitter.com/onyphe/status/1622272331421736962?cxt=HHwWhICzteOFvIMtAAAA
[9] https://blogs.vmware.com/security/2023/02/83330.html
L'auteur
Chef de projet sécurité numérique en santé - GCS e-santé Pays de la Loire Charles Blanc-Rolin est également vice-président de l’APSSIS (Association pour la promotion de la Sécurité des Systèmes d'Information de Santé)
