Les clients de Zeabur doivent s’atteler à deux tâches urgentes : remplacer les identifiants exposés et transférer leurs applications avant l’arrêt de la plateforme.
La plateforme d’hébergement pour développeurs a révélé une intrusion survenue les 14 et 15 octobre, qui a exposé les informations de 321 810 comptes ainsi que plus de 3,2 millions d’enregistrements de variables d’environnement. L’incident fait suite à une autre faille survenue en août, et Zeabur a annoncé son intention de cesser ses activités d’ici fin décembre.
Pour les équipes de sécurité, le problème ne se limite pas aux informations des comptes. Les identifiants stockés auprès d’un fournisseur de déploiement peuvent permettre à des attaquants d’accéder à des bases de données, à des ressources cloud et à des services d’IA payants auprès d’autres fournisseurs.
Ce à quoi l’attaquant a accédé
Le rapport préliminaire de Zeabur confirme que l’attaquant a lu 3 218 965 enregistrements de variables d’environnement, comprenant leurs noms et leurs valeurs, ainsi que des informations de compte telles que des adresses e-mail, des noms d’utilisateur et des numéros de téléphone.
Les variables d’environnement contiennent les paramètres des applications et peuvent renfermer des mots de passe ou des clés d’API. Ce nombre d’enregistrements ne signifie pas que 3,2 millions de clients distincts ou d’identifiants utilisables ont été exposés. Zeabur a indiqué que les variables transférées exclusivement vers les propres serveurs des clients après août n’étaient pas concernées par cette exposition de la base de données, même si des hôtes compromis pouvaient toujours les exposer.
Zeabur a également confirmé un accès root à 101 serveurs Google Cloud dédiés utilisés par 92 utilisateurs. Des clés SSH contrôlées par l’attaquant ont été ajoutées à 50 serveurs, lui permettant de revenir après l’intrusion initiale.
Les titulaires de comptes doivent se méfier des campagnes d’hameçonnage ciblées et prendre des mesures pour vérifier si leurs informations personnelles ont été exposées. Les propriétaires d’applications doivent également déterminer à quels services externes leurs identifiants stockés pourraient donner accès.
Le risque rappelle celui de la récente exposition de clés d’API d’OpenCode : un identifiant dérobé sur une plateforme de développement peut autoriser directement des opérations auprès d’un autre fournisseur.
Des identifiants non renouvelés ont laissé l’accès ouvert
Zeabur a indiqué que des identifiants d’administrateur à longue durée de vie étaient stockés en clair et que son interface de gestion des clusters partagés était accessible depuis l’internet public. Certains jetons d’administrateur n’avaient pas été renouvelés depuis janvier 2024 et avaient été oubliés lors de la réponse à l’incident d’août.
L’entreprise n’a pas confirmé comment l’attaquant avait initialement obtenu ces identifiants. Un lien avec la faille d’août reste une hypothèse.
L’incident rappelle l’importance de la segmentation du réseau et de la restriction des accès : le fait de posséder l’identifiant d’un service ne devrait pas fournir de voies d’accès sans restriction vers d’autres systèmes.
L’arrêt de décembre impose une échéance pour la migration
Dans son annonce d’arrêt, Zeabur a fixé deux échéances :
- 1er décembre : les renouvellements de serveurs dédiés s’arrêtent, et les serveurs seront mis hors service à leur date d’expiration respective. Les services exécutés sur des clusters partagés seront mis en pause, mais les clients pourront les redémarrer manuellement pour sauvegarder leurs données.
- 31 décembre : tous les serveurs dédiés et les clusters partagés cessent de fonctionner.
Les clients doivent planifier leur migration en fonction de la date d’expiration de leur serveur. L’entreprise n’a pas encore fixé la date de suppression des données, la date limite d’exportation finale ni la date de fermeture du support.
Ce que les équipes de sécurité doivent faire maintenant
Les priorités immédiates sont la révocation des identifiants, l’investigation et la reprise d’activité. Zeabur invite ses clients à remplacer les identifiants exposés et à reconstruire les serveurs Google Cloud compromis.
Une réponse concrète devrait inclure les mesures suivantes :
- Révoquez les identifiants auprès du fournisseur émetteur. Révoquez et remplacez les clés d’API, les clés cloud, les mots de passe des bases de données ainsi que les clés de signature ou de chiffrement exposés, puis mettez à jour les applications qui en dépendent. Modifier un mot de passe de base de données dans une variable d’environnement ne le modifie pas à l’intérieur de la base de données.
- Examinez l’activité et les coûts. Vérifiez les journaux d’audit des fournisseurs, l’activité des bases de données et les factures des services d’IA pour repérer les accès ou les frais inhabituels.
- Recherchez les accès persistants. Examinez les clés SSH, les comptes, les tâches planifiées et la configuration des services. Un simple changement de mot de passe ne supprimera pas la clé SSH ajoutée par un attaquant.
- Préparez une migration propre. Conservez les journaux pertinents et sauvegardez les données nécessaires avant de reconstruire et de tester les services de remplacement.
Vérifiez la reprise d’activité pour tous les services connectés
Les équipes de sécurité doivent considérer le nettoyage des identifiants et la migration comme deux opérations liées. Le déplacement d’une application peut rétablir sa disponibilité tout en laissant une clé dérobée valide auprès de son fournisseur d’origine. Avant de clore l’incident, vérifiez que les anciens identifiants échouent et que les identifiants de remplacement ne fonctionnent que là où cela est prévu.
Attribuez un responsable à chaque intégration concernée. Cette personne devra documenter les accès permis par l’identifiant, le moment où celui-ci a été révoqué, les journaux examinés et la nécessité éventuelle d’approfondir l’enquête sur des modifications suspectes. Donnez la priorité aux identifiants disposant de droits d’administration, d’un accès à des données sensibles ou d’une capacité importante à engager des dépenses.
Séparez la reprise d’activité de la copie intégrale de l’ancien environnement. Validez le code et la configuration de l’application, restaurez les données nécessaires et vérifiez qu’aucun compte ni mécanisme d’accès non autorisé n’a suivi la charge de travail dans son nouvel environnement.
Pour les organisations qui évaluent d’autres fournisseurs d’hébergement, ce cas soulève des questions concrètes : le fournisseur peut-il identifier chaque identifiant impliqué dans un incident, démontrer que la révocation est complète et fournir des journaux suffisamment détaillés pour enquêter sur l’impact subi par les clients ? Les réponses permettent de déterminer si une garantie de sécurité suffit pour recommencer à faire confiance au service.
À lire aussi : la faille de ConnectWise Cloud Backup montre pourquoi la désactivation des identifiants compromis d’un fournisseur laisse malgré tout aux administrateurs le travail de rechercher les modifications non autorisées et les accès persistants.