Chainstack : une fuite de données client liée à des outils d'administration exposés
Chainstack a publié un rapport d'incident enrichi après la faille de sécurité qu'il avait révélée le 3 novembre. Le document, complété par une section technique datée du 10 novembre, décrit une intrusion survenue en octobre et liée à des défaillances de configuration et de contrôle d'accès. L'entreprise dit n'avoir trouvé aucune preuve d'une exploitation d'une vulnérabilité logicielle.
Des contrôles d'accès défaillants
Selon Chainstack, l'attaquant est entré via une instance Grafana de développement utilisant encore des identifiants administrateur par défaut inchangés. Un serveur d'outils non authentifié, doté de larges permissions Kubernetes, a ensuite fait partie du chemin d'accès. Des identifiants machine reliaient aussi les environnements de développement et de production.
Le rapport met surtout en avant la portée d'un compte après la première connexion. Un service de test discret peut devenir sensible s'il peut joindre des systèmes critiques ou disposer de privilèges qui dépassent son rôle initial.
Quelles données sont concernées
Le rapport mentionne comme potentiellement exposés des noms de comptes, des informations d'organisation, des adresses e-mail et des hash de mots de passe. Chainstack considère aussi les identifiants de nœud comme exposés, même s'il n'a trouvé aucune preuve qu'ils aient été lus.
L'entreprise demande aux clients de changer leurs mots de passe, de faire tourner les identifiants de nœud et de régénérer les clés API de la plateforme lorsqu'elles ont été utilisées. Un hash de mot de passe et un jeton d'accès actif ne posent pas le même problème : le premier représente un mot de passe, tandis que le second peut autoriser directement des requêtes.
Le rapport insiste donc sur la nécessité de préciser les types d'identifiants touchés. Une consigne générale de changement de mot de passe peut laisser des zones d'ombre pour les points de terminaison applicatifs, les tâches automatisées et les intégrations de services.
La rotation des identifiants doit aller au bout
La documentation de gestion des nœuds de Chainstack décrit un processus de rotation par étapes. De nouveaux identifiants sont générés tandis que les anciens restent actifs, puis les applications migrent vers les remplaçants avant la désactivation des précédents.
Cette période de chevauchement réduit le risque d'interrompre un service en fonctionnement pendant la mise à jour des applications. Mais la responsabilité reste de terminer la migration : générer un remplacement seul laisse l'ancien moyen d'accès disponible.
La documentation précise aussi qu'une rotation de nœud ne modifie pas un jeton d'authentification multichain. Un suivi utile consisterait donc à vérifier quelles applications ont migré et à quel moment les anciens identifiants ont été désactivés.
Un problème de conception déjà connu
La documentation de sécurité de Grafana indique que des services présents sur son réseau local peuvent être accessibles via son proxy de source de données. Elle recommande notamment de limiter les destinations autorisées et d'utiliser des règles de pare-feu pour restreindre l'accès aux services internes sensibles.
Ces mesures concernent à la fois ce qu'un outil peut atteindre et qui peut s'y connecter. Chainstack estime que son compte rendu enrichi donne désormais plus de détails aux clients pour évaluer la situation et vérifier si les changements d'accès ont bien été finalisés.
