Des attaquants ont exploité une vulnérabilité de la plateforme VMmanager 6 d'ISPsystem pour copier des fichiers depuis les serveurs virtuels de clients du fournisseur d'hébergement russe FirstVDS. Selon les déclarations de l'entreprise, les données dérobées comprenaient des mots de passe, des identifiants de services cloud, des fichiers de configuration et des portefeuilles de cryptomonnaies (rapporté par The Record).
FirstVDS a découvert l'intrusion samedi et l'a annoncée au cours du week-end. L'entreprise indique que seule une partie de son infrastructure a été touchée, mais elle n'a pas communiqué de décompte des clients, des serveurs ou des personnes concernées.
FirstVDS avertit que les clients qui reçoivent une notification de violation de données doivent considérer que les données stockées sur leurs serveurs ont été dérobées. Ils doivent changer leurs mots de passe et remplacer les identifiants d'accès exposés, sans se fier à la disponibilité continue ou au fonctionnement apparemment normal de leurs machines virtuelles.
Les attaquants ont monté des disques virtuels sans perturber les serveurs
VMmanager 6 est une plateforme de gestion de la virtualisation d'ISPsystem, que les hébergeurs utilisent pour administrer des machines virtuelles réparties sur plusieurs serveurs physiques.
Selon FirstVDS, un logiciel malveillant a détourné la plateforme de gestion pour monter les disques des serveurs virtuels des clients en lecture seule. Les attaquants ont ainsi pu copier des fichiers sans en modifier le contenu ni interrompre les services en cours. Les données extraites ont ensuite été envoyées vers une infrastructure contrôlée par les attaquants.
FirstVDS affirme que les machines virtuelles elles-mêmes n'ont pas été compromises directement et qu'il n'y avait « aucune trace » de l'attaque sur les serveurs touchés, qui ont continué à fonctionner normalement. Cette description ne réduit pas l'impact sur la confidentialité : un montage en lecture seule peut laisser les charges de travail des clients en fonctionnement tout en exposant des identifiants et d'autres fichiers sensibles.
Le fournisseur propose des serveurs en Russie, aux Pays-Bas et au Kazakhstan. Le compte rendu ne précise pas quels emplacements d'hébergement faisaient partie de la portion touchée de l'infrastructure.
La vulnérabilité n'est pas encore entièrement corrigée, selon FirstVDS
FirstVDS a désactivé l'accès externe au système de gestion vulnérable et bloqué les communications avec le serveur des attaquants. L'entreprise indique également qu'ISPsystem a publié plusieurs correctifs après l'intrusion, dont une mise à jour déployée dans la nuit de lundi.
Cependant, FirstVDS signale que la vulnérabilité n'était pas encore entièrement résolue. ISPsystem conseille aux opérateurs de ne pas rétablir l'accès à l'interface de gestion tant que des mises à jour de sécurité supplémentaires ne sont pas disponibles.
Lundi, FirstVDS fonctionnait toujours sous restrictions, notamment avec une disponibilité réduite de certaines fonctions de VMmanager. Les versions concernées de VMmanager 6 et les numéros de build corrigés n'ont pas été identifiés dans les déclarations rapportées, ce qui limite la capacité des administrateurs à évaluer leur exposition à partir d'une simple vérification de version.
Les clients notifiés doivent renouveler les identifiants exposés
La première mesure pour les clients de FirstVDS notifiés est de considérer le contenu des serveurs comme copié. Le changement des mots de passe peut ne pas suffire à lui seul si le serveur stockait d'autres identifiants réutilisables, des secrets de configuration ou des données d'accès cloud. Ces identifiants doivent aussi être remplacés dans les services où ils restent valides.
Les fichiers de portefeuilles de cryptomonnaies et les données de configuration demandent une attention particulière, car leur copie peut créer des risques en dehors du serveur virtuel concerné. Les déclarations rapportées ne permettent pas d'établir si les informations dérobées ont déjà servi à des attaques ultérieures.
Les hébergeurs qui utilisent VMmanager 6 doivent suivre la consigne d'ISPsystem : maintenir l'interface de gestion inaccessible en attendant de nouvelles mises à jour de sécurité. Rétablir l'accès externe avant que le fournisseur ne considère le problème entièrement traité pourrait exposer de nouveau cette couche d'administration vulnérable.
