La fuite de Docker Hub en 2019 a exposé les jetons de dépôt de 190 000 comptes — le correctif a cassé les autobuilds

Le 25 avril 2019, Docker a découvert un accès non autorisé à une base de données unique de Docker Hub. Les données d'environ 190 000 comptes — un peu moins de 5 % des utilisateurs du Hub — ont pu être exposées : noms d'utilisateur, hachages de mots de passe bcrypt et jetons d'accès GitHub et Bitbucket qui alimentaient la fonction d'autobuild de Docker. Docker l'a divulgué deux jours plus tard par des notifications par courriel et une annonce d'assistance de Kent Lamb, son directeur de l'assistance.

L'exposition des jetons importait bien plus que celle des mots de passe. ZDNet a noté que la plupart des utilisateurs de Docker Hub sont des employés au sein de grandes entreprises, qui construisent automatiquement des images de conteneurs déployées en production. Quiconque détenait ces jetons pouvait accéder à des dépôts de code source privés ou, pire, modifier discrètement les Dockerfiles qui construisent les logiciels de production. Docker lui-même ne pouvait pas dire si l'intrus avait téléchargé quoi que ce soit — seulement que l'accès « pouvait avoir été exposé ».

La réponse de Docker était la seule sûre, et elle était perturbatrice par conception : réinitialiser les mots de passe exposés, révoquer tous les jetons GitHub et Bitbucket concernés et dissocier les dépôts. Les utilisateurs devaient reconnecter leurs dépôts et auditer leurs journaux de sécurité GitHub et Bitbucket à la recherche de signes d'utilisation abusive. Sur les propres forums de Docker, des utilisateurs ont signalé l'apparition inattendue de clés de déploiement « Docker Cloud Build » dans leurs dépôts GitHub au gré des remous des intégrations révoquées, et ont demandé en vain comment savoir si leur compte avait réellement fait partie des 190 000.

Docker n'a jamais identifié publiquement l'intrus ni confirmé une quelconque exfiltration. Il a déclaré que les images officielles n'étaient pas affectées et a déployé des mesures de sécurité supplémentaires pour garantir leur intégrité. Le dommage durable a été pour la confiance : le registre que l'écosystème des conteneurs considère comme une infrastructure de base avait montré qu'une intrusion y donne à un attaquant les clés du code source des clients, et pas seulement de leurs identifiants.

Tous les mots de passe concernés réinitialisés ; les jetons GitHub/Bitbucket de chaque autobuild révoqués et les dépôts dissociés — les builds sont restés cassés jusqu'à ce que chaque propriétaire reconnecte son dépôt

Des jetons OAuth de longue durée vers GitHub et Bitbucket résidaient dans une seule base de données opérationnelle du Hub, de sorte qu'une seule intrusion exposait les pipelines de code des clients, et pas seulement leurs identifiants.

Docker Hub était devenu le registre public de facto de tout l'écosystème des conteneurs, si bien que son rayon d'impact était celui de l'industrie, et non celui d'un seul fournisseur.

Docker n'a pas pu déterminer si des données avaient été téléchargées, laissant environ 190 000 équipes de sécurité supposer le pire et auditer manuellement leurs dépôts.

Les comptes exposés n'étaient pas des utilisateurs ordinaires mais des opérateurs d'autobuild en entreprise, ce qui faisait de l'exposition des identifiants un risque actif pour la chaîne d'approvisionnement plutôt qu'une simple réinitialisation de mot de passe de routine.

Un registre que tout le monde traite comme une infrastructure est aussi un cache d'identifiants en amont. Des jetons de contrôle de source de longue durée dans une seule base de données opérationnelle ont transformé une brève intrusion en un audit à l'échelle de l'industrie.

Docker a réinitialisé les mots de passe concernés, révoqué les jetons d'autobuild et dissocié les dépôts, et a demandé aux clients de vérifier leurs journaux GitHub et Bitbucket à la recherche d'accès inattendus. Les images officielles ont été déclarées intactes, avec des mesures d'intégrité supplémentaires ajoutées. Aucune exfiltration n'a jamais été confirmée et aucun attaquant n'a été nommé publiquement. L'incident est devenu une référence permanente dans les conseils de sécurité de la chaîne d'approvisionnement pour garder les identifiants entre CI et contrôle de source de courte durée et à portée étroite.