Une vague d’attaques vise actuellement les serveurs ESXi. Chez OVHcloud, aucun de nos services managés n’est impacté par cette attaque. Cependant, à mesure que de nombreux clients utilisent ce système d’exploitation sur leur propre serveur, nous publions cet article en tant que référence pour les aider à reduire leur exposition à ce risque.
Ces attaques sont détectées mondialement et notamment en Europe. Selon nos analyses, les experts de l’écosystème ainsi que les autorités le malware utiliserait la vulnérabilité CVE-2021-21974 comme vecteur de compromission. Les enquêtes sont toujours en cours pour confirmer cette hypothèse. Nos équipes techniques travaillent à l’identification détaillée des caractéristiques de l’attaque tout en se coordonnant avec nos pairs des autres CERT et des équipes de sécurité.
Mise à jour du 07/02/2023
Nous continuons nos investigations et à apporter notre soutien à nos clients. Nos efforts sont en priorité :
- d’identifier nos clients impactés sur nos réseaux afin de leur fournir les informations les plus précises et appropriées pour les aider à remettre leurs systèmes en marche.
- identifier les clients potentiellement vulnérables afin de garantir une mitigation des risques adéquate dans les meilleurs délais en cas d’une nouvelle vague d’attaques similaires.
Plusieurs chercheurs en sécurité semblent avoir trouvé un lien entre le code source du ransomware Babuk divulgué en septembre 2021. Le même algorithme de chiffrement (Sosemanuk) est utilisé dans les deux cas, mais la structure du code semble légèrement différente.
En plus de la procédure de récupération décrite précédemment, nous avons noté que le processus de chiffrement n’impacte qu’une faible quantité de données à l’intérieur du fichier. Selon le système d’exploitation de votre machine virtuelle et le type de système de fichiers, vous pouvez être en mesure de récupérer des données avec des outils de récupération de données, au moins partiellement. Attention, ces outils peuvent endommager de manière irréversible le fichier, nous vous recommandons donc de copier les fichiers de la VM sur un autre emplacement pour protéger les données avant d’essayer toute opération de récupération.
Nous sommes également en train de référencer une liste d’entreprises qui peuvent vous aider à récupérer vos données et à reconstruire vos systèmes. La liste des sociétés est disponible auprès du support OVHcloud.
Nous rappelons également à nos clients agissant en qualité de responsable de traitement de données à caractère personnel qu’ils pourraient avoir des obligations légales de notification aux autorités en cas d’incident de sécurité. Assurez-vous d’avoir déclaré l’incident aux autorités compétentes dans les délais impartis.
Vous trouverez ci-dessous les procédures de déclaration pour les violations de bases de données pour les pays principalement touchés et les sites web du CERT aussi. Vérifiez auprès de votre service juridique ou de votre conseiller juridique pour vous assurer que vous avisez l’organisme approprié selon votre statut.
Pour les responsables de traitement de données à caractère personnel:
- France: https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles
- Italie: https://servizi.gpdp.it/databreach/s/
- Belgique: https://www.autoriteprotectiondonnees.be/professionnel/actions/fuites-de-donnees-personnelles
- Espagne: https://www.aepd.es/es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/brechas-de-datos-personales-notificacion
- Pologne : https://uodo.gov.pl/pl/501/2278
- UK: https://ico.org.uk/for-organisations/report-a-breach/
- Allemagne: https://formulare.bfdi.bund.de/lip/form/display.do?%24context=E72B6A6366642AE42118
- Portugal: https://www.cnpd.pt/databreach/
- Quebec: https://www.cai.gouv.qc.ca/incident-de-confidentialite-impliquant-des-renseignements-personnels/aviser-commission-et-personnes/
CERT:
- France: https://www.cert.ssi.gouv.fr/les-bons-reflexes-en-cas-dintrusion-sur-un-systeme-dinformation/
- Italie: https://cert-agid.gov.it/contatti/
- Belgique : https://www.cert.be/fr/signaler-un-incident
- Espagne: https://www.ccn-cert.cni.es/gestion-de-incidentes/notificacion-de-incidentes.html
- Pologne: https://incydent.cert.pl/#!/lang=en
- UK: https://report.ncsc.gov.uk/
- Canada: https://www.cyber.gc.ca/en/incident-management
- Allemagne: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Reaktion/CERT-Bund/Kontakt/kontakt_node.html
- Portugal: https://www.cncs.gov.pt/pt/certpt/
Références supplémentaires :
https://www.bleepingcomputer.com/news/security/
https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/
https://blogs.vmware.com/security/2023/02/83330.html
https://members.loria.fr/MMinier/static/papers/sosemanuk_08.pdf
Mise à jour du 05/02/2023
Nous continuons à travailler sur l’analyse technique en coordination avec les autorités et la communauté des experts sécurité pour déterminer les marqueurs de l’attaque et comprendre le comportement du malware après la compromission initiale.
Nous avons identifié à ce jour les comportements suivants :
- Le vecteur de compromission est confirmé pour utiliser une faille OpenSLP qui pourrait être CVE-2021-21974 (encore à confirmer). Les logs indiquent que l’utilisateur dcui est impliqué dans le processus de compromission.
- Le chiffrement utilise une clé publique déployée par le logiciel malveillant dans /tmp/public.pem
- Le processus de chiffrement cible spécifiquement les fichiers des machines virtuelles (“.vmdk”, “.vmx”, “.vmxf”, “.vmsd”, “.vmsn”, “.vswp”, “.vmss”, “.nvram”, “*.vmem”)
- Le malware tente d’arrêter les machines virtuelles en tuant le processus VMX pour déverrouiller les fichiers. Cette fonction ne fonctionne pas systématiquement comme prévu, ce qui maintient le verrouillage des fichiers.
- Le malware crée le fichier “argsfile” pour stocker les arguments passés au binaire chiffré (nombre de Mo à sauter, nombre de Mo dans le bloc de chiffrement, taille du fichier)
- Aucune exfiltration de données n’a été constatée.
Dans certains cas, le chiffrement des fichiers peut partiellement échouer, ce qui permet de récupérer les données. Enes Sönmez (@enes_dev), un chercheur turc en sécurité, a documenté la procédure de récupération des fichiers VMDK. La procédure est décrite sur son blog (https://enes.dev/). Nous avons testé cette procédure ainsi que de nombreux experts en sécurité avec succès sur plusieurs serveurs impactés. Le taux de réussite est d’environ 2/3. Sachez que suivre cette procédure nécessite de fortes compétences sur les environnements ESXi. Utilisez-le à vos propres risques et demandez l’aide d’experts pour vous aider.
Dans la version précédente du post, nous avions supposé que l’attaque était liée au ransomware Nevada, ce qui était une erreur. Aucun élément ne peut nous conduire à attribuer cette attaque à un groupe particulier à l’heure qu’il est. L’attribution est une activité souvent hasardeuse et nous laissons les chercheurs en sécurité tirer leurs propres conclusions.
ESXi OS ne peut être installé que sur des serveurs bare metal. Nous avons lancé plusieurs initiatives pour identifier les serveurs vulnérables, en nous appuyant sur nos logs d’automatisation pour détecter l’installation d’ESXI par nos clients.
Les moyens d’action sont limités, car nous n’avons aucun accès logique aux serveurs de nos clients. Pour les hôtes bare metal identifiés :
- Nous avons envoyé des emails vendredi après-midi pour avertir les clients du risque et leur fournir des informations pour réduire les risques
- Nous avons bloqué le port OpenSLP (427) entre Internet et les serveurs avec ESXI installé. Le client peut désactiver cette règle de filtrage dans son interface de gestion si l’utilisation du port 427 est requise pour une raison quelconque.
Nous avons lancé le scan pour identifier les hôtes compromis, en testant la présence de la page web et/ou de la bannière ssh spécifiant que l’hôte a été compromis pour prévenir les clients impactés.
Notre équipe support est pleinement mobilisée pour aider nos clients à protéger leurs systèmes et les aider à se relever s’ils sont impactés par l’attaque.
Références supplémentaires :
https://www.cert.ssi.gouv.fr/alerte/CERTFR-2023-ALE-015/
https://enes.dev/
https://straightblast.medium.com/my-poc-walkthrough-for-cve-2021-21974-a266bcad14b9
Premières analyses et recommandations au 03/02/2022
L’attaque vise principalement des serveurs ESXi de version antérieure à la 7.0 U3i, semble-t-il via le port OpenSLP (427).
Pour vérifier votre version d’ESXi, veuillez vous référer à la page de votre serveur dans votre interface client pour identifier la version déployée sur le serveur, ou à l’interface ESXi sur le système lui-même.
À ce jour, nous pouvons formuler les recommandations suivantes concernant nos services :
Pour les clients Bare Metal utilisant ESX-i, nous recommandons fortement d’agir au plus vite pour :
- désactiver le service Openslpd sur le serveur ou pour restreindre l’accès aux seules adresses IP de confiance (https://kb.vmware.com/s/article/76372)
- mettre à jour votre ESXi avec les dernier patch de sécurité disponibles
Dans un second temps, assurez-vous que:
- vos données sont sauvegardées;
- seuls les services nécessaires sont actifs et filtrés avec ACL vers une adresse IP de confiance uniquement;
- surveillez votre système pour détecter tout comportement anormal.
Nos clients utilisant Hosted Private Cloud VMware ne sont pas impactés. Concrètement, la SSL gateway permet d’éviter cette typologie d’attaque en bloquant l’accès externe à ce port (OpenSLP 427).
Pour les clients Public Cloud, il n’y a pas de dépendance à ESXi. Ainsi, aucun risque n’est identifié.
Aucun autre produit du catalogue d’OVHcloud n’est menacé par cette campagne de ransomware.
Nous mettrons à jour ce billet de blog avec toute information qui pourrait aider à réduire le risque associé à cette menace.
