La Fibre
Télécom => Réseau => 
Attaques informatiques => Discussion démarrée par: vivien le 03 février 2023 à 21:27:44
-
Campagne d’exploitation d’une vulnérabilité affectant VMware ESXi
(https://lafibre.info/images/logo/logo_faille_securite.jpg)
On a vu dans le passé que de grosses attaques ont eu lieu avec des failles corrigées depuis plusieurs mois.
L'attaque de ce jour, que certains attribuent à la Russie, est de ce type. C'est une faille affectant VMware ESXi corrigée fin 2020 et redue publique début 2021.
(https://lafibre.info/images/presse/202202_campagne_exploitation_vulnerabilité_vmware_esxi_1.webp)
-
Le bulletin d'alerte de Cert de ce soir : https://www.cert.ssi.gouv.fr/alerte/CERTFR-2023-ALE-015/
(https://lafibre.info/images/presse/202202_campagne_exploitation_vulnerabilité_vmware_esxi_2.webp)
Documentation :
- Bulletin de sécurité VMware VMSA-2021-0002 du 23 février 2021 (https://www.vmware.com/security/advisories/VMSA-2021-0002.html)
- Avis de sécurité CERT-FR CERTFR-2021-AVI-145 du 24 février 2021 (https://www.cert.ssi.gouv.fr/avis/CERTFR-2021-AVI-145/)
- Référence CVE CVE-2021-21974 (https://www.cve.org/CVERecord?id=CVE-2021-21974)
[1] Procédure permettant de désactiver le service SLP (https://kb.vmware.com/s/article/76372)
[2] Les bons réflexes en cas d’intrusion sur un système d’information (https://www.cert.ssi.gouv.fr/les-bons-reflexes-en-cas-dintrusion-sur-un-systeme-dinformation/)
-
Certains disent que les VMware ESXi en langue russe ne sont pas touchés :
(https://lafibre.info/images/presse/202202_campagne_exploitation_vulnerabilité_vmware_esxi_3.webp)
Source : https://twitter.com/ProcessusT/status/1621545044569120770
-
Correctif sorti en 2021.
Ceux qui n'ont pas daigné patcher entre temps sont les uniques responsables de leur malheur, on ne laisse pas un hyperviseur avec une IP publique sans mises à jour pendant deux ans.
C'est de la sélection naturelle quoi :P
-
Correctif sorti en 2021.
Même pas, les correctifs pour 6.7 et 7.0 sont sortis fin 2020.
Versions corrigées :
- vCenter Server 7.0 : 7.0 U1c du 17 décembre 2020
- vCenter Server 6.7 : 6.7 U3l du 19 novembre 2020
- vCenter Server 6.5 : 6.5 U3n du 23 février 2021
-
on ne laisse pas un hyperviseur avec une IP publique sans mises à jour pendant deux ans.
Heh, pour un industriel, on ne patch/reboot jamais un système qui fonctionne... "L'uptime du serveur est de 4 ans, si on le reboot, y'a une grande chance qu'il redémarre pas, et on peut pas se permettre de perdre notre SCADA".
Certains mettent ca derrière des VPN et firewalls, d'autres, hm.
-
Oui enfin un hyperviseur c'est justement fait pour faire une couche d'abstraction entre ton applicatif et le matériel, c'est pas vraiment une excuse
-
Pour gérer le serveur par défaut qui distribue les mises à jour Ubuntu pour la France, je vois un pourcentage stable de version obsolète d'Ubuntu qui sont demandées.
Statistiques d'hier :
(https://lafibre.info/testdebit/ubuntu/202302_ubuntu_statistiques_versions.webp)
-
Je suis vraiment surpris par la proportion de personnes qui utilisent une LTS : plus des 2/3 sont en 20.04 ou en 22.04 et à peine 2% en 22.10 (alors que j’installe moi même des LTS…).
-
Oui, il y a plus d'utilisateurs d'Ubuntu 14.04 que de la dernière version d'Ubuntu (22.10).
Ubuntu 14.04 est sortie en avril 2014 et sans mise à jour, sauf à avoir pris ESM qui à l'époque n'était pas gratuit.
Pour la quasi-totalité de ces Ubuntu 14.04, le support s'est arrêté le 25 avril 2019, elles ont donc un nombre de failles énormes, pourtant ces PC ou serveurs sont bien connectés à Internet vu que je reçois les demande de mise à jour.
-
Oui enfin un hyperviseur c'est justement fait pour faire une couche d'abstraction entre ton applicatif et le matériel, c'est pas vraiment une excuse
On est d'accord, mais dans certains milieu avec lequel je travaille (energie notamment) ils ne le voient pas comme ca.
Les machines industrielles déployées dans des centrales/sous stations sont considérées comme des gros automates ou appliances plus qu'autre chose. On ne fait pas d'upgrade in place, on upload une VM patchée (et normalement testée et validée en labo, quoi qu'encore...) sur l'hyperviseur, on démarre la nouvelle VM, on bascule l'applicatif et on éteint l'ancienne VM.
Vu qu'on ne peut pas faire ca avec l'hyperviseur et que bien souvent, il n'y a qu'une seule machine physique sur site pour des raisons de coût... l'hyperviseur (et l'OS hote, quand il y en a un) n'est jamais patché.
Ce sont des milieux qui considèrent le réseau comme un sanctuaire, une zone sécurisée, dans laquelle rien de bien grave ne peut se produire. Pas facile de faire changer les mentalités :)
-
Je suis vraiment surpris par la proportion de personnes qui utilisent une LTS : plus des 2/3 sont en 20.04 ou en 22.04 et à peine 2% en 22.10 (alors que j’installe moi même des LTS…).
La promesse de la LTS, c'est qu'une fois installée, tu as des mises à jour pendant 5 ans (au moins, tu peux avoir plus avec un contrat avec Canonical) et normalement pas de casse après une upgrade du fait de nouvelles versions incompatibles d'un soft. Ca convient tout à fait à l'attente des entreprises, dont l'IT a peur du moindre changement.
Je ne l'ai pas vu de moi même, mais on m'a déjà dit plusieurs fois que dans la banque ou le gouvernement, ca tourne souvent sous RHEL4...
-
Vu qu'on ne peut pas faire ca avec l'hyperviseur et que bien souvent, il n'y a qu'une seule machine physique sur site pour des raisons de coût... l'hyperviseur (et l'OS hote, quand il y en a un) n'est jamais patché.
Dans ce milieu que tu connais qui pourtant est sensible à la disponibilité, tu nous dis qu'il y a des systèmes "industriels" qui fonctionnent avec un gros SPOF, dans leur architecture ? Que se passe-t-il si le host hyperviseur a une panne ?
Perso, j'ai toujours vu (certes, en datacenters) des architectures avec beaucoup plus de redondance ...
-
Je ne l'ai pas vu de moi même, mais on m'a déjà dit plusieurs fois que dans la banque ou le gouvernement, ca tourne souvent sous RHEL4...
Et dans la banque, combien de lignes de Cobol qui tournent encore ?
-
Dans ce milieu que tu connais qui pourtant est sensible à la disponibilité, tu nous dis qu'il y a des systèmes "industriels" qui fonctionnent avec un gros SPOF, dans leur architecture ? Que se passe-t-il si le host hyperviseur a une panne ?
Perso, j'ai toujours vu (certes, en datacenters) des architectures avec beaucoup plus de redondance ...
Des infras sensibles sans vMotion ?
La bonne blague.
-
Dans ce milieu que tu connais qui pourtant est sensible à la disponibilité, tu nous dis qu'il y a des systèmes "industriels" qui fonctionnent avec un gros SPOF, dans leur architecture ? Que se passe-t-il si le host hyperviseur a une panne ?
Il y a défaut du SCADA, ce qui ne l'empêche pas forcément de fonctionner mais impacte le contrôle à distance et la collecte/remontée de données.
C'est le cas d'install solaires de plusieurs MW, petit hydraulique, parfois de l'éolien, et de petites sous stations ENEDIS.
Si défaut du SCADA il y a, les protections sont toujours actives et l'énergie est toujours produite ou fournie. Un gars doit se déplacer sur site pour réparer la panne.
Contrairement au monde de la tech, c'est un monde qui considère que la panne arrivera coute que coute et qui s'en accomode. Bien évidemment dans une centrale de plusieurs centaines de MW voire plus, il y a de la redondance, ce n'est pas pareil.
-
Oui enfin un hyperviseur c'est justement fait pour faire une couche d'abstraction entre ton applicatif et le matériel, c'est pas vraiment une excuse
Hélas, la compréhension des intérêts de la virtualisation dans sa globalité, c'est à dire non pas un mais au moins trois hyperviseurs, pour permettre de la haute disponibilité, la migration de VM et donc, l'arrêt d'un serveur matériel pour sa mise à jour sans arrêter l'infra, ça exige de comprendre, et ensuite, de payer materiel surnuméraire et, dans le cas de VMWare, des licences...
Compréhension globale, coûts matériels, prix, trois vivants promoteurs de la sélection naturelle.
Fondamentalement, c'est regrettable, surtout qu'il existe une solution déployable sans coût de licence, voire avec un coût à la marge avec support, Aïe aïe aïe, en Anglais (c'est dingue comme ça détermine la non adoption), Proxmox.
-
J'aime bien Proxmox en @home ou bien pour une utilisation pour une asso genre Milkywan mais il manque pleins de features à Proxmox par rapport à VMWare...
-
On a peu entendu parler du fait que Resecurity (https://www.resecurity.com/blog/article/nevada-ransomware-waiting-for-the-next-dark-web-jackpot) indique que Nevada Ransomware ne fonctionne pas quand les paramètres régionaux sont configurés pour correspondre aux zones géographiques de la Russie, certains pays de l'ex-URSS, et ce qui est plus intéressant - Albanie, Hongrie, Vietnam, Malaisie, Thaïlande, Turquie, Iran.
Maintenant, est-ce que la campagne actuelle est liée à Nevada Ransomware ? Je n'en suis pas sûr.
-
Pour ceux qui se sont fait chiffrer leur ESXi 6.x, voici la méthode pour déchiffrer les données : https://enes.dev/
Il explique que le virus chiffre les petits fichiers comme .vmdk .vmx, mais pas le fichier server-flat.vmdk.
Dans la structure ESXi, les données réelles sont conservées dans flat.vmdk.
Le tutoriel explique donc comment faire un repli en utilisant flat.vmdk.
-
J'aime bien Proxmox en @home ou bien pour une utilisation pour une asso genre Milkywan mais il manque pleins de features à Proxmox par rapport à VMWare...
Je suis d'accord que VMWare ESXi est la Rolls des hyperviseurs (à condition de payer les licences pour activer les différentes fonctionnalités), et que c'est donc l'hyperviseur le plus répandu, mais c'est donc aussi le windows des hyperviseurs, le plus attaqué de ce fait. Il faut donc le surveiller comme le lait sur le feu.
Pour Proxmox, il a de plus en plus de fonctionnalités, et il est utilisé pour bien plus que de simples associations. Et comme il est plus confidentiel, il est aussi beaucoup moins attaqué.
Ce qui m'étonne dans ces attaques, c'est qu'on dise qu'elles concerneraient des ESXi exposés sur Internet. Cela m'tonnerait qu'il y ait beaucoup de monde qui le laisseraient exposés sur Internet. Par contre, par un accès interne, par exemple parce que grâce à du phishing, on ait récupéré des identifiants pour y accéder en VPN, j'y crois beaucoup plus.
J'aimerais bien avoir des détails sur ces attaques, mais malheureusement, comme beaucoup d'attaques par ransomware ou autres, on a souvent très peu de retex. Ce serait pourtant bien utile pour prendre les mesures adéquates pour ses propres infrastructures...
-
Cet exploit fonctionne en utilisant le service SLP.
Si tu n'as qu'une machine sur un hébergeur, le plus simple est de l'exposer sur Internet.
Ce n'est effectivement pas le cas quand c'est une entreprise un peu sérieuse avec une infrastructure plus conséquente.
Enfin, je comprends que l'on ne réalise pas de mise à jour tous les mois, mais aucune mise à jour en deux ans...
De façon plus globale, il serait intéressant de savoir le % d'attaque réussie qui aurait pu être évité par des mises à jour plus fréquentes.
Dans cette liste d'hôpitaux attaqués en 2022, pour lesquels c'est lié à un défaut de mise à jour ?
- Clinique Léonard de Vinci de Chambray-les-Tours : attaque par ransomware le 7 janvier. Les malfaiteurs ont demandé 500 000 euros de rançons.
- Cité sanitaire de Saint-Nazaire : attaquée le 12 janvier, les patients sont privés de télévision, d’Internet et de communication avec leurs proches.
- Hôpital de Castelluccio, Ajaccio : touché par un ransomware le 28 mars, les soins de radiologie et oncologie étaient suspendus.
- L’hôpital de Saint-Dizier et de Vitry-le-François : victimes d’un ransomware le 19 avril. Les auteurs exigeaient une rançon de 1,2 million d’euros.
- Centre hospitalier de Mâcon : touché le 27 mai.
- Centre hospitalier de Corbeil-Essonnes : attaque par ransomware le 20 août, revendiquée par Lockbit. Demande de rançon de 1 million d’euros.
- Hôpital de Cahors : cyberattaque le 12 septembre.
- Maternité des Bluets, Paris XIIIe : touchée par un ransomware le 9 octobre, revendiqué par Vice Society.
- Hôpital André-Mignot, Versailles : attaque par ransomware le 3 décembre.
J'ai toujours le souvenir de cet hôpital qui ne se cachait pas de déployer de nouveaux postes Windows 7 en 2021 alors que ce système n'était déjà plus maintenu.
-
Si tu n'as qu'une machine sur un hébergeur, le plus simple est de l'exposer sur Internet.
C'est effectivement le plus simple, mais certainement le moins sécurisé, Internet est une jungle.
Il faut être fou pour mettre un ESXi directement sur Internet. Et quand on a un ESXi (avec le coût que cela a), on a certainement plusieurs machines, et ce n'est certainement pas un hôpital.
Donc, cela pourrait arriver pour une personne ou une petite association, mais à mon avis certainement pas pour une institution plus grosse. Personnellement, je crois bien plus à l'obtention d'identifiants permettant l'intrusion dans le réseau interne, ou dans le réseau hébergé par VPN. Il y a d'ailleurs aussi régulièrement des failles de sécurité dévoilées sur les solutions VPN les plus courantes, qui permettent probablement de se passer même d'identifiants.
-
J'ai récemment reçu par courrier, dans une lettre à mon attention, une clé USB, dénudée, sans cache plastique. Pas d'expéditeur, adresse manuscrite bien gauche.
J'ai ri. Je ne l'ai bien sûr pas insérée où que ce soit.
Quelqu'un s'est fait suer à trouver l'identité de la personne qui pilote l'infra de la structure médicale où je bosse, et, au cas où, m'envoie ça.
Je répète à l'envie à tout le personnel de n'insérer aucune clé USB trouvée dans la rue dans le moindre port usb, et les stations voient leurs ports USB désactivés. Aucune faille humaine n'est jamais impossible, alors je répète souvent les bonnes pratiques.
Je me suis promis d'essayer la clé sur un vieux laptop, pour forensic un peu, mais le temps me manque pour travailler la question. Je la garde sous clé pour l'analyser à l'occasion. J'en extrairais le contenu en une image, pour la monter et analyser un peu.
Manifestement, si on assiste à tant de mises en cause, c'est que la pratique est rentable. Porter atteinte à une institution médicale, c'est pathétique. Plus rien n'est sacré. Tout n'est que gain potentiel.
-
Je pense que les attaques évoquées par vivien contre des établissements de santé, ou bien la tentative dont a été victime Gnubyte, ont cherché à profiter d'un "facteur humain", que ça soit au travers d'un mail mal filtré, d'une page web frauduleuse, ou même d'un support externe.
Dans ce milieu où par ailleurs les "interactions" avec le monde extérieur sont très nombreuses, la population importante d'intervenants ayant recours obligatoirement à l'informatique pour accomplir leurs missions, qu'ils soient permanents, contractuels, intérimaires, prestataires, etc, ne permet pas de les former suffisamment à la méfiance, à la vigilance, à la conduite à tenir en cas de doute.
Je n'évoque pas ici le sous-investissement "technique". Une des victimes citées par vivien m'indiquait (alors que son établissement fonctionnait encore en mode dégradé) que la modernisation du SI se ferait sur un calendrier nettement raccourci par rapport au plan initial.
-
il y a du nouveau :
https://www.lemagit.fr/actualites/365530753/ESXiArgs-le-ransomware-revient-avec-une-nouvelle-version
-
Modification de la méthode de chiffrement rendant la restauration des données difficile voire impossible.
Source: https://twitter.com/CERT_FR/status/1624085352582459396
-
Cet exploit fonctionne en utilisant le service SLP.
Si tu n'as qu'une machine sur un hébergeur, le plus simple est de l'exposer sur Internet.
Effectivement, en regardant avec sodan.io, on trouve un paquet de ESXi exposés sur Internet, dans les plages IP des gros hébergeurs "bare metal" (OVH, Hetzner).
Et je ne parle pas de cet hébergeur PRO, avec 2000VM impactées https://twitter.com/FlorianLeroyFR/status/1621524448775143424
Même dans ce cas, il n'y a pas trop d'excuse.
Tu peux facilement mettre des règles firewall dans ESXi pour n'autoriser le trafic management (TOUT le trafic management) qu'avec des adresses IP de confiance.
L'hébergeur qui vend le "bare metal" peut également proposer un firewall.
On peut aussi mettre en place un réseau de management sur un VLAN isolé. Quitte à faire une porte d'accès via un serveur VPN sur un petit VPS (à 10€/mois) du même hébergeur.
Tous les hébergeurs "bare metal" proposent ça. Et ces options "Vrack / Vswitch" sont de moins en moins chères, voires "gratuites" (=intégrées dans le prix des serveurs), contrairement à ce qu'il se pratiquait il y a ~10 ans.
Donc oui, mettre des ESXi exposés sur Internet, et ne pas les patcher depuis 2 ans, c'est "joueur".
Leon.
-
J'ai lu que plus de 72% des serveurs ESXi attaqués sont hébergés chez OVHcloud.
=> https://www.channelnews.fr/plus-de-72-des-serveurs-esxi-attaques-sont-heberges-chez-ovhcloud-122067
-
J'ai lu que plus de 72% des serveurs ESXi attaqués sont hébergés chez OVHcloud.
=> https://www.channelnews.fr/plus-de-72-des-serveurs-esxi-attaques-sont-heberges-chez-ovhcloud-122067
Un article intéressant de GreyNoise qui explique ça.
https://www.greynoise.io/blog/exploit-vector-analysis-of-emerging-esxiargs-ransomware
La grosse majorité des serveurs ESXi 100% exposées, c'est effectivement chez OVH. Donc pas étonnant qu'OVH soit recordman de machines infectées par ESXiArgs.
OVH et Hetzner sont bien les 2 plus gros fournisseurs de serveurs bare-metal low-cost, avec des tarifs bien inférieurs à la concurrence, et aussi (c'est important) des machines en stock.
Après, est-ce que ces hébergeurs n'ont pas également une part de responsabilité dans ce genre de situation? Ils ont indéniablement un rôle d'éducation de leurs clients.
Donc ils pourraient très bien:
- détecter en semi-automatique des machines ESXi exposées
- informer le client qu'il prend de gros risque, surtout pour les clients qui achètent de grosses infrastructures
- proposer des solutions quasi clef-en-main pour une installation ESXi, avec gestion de VLANs de management, plutôt que de laisser les clients bricoler.
- proposer des tutoriels, des scripts, pour isoler proprement un ESXi dès l'installation, avec les spécificités des outils du cloud-provider.
Je ne connais pas les "us et coutumes" de ce marché, mais ça me semblerait sain comme démarche, de la part du "cloud provider".
Leon.
-
Après, est-ce que ces hébergeurs n'ont pas également une part de responsabilité dans ce genre de situation? Ils ont indéniablement un rôle d'éducation de leurs clients.
Sans vouloir remuer le couteau dans la plaie : OVH n'avait peut-être pas non plus "éduqué" ses clients sur la lecture des lignes du contrat d'hébergement concernant la localisation des backups ...
-
Non, il y a une raison plus profonde : OVH proposait une solution ESXi clés en main, pour des personnes qui n'ont aucune connaissance VMware.
-
Un truc que pourrait faire OVH à minimum : supprimer la mention "OS supporté : VMWARE-ESXi" pour toutes les gammes de serveurs bare-metal qui n'ont pas de Vrack.
Sur des serveurs bare-metal sans VRack, je ne vois pas trop comment on peut isoler le réseau de management, à moins de faire des bidouilles scabreuses à base de serveur VPN interne.
Leon.
-
Cela semble tourner à la catastrophe chez Hebergnity.com - Hébergeur de sites internet et de solutions web depuis 2017
On rigole avec ESXi mais j'ai +2000 VM down. Merci le ransomware VMware Nevada.
Nous avions développé notre système de création de VMs et d'installations des serveurs depuis un script fait maison et que celui-ci ne fonctionnait pas sur les versions ultérieures.
Pas la meilleure des excuses j'en ai conscience, mais vu le temps passé à trouver l'idée de comment fonctionne la création et la mise en place de celui-ci, nous avions pas vraiment envie de retravailler cela...
Source : @FlorianLeroyFR (https://twitter.com/FlorianLeroyFR/status/1622113898210918400) Directeur technique Hebergnity.com
Sur le tweeter officiel, je n'ai trouvé que ça : (le lien ne permet pas de voir si service fonctionne aujourd'hui)
[INTERVENTION] Les machines Hebergnity sont actuellement touchées parmi les victimes d'un virus VMware ESXi mondial. ☹️
Plus d'informations ici :
👉 https://hebergnity.com/esxi-nevada
Source : Twitter Hebergnity.com (https://twitter.com/Hebergnity/status/1621538557327187973)
(https://lafibre.info/images/presse/202202_hebergnity_panne_esxi.jpg)
Vous arrivez à lire le communiqué de presse ?
-
Au moins, il y a une certaine franchise...
-
Hebergenity continue à parler de "Nevada", alors qu'on sait depuis 1 semaine que ça n'est pas Nevada qui est utilisé.
Le nouveau RansomWare c'est ESXiArgs .
J'aimerais bien savoir combien de serveurs ils ont chez OVH, mais ça doit être conséquent. 2000 VM, ça tient sur ~50 serveurs? Entre 5000 et 10 000€/mois, on est d'accord sur l'ordre de grandeur?
Effectivement, ils ont l’honnêteté de la franchise... Mais 50 serveurs exposés et pas à jour depuis 2 ans... C'est un cas d'école, qui sera dans les cours de sécurité informatique.
Leon.
-
Je vois que Leon, tu arrives à lire le communiqué de presse.
J'ai donc testé avec Orange et cela passe (blocage systématique avec SFR).
Voici une copie d'écran pour ceux qui n'arrivent pas à y accéder : (il a été mis à jour aujourd'hui, les services ne sont toujours pas rétablis)
(https://lafibre.info/images/presse/202202_hebergnity_panne_esxi_communique_presse.webp)
-
Leur discord semble être en lecture seule, mais il y a des informations :
(https://lafibre.info/images/presse/202202_hebergnity_panne_esxi_discord.webp)
Effectivement certains nodes sont up, 11 jours après l'attaque :
(https://lafibre.info/images/presse/202202_hebergnity_panne_esxi_discord_etat.webp)
-
Donc HerbergNity aurait 2000 VM dans seulement 14 hosts!
140 VM par host...
Si c'est confirmé, c'est un sacré overbooking...
Donc des hosts "hyperconvergés" aussi haut de gamme, aussi critiques, exposés sur Internet, et pas à jour depuis 2 ans, c'est encore plus choquant.
Leon.
-
Pour moi ça semble plutôt être du hosting d'entrée de gamme, et je connais certains presta en 5 lettres qui font bien pire comme contention :P
-
Un de plus : https://cloudfordream.com/
(https://lafibre.info/images/presse/202302_cloudfordream_attaque_esxi.webp)
-
Et d'ailleurs, ça dit :
Cloudfordream ne rouvrira pas ses portes
qu'en pensent les clients ? Que leur proposera la maison mère (https://meliamgroup.com/#)
-
https://cloudfordream.com/
Nous pouvons désormais affirmer que le Ransomware n'a pas eu accès à vos données, l'attaque visait simplement à encrypter les disques de manière à rendre les données inaccessibles.
On est sur de ça? On a des preuves? Genre des honney-pot dont on aurait espionné le traffic management, et qui ne montrerait aucune exfiltration de donnée? Je n'ai pas souvenir d'avoir lu ce genre de certitude dans les quelques articles que j'ai lu sur ESXiArgs.
Leon.
-
Je pense que c'est basé sur le trafic les derniers jours avant l'attaque : exporter des To, cela se voit.
Maintenant, l'attaquant peut récupérer 1 Go par-ci par là discrètement.
Autre point, la faille à deux ans, on ne sait pas depuis quand les attaquants ont pris le contrôle de l'ESXi.
C'est le gros problème : les données sont peut-être compromises sur les VM avant le chiffrement.
La leçon à retenir, c'est d'appliquer les mises à jour.
-
La leçon à retenir, c'est d'appliquer les mises à jour.
Pour moi, c'est trop restrictif d'incriminer juste un problème de mise à jour.
Ces hébergeurs semblent cumuler 3 problèmes majeurs
- hyperviseurs pas à jour depuis 2 ans
- pas d'isolation du réseau de management, alors même que les serveurs physiques utilisés (haut de gamme) ont une option "VLAN isolé" sans surcout (valable chez OVH et Hetzner). Donc aucune excuse.
- probablement pas de réel "disaster recovery plan" / "PRA", testé. D'ailleurs, le site d'HebergNity ne fait mention d'aucun backup sur les offres VPS.
Avec seulement un des 3 manques corrigés, ils auraient certainement géré cette crise de manière beaucoup plus légère et indolore pour les clients.
Leon.
-
Oui, tu as raison.
Certains sont énervés de telles lacunes de sécurité et ont remercié les auteurs de l'attaque :
(https://lafibre.info/images/presse/202202_campagne_exploitation_vulnerabilité_vmware_esxi_4.webp)
Source : Twitter de Jean-Philippe SALLES (https://twitter.com/JPS_CTI/status/1622861423176032257)
-
Certains sont énervés de telles lacunes de sécurité et ont remercié les auteurs de l'attaque
Les professionnels de l'IT nombreux ici ne peuvent pas se réjouir du malheur des "victimes", clients de ces fournisseurs.
En revanche, la négligence de certains, hébergeurs en particulier, est vraiment exaspérante.
Comme dit précédemment, ce sinistre était très largement évitable.