Les hyperviseurs VMware ESXi en version 6.x et antérieures à 6.7 font l'objet d’une campagne d'attaques dans le but d'y déployer un rançongiciel, alerte le CERT de l’ANSSI. Elles exploiteraient la vulnérabilité CVE-2021-21974, pour laquelle un correctif est disponible depuis le 23 février 2021.
« Le CERT-FR recommande d'appliquer sans délai le contournement proposé par l'éditeur dans son article de blogue et qui consiste à désactiver le service SLP sur les hyperviseurs ESXi qui n'auraient pas été mis à jour. Cette modification empêchera les clients CIM de localiser les serveurs CIM via le service SLP. »
Pour autant, souligne le CERT, « l'application seule des correctifs n'est pas suffisante. En effet, un attaquant a probablement déjà exploité la vulnérabilité et a pu déposer un code malveillant. Il est recommandé d'effectuer une analyse des systèmes afin de détecter tout signe de compromission ».
Les produits VMware vCenter Server (vCenter Server) et VMware Cloud Foundation (Cloud Foundation) seraient également vulnérables, précise l'entreprise, qui estime la criticité de la vulnérabilité « à un score CVSSv3 maximum de 9.8 » :
« Un acteur malveillant résidant dans le même segment de réseau qu'ESXi et ayant accès au port 427 peut être en mesure de déclencher le problème de débordement de tas dans le service OpenSLP, entraînant l'exécution de code à distance. »
OVHcloud relève qu'Enes Sönmez, un chercheur turc, a documenté une procédure permettant de récupérer les fichiers VMDK chiffrés, que le taux de succès serait de 2/3, mais que la procédure nécessite de solides connaissances des environnements ESXI.
L'entreprise, qui a envoyé un e-mail à ses clients vendredi après-midi, a bloqué le port 427 OpenSLP entre Internet et les serveurs avec ESXI installé, et scanné ses réseaux pour alerter ses clients compromis. Elle précise : « nous avons des moyens d'action limités puisque nous n'avons aucun accès logique aux serveurs de nos clients ».
Vendredi soir, BleepingComputer dénombrait sur Shodan « au moins 120 serveurs » compromis dans le monde, majoritairement en France, Allemagne et aux États-Unis, par le rançongiciel surnommé ESXiArgs, parce que l’extension des fichiers chiffrés est modifiée en « .args ».
3200 #ESXI touchés depuis vendredi pour #censys, 800 pour #shodan, 2100 pour #onynphe...
— S. A. X. X. (@_SaxX_) February 6, 2023
Je rappelle que ces chiffres ne reflètent pas l'étendue de cette cyberattaque mondiale ! FYI, sur certains ESXI, 2 voire + de clients peuvent y être rattachés.
On est plutôt sur x5 ou + ! pic.twitter.com/tJyXtgrahV
Ce lundi matin, Shodan en répertoriait 785, dont 220 en France, 179 aux USA, 108 en Allemagne et 77 au Canada, 186 hébergés par OVH SAS, 89 par Hetzner Online GmbH, 72 par OVH Hosting Inc., 15 par OVH US LLC et 13 par OVH GmbH.
Onyphe, de son côté, répertoriait 2 112 adresses IP compromises sur quelque 50 000 potentiellement exposées ce dimanche après-midi, et Censys plus de 3200.
Les machines infectées afficheraient, d’après le forum de BleepingComputer, des demandes de rançons d'un peu plus de 2 bitcoins à payer sous trois jours, faute de quoi des données seraient rendues publiques, voire revendues, et le montant de la rançon réévalué.
« Les adresses de paiement sont différentes pour chaque victime, mais l’identifiant de messagerie instantanée chiffrée Tox ne change pas », précise LeMagIT.
Commentaires (38)
#1
Si je comprends bien, il faut que le port 427 soit exposé sur Internet ?
#1.1
Soit exposé sur Internet pour cette attaque précise, mais quid du reste ?
Imagine quelqu’un qui a infecté et scanné ton réseau, et qui, non repéré, attende le bon outil pour déclencher l’attaque ? Et si un de tes utilisateurs s’est choppé une porte dérobée à travers une saleté ?
Et ensuite, qu’est-ce qui garanti que ce soit cette faille concernée ?
Bref, entre ça et des pubs google à évasion, perso, je suis d’une méfiance hors normes ces jours-ci….
#1.2
J’ai MAJ les explications du CERT : « Cette modification empêchera les clients CIM de localiser les serveurs CIM via le service SLP. »
& de VMWare : « Un acteur malveillant résidant dans le même segment de réseau qu’ESXi et ayant accès au port 427 peut être en mesure de déclencher le problème de débordement de tas dans le service OpenSLP, entraînant l’exécution de code à distance. »
#1.3
j’ai pas compris à partir de qu’elle version ça à été patcher par contre.
#1.4
cf l’alerte CERT:
ESXi versions 7.x antérieures à ESXi70U1c-17325551
ESXi versions 6.7.x antérieures à ESXi670-202102401-SG
ESXi versions 6.5.x antérieures à ESXi650-202102101-SG
#1.5
suis pas encore aller voir , merci :)
#2
La faille est critique et corrigée depuis 2 ans… soupir
#2.1
Malheureusement, les mises à jours VMWare en entreprise sont régulièrement appliquées que lors de grands cycles de maintenance, c’est à dire tous les 1a, 2a voir 3a ou plus… Nombre d’entreprises ont un VMWare qui n’est jamais mis à jour sauf le jour du changement de serveur physique…
#2.2
Faut avouer que les maj sont super contraignantes… Pour le Vcenter ça va, c’est long (genre 2-3h) mais ça se fait tranquillement.
Pour les ESX, faut le passer en maintenance, attendre que toutes les VM soient réparties sur les autres noeuds, couper, faire la maj, prier, reboot, et ça pour chaque noeud… Et encore, faut check touuuuuutes les putin de compatibilité du hardware, ou récup la maj du constructeur (ce qu’on fait) qui ne sort pas forcément en même temps.
Le jour où ils auront un système de maj un peu moins bourrin peut-être qu’en entreprise les majs seront faites plus souvent ^^
#2.3
et ça c’est dans un cadre esx pure, nous c’est simplivity donc les maj tu attends la validation HPE avant de les passer… et leur matrice de compatibilité est merdique au possible :/
#2.4
Je plussoie, la mise à jour des hôtes est un calvaire, je ne comprend pas qu’une société comme ça n’est pas pensé à un système plus souple.
Le problème est aussi sur les version “Custom” pour Dell ou HPE par exemple , elles ne sont pas toujours suivies ce qui complique le processus de màj.
#2.6
Pour les MAJ mineurs pas besoin d’image constructeur. Les images constructeurs ne font qu’ajouter des drivers aux ESXi (iDRAC,NIC, iLO…)?
DRS permet d’automatiser les MAJ sur les grandes infra. Sinon avec vMotion seul ça ce fait bien, et c’est rare qu’un maj mineur casse un ESX (j’ai pas le souvenir).
La procédure est pas plus compliqué qu’un Windows Update et sans arrêt de service pour les VMs.
#2.7
vient automatiser les maj sur mon infra simplivity avec DRS. je t’attends :)
#2.8
Simplivity c’est un peu le mal avec l’ASIC….
#2.9
franchement ça marche quand même pas mal
#2.10
Moi je patche avec les profils baseline et du vMotion pour pas couper la prod.
Je verrai pour le DRS mais je crois que nous n’avons pas la licence.
Merci de l’info :)
#2.5
Je ne le sais que trop bien ayant des hôtes VMWare et ayant fait les MAJ complète plusieurs fois mais c’est du niveau de l’irresponsabilité de ne pas avoir traiter cette MAJ critique!
Et puis les environnements virtualisés permettent une sacrée souplesse (migration des VMs, etc).
Donc non juste non, ceux qui se font hacker sont responsables et ont mal géré leur infra.
#3
ESXi… Super outil, mais quand tu te retrouves comme un con car ton CPU serveur n’est plus supporté par les nouvelles versions…
#4
Vu le niveau de service de votre, les possibilités de migration, de clustering pour les gestes, et l’époque où nous vivons…
Reporter le problème sur vmware en disant que c’est compliqué c’est un peu puéril, non?
#4.1
J’ai pas dit qu’on faisait pas les maj :) (on les fait:)) mais que leur système de maj est très lourd, et peut dissuader certaines PME de faire les maj.
Et sachant qu’on est souvent bloqué par les ISO Custom des constructeurs, car oui, si tu veux pas mettre à plat ton infra, tu fais pas une upgrade avec l’ISO générique, tu ne connais pas les problèmes qu’il peut y avoir avec tout ton matériel.
#5
La routine habituelle.
#6
Ne pas oublier aussi que la faille n’est concernée que si le port 427 était ouvert du coup ça limite beaucoup le nombre de personne concerné.
(perso chez nous il était toujours fermé).
Bon l’avantage c’est que ça donne un prétexte pour tout mettre à jour à nouveau. :o
#7
Je ne comprend pas comment on peut “oser” mettre un hyperviseur accessible sur internet, sans VPN ou autre…
Surtout de la part d’un FAI en Italie.
#7.1
Parce qu’un VPN ça cause des problèmes. Les VPN c’est généralement tout ou rien ce qui surcharge les connexions internet, rarement possible de ne faire passer que le bureau à distance par exemple.
#8
Peut-être parce-que toi tu es sérieux et expérimenté (voire ce qu’il faut d’un peu parano…).
Ailleurs de plus en plus de gens choisissent la voie de la facilité, gestion Yolo du pare-feu quand il y en a un, oubli de l’utilité d’un proxy (surtout quand des éditeurs de logiciels ne semblent plus savoir ce que c’est… Coucou SUSE !), téléchargement à gogo via pip, docker hub, etc.
A l’heure actuelle, la sécurité périmétrique d’un réseau n’est plus suffisante, mais ça reste une base importante que beaucoup devraient éviter d’oublier. Sauf si ils aiment beaucoup les Tipiaks…
#8.1
Sans compter les vulnérabilités dans les containers qui en plus ne sont pas étanche contrairement à ce que pense beaucoup
#8.2
Purée le hub docker et pip les 2 trucs ingérables au SI…
#9
Revenir un lundi matin et voir que plus de 2000 vms ont été migrées : ☑️
#10
Parce qu’un VPN ça cause des problèmes. Les VPN c’est généralement tout ou rien ce qui surcharge les connexions internet. Suivant qui utilise le VPN il peut y avoir de gros transferts qui se retrouvent sur le réseau de l’entreprise comme des mises à jour Steam, Origin etc…
Il est rarement possible de ne faire passer que le bureau à distance par exemple.
#10.1
Les tables de routage, ce n’est pas fait pour les chiens, même sous Windows.
#11
Franchement je suis stupéfait de ce que je peux lire ici , en effet un esx , faut le mettre a jour, systeme barbare oO , je vois pas en quoi, iso personnalisé…..
Quand tu installe windows, tu vas chercher les drivers de ton materiel ou tu utilises les drivers fournis par microsoft?
C’est identique sous vmware , la hcl existe avec la compatibilité et il te fournisse le driver de ton matériel pour la build associé ( mettez a jours vos firmwares également)
Je parle de la v7 ou via le lifecycle manager tout est fourni pour la quasi totalité des constructeurs, plus rien a faire presque.
L’obsolescence forcée pour les matériels est la seule excuse, ou presque, car les failles sont patchées malgrés tout tant que le build est supporté.
Bref, n’accusé pas l’éditeur quand la négligence/méconnaissance vient de l’administrateur.
#11.1
je vais me répéter mais dans le cas de simplivity je ne peux pas faire de maj si elle n’a pas été valider par HPE sous peine de perdre le support …
donc si parfois c’est lié aux éditeurs…
#11.2
Et HPE assume les risques tant que tu ne peux pas faire cette mise à jour de sécurité ?
Ou bien, vous perdez tous les cas ?
#11.3
d’après toi … :‘(
dans le cas de cette faille nous ne sommes pas impactés (nous sommes en 7u3i).
mais sur la dernière nous avions du faire la solution de contournement (qui ne corrigeais pas tout) et planifier un upgrade du simplivity (ce qui prends 2 jours au vu de la lenteur du processus avec simplivity (faut déjà 1h30 par host pour mettre à jours les firmwares, rajoute les esx …)
bref c’est quand même long et chiant à mettre à jour et tributaire dans certains cas des constructeurs
#12
Et vous avez pensé à une solution libre (AGPL V3) européenne (allemande) pour remplacer ESXi (Proxmox VE) ?
https://fr.wikipedia.org/wiki/Proxmox_VE
-> Hyperviseur officiellement promu par la DINUM dans son Socle Interministériel des Logiciels Libres (SILL).
#12.1
En quoi c’est une solution plus safe pour gérer ses VM ? C’est pas tant lié au fait d’être propriétaire vs libre. Il y a potentiellement autant de failles dans l’un comme dans l’autre et ESXI a fixé la faille depuis un moment.
Du point de vue totalement sécuritaire, Proxmox se base sur KVM qui reste utilisable via libvirt (virsh, virt-manager, …). Pourquoi conseiller une surcouche qui peut amener des failles potentielles ?
Pour un commentaire qui sous-entendrait que ceux qui ont choisi ESXI ont survolé la question de la sécurité, c’est balo de tomber dans le même piège. Ca reste surtout un choix d’ergonomie ici, et là, il n’y a pas de choix objectivement meilleur qu’un autre.
Et il est encore acceptable de choisir quelque chose qui favorise l’ergonomie par rapport à la sécurité (ajouter une couche est toujours un risque), le tout est de peser les apports par rapports aux coûts, en sachant qu’il est possible de sécuriser ça par des restrictions au niveau réseau. Tu proposes Proxmox, donc tu dois être d’accord avec ça ;)
Du coup, c’est quand même mieux d’éviter de sous-entendre que les victimes auraient dû faire un meilleur choix technique quand l’alternative secure proposée n’est clairement pas meilleure. On dépend tous de soft externe, la sécurité absolue n’existe pas. Un peu de compassion ne ferait pas de mal ;)
#12.2
Je pense que sa proposition est plus pour indiquer une alternative, en particulier aux utilisateurs qui ne peuvent pas upgrader pour des raisons d’obsolescence. Tant que le noyau debian supporte le serveur, Proxmox fonctionne. Il faut peut-être mieux une plateforme moins ergonomique mais à jour des patches de sécurité, que la dernière supportée sur ce hardware et qui fait office de cible de choix pour compromettre l’infra.
Oui, ça n’est pas idéal (en particulier de maintenir deux infras, etc…), mais dans certains cas, ça peut être utile: réutilisation de serveurs pour faire dev vms de tests/devs/non exposées.
Je n’ai pas lu d’attaque dans son approche, juste une ouverture vers d’autres outils. On aurait pu mentionner aussi OpenStack (bien plus violent à mettre en place, et en fonction des editeurs, là aussi des notions de matériel supporté), Ganeti, oVirt, etc…