Docker Hub : des milliers d'images contiennent des clés privées ou d'API

Des clés pas si privées

Docker Hub : des milliers d’images contiennent des clés privées ou d’API

Docker Hub : des milliers d'images contiennent des clés privées ou d'API

Abonnez-vous pour tout dévorer et ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

Docker et la conteneurisation se sont petit à petit imposés dans le milieu du développement et de l'administration de systèmes. Mais des chercheurs allemands tirent le signal d'alarme : en analysant des milliers d'images issus de Docker Hub, ils ont découvert que 9 % contenaient des clés privées ou des clés d'API.

Des chercheurs de l'École supérieure polytechnique de Rhénanie-Westphalie ont révélé [PDF], lors de la conférence scientifique Asia Computer and communications Security qui se tenait la semaine dernière, que des milliers de conteneurs d'images hébergés sur Docker Hub stockaient des informations qui auraient dû rester confidentielles.

Les chercheurs ont contacté 1 181 mainteneurs des images Docker concernées pour leur faire part de leur découverte problématique, en retrouvant leurs emails via les variables des Dockerfiles ou leurs comptes Gravatar liés à Docker Hub. Quelques heures après, ils avaient reçu plus de 30 réponses d'utilisateurs expliquant être en cours de correction des images ou les informant que l'image n'était plus utilisée.

Comme nous l'expliquions dans notre dossier sur le sujet il y a plus de deux ans, le déploiement de services via l'utilisation de « conteneurs » est devenu monnaie courante, notamment via l'outil Docker développé il y a une dizaine d'années et son registre Docker Hub qui permet d'héberger n'importe quelle image créée par cet outil.

Notre dossier sur les conteneurs :

Ce système est très pratique pour déployer un service sur une machine sans se préoccuper de ce qui tourne dessus et, finalement, industrialiser un peu plus le déploiement. Mais si le conteneur est mal généré, il peut contenir des informations qui ne devraient pas être divulguées, comme des clés privées SSH, SSL, d'authentification IoT (Internet of things) ou encore des clés API pour se connecter à des services comme Twitter, Facebook ou Slack.

Dans leur conclusion, les chercheurs rappellent qu' « en matière de sécurité, le partage de clés secrètes ou l'utilisation de clés déjà compromises rompt les promesses, par exemple en matière d'authentification ou de contrôle d'accès. Par conséquent, les secrets cryptographiques ne doivent pas être inclus dans les images de conteneurs accessibles au public ».

Plus de 50 000 clés privées et 3 000 clés API fuitées

Markus Dahlmanns et trois de ces collègues, à l'origine de cette étude, ont analysé 1 647 300 couches de 337 171 images hébergées par Docker Hub et de 8 076 autres images provenant de registres privés. 8,5 % d'entre elles contenaient des informations secrètes (9 % des images issues de Docker Hub et 6,3 % de celles issues de registres privés). Au total, ils ont trouvé 52 107 clés privées et 3 158 clés API.

Pour repérer ces informations secrètes dans les images Docker, ils ont utilisé des expressions régulières établies et reconnues par la communauté scientifique pour identifier clés privées et d'API.

Des clés API pour accéder au Cloud

La plupart des clés API (2 920) permettent d'accéder à des fonctionnalités de services de cloud computing comme AWS, Alibaba, Github, MailChimp, Heroku, Google Cloud, Teams, IBM Cloud Identity Service, etc. En possédant une telle clé, suivant le service utilisé, il est possible de le paramétrer, de créer de nouvelles clés API, de reconfigurer le DNS utilisé, d'accéder à des emails ou SMS, de contrôler les appels téléphoniques, etc.

Une petite partie des clés API (213) fuitées concerne des médias sociaux et 25 clés API concernent des services financiers comme MWS (Marketplace Web Service) d'Amazon, Stripe ou Paypal Braintree. Les clés d'API des IoT semblent épargnées, mais il faut rappeler que les chercheurs n'ont analysé qu'une petite partie des images accessibles sur Docker Hub. Il n'est donc pas impossible que des clés d'API d'IoT trainent dans un ou des dockers hébergés par le site.

Des clés privées massivement pour SSH

Pour savoir à quels services correspondaient les clés privées, les chercheurs ont regardé dans quelles arborescences elles se situaient. Une majorité d'entre elles étaient dans /etc/ssh, signant une très grande proportion (53 %) de clés privées compromises d'hôtes SSH. Une autre grande partie (11 %) se situe dans /etc/ssl, suggérant des clés compromises pour l'authentification via le protocole TLS.

Si une majorité provient donc de ces deux protocoles, « plus inquiétant encore », expliquent-ils, « nous avons trouvé des clés dans /etc/pki, ce qui indique que les clés incluses sont associées à une infrastructure à clé publique (PKI) et donc potentiellement destinées à offrir des services à un plus grand nombre d'utilisateurs. En outre, /iotx contient des clés privées utilisées en relation avec l'IoT et, d'après les noms des dépôts, pour l'authentification à l'aide de protocoles IoT tels que CoAP et MQTT ».

Les chercheurs expliquent que des attaquants pourraient, en utilisant ces clés privées, accéder aux données confidentielles transmises par les objets connectés et même les modifier, ce qui pourrait engendrer des problèmes physiques concrets.

Enfin, ils ont aussi trouvé, en petite quantité (2 %), des paires de clés SSH dans /root/.ssh, ce qui permettrait de prendre le contrôle de serveurs SSH.

Markus Dahlmanns et ses collègues expliquent que si la plupart des clés API sont insérées dans le conteneur via l'ajout de fichier (copie du fichier venant du système de l'utilisateur), les clés privées sont généralement ajoutées par l'exécution d'une commande (ssh-keygen ou l'installation du paquet ssl-cert, notamment)  dans le fichier Dockerfile créant l'image.

« Bien que bénéfique lorsqu'il est exécuté sur du matériel réel où chaque ordinateur génère sa propre clé, dans les images de conteneurs, ce processus conduit automatiquement à la compromission de secret et potentiellement à un grand nombre de conteneurs dont l'authenticité est compromise », expliquent les chercheurs dans leur conclusion.

22 082 certificats compromis

En tout, ils ont trouvé que 22 082 certificats étaient compromis par le partage de ces clés. Si une grande majorité d'entre eux (61 %) sont des certificats autosignés, plus de 7 500 sont des certificats privés émis par une autorité de certification (private CA-signed) et 1 060 des certificats publics émis par une de ces autorités (public CA-signed  certificates).

Heureusement, le temps de vie des certificats est limité, ce qui permet de réduire les risques. Mais, au moment de la publication de leur étude, 141 certificats publics « CA-signed », 4 970 privés « CA-signed » et 10 629 certificats autosignés étaient encore valides. 

En conclusion, les chercheurs insistent sur le fait que la fuite de clés dans les conteneurs Dockers constitue « une menace réelle et non négligeable » et qu'une sensibilisation des créateurs et utilisateurs des images est nécessaire. Ils suggèrent que le paradigme Docker pourrait intégrer des outils de recherche de ce genre de fuites.

Commentaires (13)


Il me semble qu’un travail similaire avait été faire sur Github. Mais je crois que les chiffres étaient plus faibles (9% c’est énorme)


Oui, d’ailleurs, je ne le précise pas dans l’article mais les chercheurs ont essayé de recouper pour vérifier que ça venait pas de dépôts github mais ça ne semble pas être le cas.


C’est entre autre pour ça qu’on voie de plus en plus d’outil d’analyse dans le CI/CD pour éviter ce genre de fuite par inattention, ou juste méconnaissance.
C’est si vite fait de prendre un raccourcis pour “gagner du temps”, je ferais proprement plus tard, et on oublie.


Le pire est quand on justifie ça par “on a toujours fait comme ça”.
La précipitation, le pire ennemi du dev’.


Arcy

Le pire est quand on justifie ça par “on a toujours fait comme ça”.
La précipitation, le pire ennemi du dev’.


Perso j’aurais dit le copié/collé, mais j’avoue que ça peut se débattre xd (puis l’une peut provoquer l’autre au demeurant haha).


La détection de secrets est effectivement un prérequis, mais hélas tellement oublié ou ignoré.



Parfois c’est aussi une simple mauvaise pratique, celle que je vois souvent : git add -A. Ou comment ajouter à son historique des choses sans aucune maîtrise.


Cela ne m’étonne pas du tout, et quand je m’énerve contre les dev, je suis le méchant 😂😂😂



[…] en retrouvant leurs emails via […] leurs comptes Gravatar liés à Docker Hub.




Je me demande comment ils ont converti un Gravatar (apparaissant comme un MD5) en email. Ils ont tenté une attaque par force brute ? (Cela ne semble pas précisé dans leur article.)



(reply:2143350:Sans intérêt)




Je crois qu’il fallait plutôt comprendre qu’ils les ont contactés soit par email soit par message privé vers leur compte Gravatar.



(quote:2143350:Sans intérêt)
Je me demande comment ils ont converti un Gravatar (apparaissant comme un MD5) en email. Ils ont tenté une attaque par force brute ? (Cela ne semble pas précisé dans leur article.)




Le lien pour afficher un gravatar sur un site quelconque est l’adresse couriel d’un compte wordpress. Ce sont ces adresses qui son dans la nature dans le cas présent.


Tu veux dire qu’on peut contacter un compte Gravatar chez WordPress en connaissant uniquement le MD5 de l’adresse email ?



(quote:2143406:Sans intérêt)
Tu veux dire qu’on peut contacter un compte Gravatar chez WordPress en connaissant uniquement le MD5 de l’adresse email ?




Non, je dit que ce qu’ont trouvé les chercheurs ne sont pas des md5 mais des adresses courriels WordPress.



Avec jitsi meet par exemple, c’est mon adresse WordPress qui me sert pour ajouter mon avatar.
C’est en fait une adresse dédiée à cette fonction.


… nous sommes en 2023 … et une trop grande proportion de ceux qui jouent à créer des containers n’ont pas le début du commencement des bonnes pratiques pour le faire…



ça me fait penser aux idiots sur linkedin qui postent des choses comme “ne cherchez pas à tout prix à embaucher la personne la plus intelligente, mais cherchez plutôt à embaucher celle qui fait le taf” et en énumérant les soft skills qui vont bien en entreprise sans évoquer une seule fois le point vraiment important: la compétence… “faire le taf” est un élément aux propriétés qualitatives très variables, surtout en informatique


Fermer