Un hôte Docker dont l’API sans authentification est accessible sur Internet n’offre pas simplement une fonction pratique d’administration à distance. Il fournit un chemin distant vers la machine qui exécute les conteneurs. La campagne CARBONATO signalée le 30 septembre rend cette distinction difficile à ignorer : les attaquants utilisent des API Docker Remote exposées pour créer des conteneurs privilégiés, établir une persistance, dérober des identifiants et rechercher d’autres hôtes Docker.

Illustration éditoriale d’un hôte Docker exposé, montrant un chemin d’accès depuis Internet vers le serveur et le plan de contrôle des conteneurs.

L’incident mérite l’attention parce qu’il ne raconte pas fondamentalement l’exploitation d’une nouvelle vulnérabilité de Docker. Il montre plutôt ce qui se passe lorsqu’une interface d’administration est placée sur un réseau non fiable sans barrière d’authentification. Le logiciel malveillant ajoute une charge utile moderne, notamment un framework d’agent IA open source réutilisé, mais la condition qui rend l’attaque possible est plus ancienne et plus simple : toute personne capable d’atteindre le daemon peut lui demander d’effectuer des opérations avec les privilèges de l’hôte.

Pour les équipes qui exécutent Docker sur des serveurs cloud, des machines de build, des hôtes de développement, des services auto-hébergés ou des systèmes en périphérie, la bonne réponse est d’évaluer à la fois l’exposition et une éventuelle compromission. Fermez le chemin sans authentification, déterminez si l’hôte a été utilisé, renouvelez tout ce qu’il pouvait lire, puis examinez les systèmes voisins. Réinstaller un conteneur ou modifier un tag d’image ne suffit pas si l’hôte sous-jacent, ou ses identifiants, peut déjà être contrôlé par un tiers.

Ce que dit réellement le signalement sur CARBONATO

L’avis de l’Agence de cybersécurité de Singapour, publié le 30 septembre, indique que des chercheurs ont identifié une campagne de botnet visant des hôtes Docker dont les API Remote sans authentification étaient exposées à Internet, généralement sur le port TCP 2375. L’avis décrit une campagne qui utilise les fonctions légitimes de Docker pour créer un conteneur privilégié ayant accès au système de fichiers, aux processus et au réseau de l’hôte.

Cette séquence est importante. L’attaquant n’a pas besoin d’exploiter un bug de sécurité mémoire dans Docker Engine si le daemon accepte des requêtes d’administration provenant d’une partie non fiable. Une requête normale pour un administrateur — créer un conteneur, monter un chemin, démarrer un processus ou connecter un réseau — peut donner un contrôle au niveau de l’hôte lorsque l’émetteur n’est pas authentifié et que le daemon dispose de privilèges élevés.

L’avis singapourien indique que la campagne peut établir un accès distant persistant, voler des identifiants et d’autres informations sensibles, puis analyser les réseaux connectés afin de trouver d’autres hôtes Docker exposés. Il n’affirme pas que chaque hôte exposé a été compromis et ne fournit pas non plus d’indicateur universel permettant, à lui seul, de confirmer ou d’écarter un incident. Ces limites comptent. L’avis justifie une enquête sur l’exposition et les journaux ; il ne permet pas d’étiqueter toute installation Docker comme infectée.

Une note de recherche de la Cloud Security Alliance apporte des précisions sur la charge utile. Elle décrit CARBONATO comme un botnet à propagation automatique qui installe un framework d’agent IA open source non modifié, Hermes Agent, puis change sa configuration de persona afin que le framework serve les objectifs des opérateurs. La note indique que les hôtes infectés analysent les plages réseau voisines à la recherche d’autres daemons Docker.

Le choix de la charge utile est inhabituel. Pour les défenseurs, le point essentiel reste toutefois le chemin d’accès. La présence d’un framework IA peut attirer l’attention, mais un attaquant n’a pas besoin d’un agent IA pour transformer un daemon Docker exposé en incident grave. La même exposition administrative pourrait servir au vol d’identifiants, au cryptominage, à des actions destructrices, au relais de trafic, aux déplacements latéraux ou au déploiement d’une porte dérobée classique.

Pourquoi le port 2375 appelle une réponse précise

La documentation de Docker distingue le socket local habituel des connexions réseau distantes. Par défaut, Docker utilise sous Linux et macOS un socket Unix qui n’est pas exposé sur le réseau. L’administration à distance peut plutôt passer par SSH ou par un socket TCP protégé par TLS et une authentification du client.

La documentation de Docker rappelle également la répartition conventionnelle des ports : le TCP 2375 sert normalement aux connexions non sécurisées sans TLS, tandis que le TCP 2376 est généralement associé à TLS. Le numéro ne prouve pas à lui seul une compromission, et utiliser un autre port ne rend pas une API sans authentification sûre. Le port 2375 est simplement un signal de découverte utile, car il indique souvent qu’un daemon Docker a été configuré pour un accès distant en clair.

La question déterminante n’est pas seulement « Le port 2375 est-il ouvert ? ». Il faut demander :

  • Quel processus écoute ?
  • L’écouteur est-il accessible depuis Internet, depuis un vaste réseau d’entreprise ou uniquement depuis un segment d’administration restreint ?
  • Une authentification est-elle exigée et le client est-il correctement autorisé ?
  • Quel daemon Docker, quel compte, quel hôte et quelle charge de travail se trouvent derrière lui ?
  • Les journaux montrent-ils des requêtes que le propriétaire n’a pas effectuées ?

Un service exposé sur Internet peut être dangereux même s’il n’est pas accessible à tout le monde. Un daemon exposé à un réseau interne plat peut rester disponible pour un poste de travail compromis, un appareil de prestataire, un compte de développement ou une autre charge de travail qui ne devrait jamais disposer de privilèges d’administration sur l’hôte. « Il est seulement ouvert dans le VPC » est une description du réseau, pas un modèle d’autorisation.

Le problème fondamental : l’accès à Docker donne accès à l’hôte

Les conteneurs constituent des frontières d’isolation utiles, mais l’accès au daemon Docker est un privilège d’administration. Docker avertit que modifier la liaison du daemon vers un socket TCP, ou accorder l’accès au socket Unix via le groupe docker, peut permettre à un utilisateur d’obtenir un accès de niveau root à l’hôte. Cet avertissement passe facilement inaperçu lorsqu’une équipe dépanne un système de build ou cherche à simplifier le développement à distance.

Un conteneur créé avec des privilèges élevés peut voir ou modifier des ressources de l’hôte. Sans même reproduire une séquence d’attaque, l’implication défensive est directe : traitez les identifiants du daemon Docker et l’accès à son socket comme des identifiants root. Ils appartiennent à la même catégorie de risque que les clés d’administrateur cloud, les interfaces de gestion d’hyperviseur et l’accès au plan de contrôle Kubernetes.

C’est aussi pourquoi supprimer un conteneur suspect constitue à lui seul une faible mesure de confinement. Si un attaquant a eu accès au niveau du daemon, il a pu lire des variables d’environnement, monter des répertoires de l’hôte, inspecter d’autres conteneurs, copier des fichiers de configuration, modifier des mécanismes de démarrage, créer des comptes supplémentaires ou récupérer des identifiants sur l’hôte. Le conteneur visible peut n’être qu’un artefact parmi d’autres d’une compromission plus large.

Le même principe vaut pour les runners CI. Un runner de build qui a accès à un socket Docker privilégié peut exposer du code source, du matériel de signature, des identifiants de paquets, des jetons cloud et des permissions de déploiement. Un ordinateur portable de développeur qui monte un socket Docker peut exposer des fichiers locaux et l’environnement de l’hôte. Une API distante ajoutée par commodité peut donc relier un workflow de conteneurs aux identités et à l’infrastructure qui l’entourent.

Ce que les administrateurs doivent faire en premier

La première réponse doit réduire la portée de l’attaquant sans détruire les éléments de preuve.

1. Identifier chaque daemon Docker exposé sur le réseau

Commencez par un inventaire fiable, plutôt que de vous en remettre à la mémoire. Examinez les groupes de sécurité cloud, les pare-feu des hôtes, les équilibreurs de charge, les routes VPN, les enregistrements de découverte de services, la configuration des hôtes de conteneurs, les unités systemd, les fichiers de configuration du daemon, les modèles d’orchestration et les dépôts d’infrastructure as code.

Recherchez les écouteurs Docker sur les ports TCP 2375 et 2376, mais aussi les ports personnalisés et les liaisons telles qu’un daemon à l’écoute sur toutes les interfaces. Examinez les environnements de production et hors production. Les hôtes de développement sont souvent davantage exposés, moins surveillés et connectés à des réseaux qui contiennent des identifiants précieux.

Les recommandations de la CISA sur la réduction de l’exposition Internet préconisent d’améliorer la visibilité sur les actifs accessibles depuis Internet et de réduire les expositions inutiles. La même méthode s’applique à l’exposition interne : établissez ce qui est joignable, depuis où et pour quelle raison métier. Un actif absent de l’inventaire ne peut pas être corrigé, surveillé ou examiné de manière fiable.

Si un daemon sans authentification est exposé, restreignez immédiatement son accès au niveau réseau tout en conservant les journaux et les traces de changement. L’objectif d’urgence est d’empêcher de nouvelles connexions sans authentification. Ne supposez pas qu’une modification du pare-feu prouve que l’hôte est sain ; elle change seulement les personnes ou les systèmes qui peuvent l’atteindre.

2. Supprimer l’accès distant en clair

Les recommandations officielles de Docker pour protéger le socket du daemon conseillent d’utiliser SSH ou TLS pour sécuriser l’accès distant. SSH peut être un choix pratique pour les opérations, car il relaie les requêtes vers le socket Unix distant tout en s’appuyant sur le modèle d’authentification et d’autorisation déjà présent sur l’hôte.

Lorsqu’un accès TCP est réellement nécessaire, utilisez un TLS mutuellement authentifié avec une autorité de certification contrôlée, protégez les clés privées, limitez les réseaux sources et journalisez les activités d’administration. Un service chiffré par TLS mais dépourvu d’authentification reste un problème d’autorisation. Le chiffrement protège les communications contre l’observation et la modification ; il ne décide pas si un client doit pouvoir créer des conteneurs privilégiés.

Préférez un chemin de gestion privé à une écoute publique. Appliquez le principe du moindre privilège aux identités qui peuvent administrer le daemon, séparez l’administration humaine de l’automatisation et évitez de distribuer un certificat client largement réutilisable aux jobs de build ou à plusieurs équipes. Un certificat client qui accorde un accès Docker sans restriction doit être traité comme un identifiant root de l’hôte.

Ne résolvez pas une exposition en changeant uniquement le numéro de port. Les groupes de sécurité, les pare-feu des hôtes, le routage, l’authentification et l’autorisation doivent tous correspondre à la frontière d’administration prévue.

3. Préserver et examiner les éléments de preuve

Pour un hôte potentiellement exposé, conservez les journaux système, pare-feu, cloud, Docker, orchestration et identité pertinents avant de renouveler les secrets ou de le reconstruire. Déterminez la période pendant laquelle le daemon était joignable et comparez-la au signalement de la campagne ainsi qu’à votre propre télémétrie.

Les questions utiles comprennent notamment :

  • Des requêtes inattendues ont-elles été envoyées aux points d’accès de l’API Docker ?
  • Des conteneurs ont-ils été créés, démarrés, arrêtés ou supprimés en dehors des fenêtres normales de déploiement ?
  • Une nouvelle image, un nouveau registre, un nouveau réseau, un nouveau volume ou un nouveau secret est-il apparu ?
  • Des chemins de l’hôte ont-ils été montés de manière inattendue dans des conteneurs ?
  • Un conteneur a-t-il fonctionné avec des privilèges élevés, le réseau de l’hôte ou un accès à des répertoires sensibles ?
  • De nouveaux processus, utilisateurs, tâches planifiées, services, clés SSH ou entrées de démarrage ont-ils été créés sur l’hôte ?
  • L’hôte a-t-il établi des connexions sortantes inhabituelles, notamment vers une infrastructure de commande et contrôle ou des registres inconnus ?
  • D’autres hôtes du même réseau ont-ils montré peu après des tentatives de connexion liées à Docker ?

L’objectif n’est pas de rechercher un nom de fichier magique. Les attaquants peuvent supprimer des conteneurs, renommer des processus, utiliser des outils légitimes ou déployer une autre charge utile. Corrélez l’activité de l’API avec l’exécution des processus, les flux réseau, l’accès aux registres, les événements d’audit cloud et les journaux du fournisseur d’identité.

Si l’hôte contient des charges de travail sensibles ou si les journaux ne permettent pas d’établir ce qui s’est passé, isolez-le et appliquez le processus de réponse aux incidents de l’organisation. Reconstruisez-le depuis une image fiable lorsque l’intégrité de l’hôte est incertaine. Une reconstruction est plus crédible lorsque les identifiants, la configuration et les artefacts de déploiement ont également été examinés, au lieu d’être recopiés intégralement depuis le système potentiellement compromis.

4. Renouveler les secrets selon leur niveau d’autorité

Partez du principe que les secrets lisibles par le daemon Docker, l’hôte, les volumes montés, les variables d’environnement, les couches d’image ou les processus en cours ont pu être exposés. Donnez la priorité aux identifiants en fonction de ce qu’ils permettent de faire, et non de l’endroit où ils étaient stockés.

Il peut s’agir de clés d’accès cloud, de jetons CI, de jetons de gestion de code source, d’identifiants de registre, de mots de passe de base de données, de clés SSH, de clés de signature, de secrets de webhook, de jetons de comptes de service et d’identifiants intégrés dans les fichiers de déploiement. Révoquez-les ou renouvelez-les depuis un chemin d’administration fiable. Vérifiez si les nouveaux identifiants ont été utilisés de façon inattendue après leur émission.

Un renouvellement sans révocation est incomplet si l’ancien identifiant reste valide. Un renouvellement sans examen des journaux ne permet pas de savoir si un attaquant a déjà utilisé le secret pour accéder à un autre service. Un renouvellement sans cartographie des dépendances peut interrompre la production et doit donc être coordonné, mais la gêne opérationnelle ne justifie pas de laisser actifs des identifiants à forte valeur après une exposition crédible.

Examinez aussi les secrets qui n’étaient pas directement stockés sur l’hôte mais qui étaient accessibles par l’intermédiaire de son identité. Un rôle d’instance cloud compromis, une identité de workload ou un compte de service CI peut étendre l’incident bien au-delà d’un seul serveur Docker.

À quoi ressemble une architecture sûre

Une configuration Docker défendable possède généralement un chemin d’administration étroit et une raison explicite pour chaque exception.

Pour l’administration locale, conservez le socket Unix par défaut et protégez-le avec les contrôles d’accès de l’hôte. Limitez l’appartenance au groupe docker. Cette appartenance n’est pas une simple commodité : elle peut donner un contrôle étendu du daemon et donc de l’hôte.

Pour l’administration distante, utilisez SSH ou TLS mutuellement authentifié, limitez les adresses sources et placez le service derrière un réseau de gestion ou un VPN lorsque cela est approprié. Conservez les journaux en dehors de l’hôte afin qu’un attaquant ne puisse pas effacer l’unique copie. Surveillez l’émission des certificats, l’utilisation des clés et les changements de configuration du daemon.

Pour la CI, évitez de remettre à un job de build non fiable un socket hôte privilégié. Envisagez les modes rootless, des runners isolés, des workers éphémères, des identités distinctes pour le build et le déploiement, ainsi que des API limitées. Si un build nécessite réellement des opérations privilégiées, considérez le runner comme un système d’administration à haut risque et isolez-le en conséquence.

Dans les environnements cloud, incluez les écouteurs Docker dans la gestion de la surface d’attaque et la détection des dérives de configuration. Un modèle sécurisé peut être annulé plus tard par un script de lancement, une configuration du daemon intégrée à une image, une commande de dépannage ou une exception temporaire de pare-feu qui devient permanente.

Pour les développeurs, documentez le workflow distant approuvé. Les équipes créent souvent des écouteurs non sécurisés parce que le chemin sûr est mal défini ou peu pratique. Un contexte SSH pris en charge, un environnement de développement géré ou un service de build bien conçu réduit la pression qui pousse à exposer directement un daemon.

Distinguer exposition et compromission confirmée

Un écouteur Docker public ou largement accessible en interne constitue une constatation grave, mais ne prouve pas automatiquement qu’un attaquant l’a utilisé. Conservez trois états distincts dans les dossiers d’incident :

  1. Exposition confirmée : le daemon acceptait, ou pouvait accepter, des connexions provenant d’un réseau non fiable.
  2. Activité suspecte identifiée : les journaux ou la télémétrie de l’hôte montrent des requêtes, des processus, une activité réseau ou des changements de configuration qui ne s’expliquent pas par une activité autorisée.
  3. Compromission confirmée : les enquêteurs disposent d’éléments suffisants pour établir qu’une partie non autorisée a obtenu le contrôle ou accédé à des données.

Cette distinction améliore les décisions. Une exposition confirmée doit entraîner une fermeture immédiate et un examen fondé sur le risque. Une activité suspecte identifiée doit déclencher le confinement et la réponse aux incidents. Une compromission confirmée doit entraîner un périmètre complet, la révocation des identifiants, la récupération, l’évaluation des notifications et le retour d’expérience.

Elle évite aussi deux erreurs fréquentes. La première est la complaisance : « Nous n’avons pas vu de conteneur malveillant, donc l’exposition était sans conséquence. » La seconde est l’exagération : « Le port 2375 était ouvert, donc tout l’environnement a certainement été compromis. » Un bon rapport de sécurité peut être urgent sans prétendre que les preuves en disent davantage qu’elles ne le font.

L’angle IA est secondaire, mais reste instructif

L’utilisation par CARBONATO d’un framework d’agent IA signale la manière dont les attaquants peuvent conditionner leur automatisation ; elle ne justifie pas de considérer tout composant IA comme intrinsèquement malveillant. Le framework décrit par la Cloud Security Alliance est open source et peut avoir des usages légitimes. Sa réutilisation dans un botnet illustre un schéma de sécurité bien connu : un logiciel légitime devient une composante d’attaque lorsqu’un adversaire contrôle l’environnement d’exécution et la configuration qui l’entourent.

Les défenseurs doivent donc ajouter à l’enquête les logiciels installés, les fichiers de configuration, les activités planifiées, les destinations sortantes et les identifiants consultés. Rechercher uniquement un nom de produit peut laisser passer un déploiement modifié ou une charge utile entièrement différente. À l’inverse, bloquer le nom d’un framework légitime sans corriger l’exposition Docker laisse ouvert le chemin d’accès initial.

La leçon plus large concerne les frontières de l’automatisation. Un framework IA exécuté sur un hôte compromis peut rendre l’exécution de tâches plus flexible, mais il ne crée pas l’autorité initiale. Cette autorité venait du daemon Docker. Une authentification solide, la segmentation réseau, l’intégrité de l’hôte, l’hygiène des identifiants et des journaux utiles restent les contrôles déterminants.

Une liste de contrôle pratique pour la prochaine revue

Les équipes peuvent transformer cet incident en contrôle récurrent :

  • Inventorier tous les daemons Docker et les réseaux qui peuvent les atteindre.
  • Vérifier qu’aucune API Docker sans authentification n’est exposée à Internet ou à un réseau interne non fiable.
  • Rechercher le TCP 2375 et les écouteurs personnalisés du daemon, plutôt que les seuls noms de services attendus.
  • Remplacer l’administration TCP improvisée par SSH ou par un TLS mutuellement authentifié correctement configuré.
  • Restreindre l’accès au socket Docker et examiner les membres du groupe docker.
  • Séparer les runners CI des réseaux et des identifiants de production sensibles.
  • Centraliser les journaux Docker, hôte, pare-feu, cloud, identité et registre.
  • Examiner la création inattendue de conteneurs, les paramètres privilégiés, les montages d’hôte, les nouvelles images et les connexions sortantes.
  • Renouveler les identifiants qui ont pu être lisibles depuis les hôtes ou charges de travail concernés.
  • Reconstruire les hôtes lorsque leur intégrité ne peut pas être établie depuis un support fiable.
  • Ajouter l’exposition du daemon et les dérives de configuration aux contrôles de sécurité récurrents.
  • Documenter un workflow approuvé d’administration distante afin que les ingénieurs ne créent pas d’écouteurs d’urgence.

CARBONATO rappelle à point nommé que le plan de contrôle d’une plateforme de conteneurs est lui-même un actif critique. L’action défensive décisive n’est pas de spéculer sur la nouveauté de la charge utile. Il faut vérifier qui peut atteindre le daemon, ce que celui-ci peut faire, ce qu’il a fait récemment et quelles identités seraient exposées si l’hôte était compromis. Lorsque ces questions deviennent routinières, le risque est plus facile à gérer, sans panique ni confiance excessive.

Sources