Les 5 principaux risques de sécurité liés aux conteneurs Docker

I. Présentation

Lorsque l’on ne baigne pas quotidiennement dans la cybersécurité et que l’on n’a pas été spécifiquement formé à la technologie Docker, les risques concrets liés à celle-ci peuvent ne pas être clairement compris et intégrés. C’est pour cette raison que je vous présente dans cet article, les 5 principaux risques de sécurité liés à Docker. Nous évoquerons notamment les détails et impacts concrets de ces risques ainsi que les moyens de protection et bonnes pratiques associés.

L’utilisation de Docker a révolutionné la manière dont les applications sont déployées et gérées en offrant une solution de conteneurisation légère et portable. Cependant, comme toute technologie, Docker et la conteneurisation présentent des risques de cybersécurité qu’il est important de connaître et de gérer.

En effet, Docker complique quelque peu la chose lorsque l’on s’intéresse à son fonctionnement interne, et donc sa sécurité : API, gestion du stockage, registres externes, images, réseau et communications entre conteneurs, etc. Tous ces sujets sont autant de risques d’erreur, de négligence et de compromission.

Cette « complexité » permet d’utiliser Docker dans de nombreux contextes d’application et de développement, mais nécessite plus d’efforts pour comprendre et maîtriser sa sécurité.

II. Les principaux risques liés à Docker

A. Risque n°1 : utilisation d’images vulnérables/non fiables

L’intérêt majeur de Docker est la possibilité de construire rapidement et facilement des images qui serviront de modèle aux conteneurs. Les images peuvent donc être mises à disposition de tous, téléchargées et utilisées pour servir de base à d’autres images.

Les registres, également appelés « hubs« , sont les principaux endroits où les images Docker sont partagées et stockées. Des exemples populaires incluent Docker Hub et les registres privés hébergés par des entreprises. En plus de ces hubs, il est aussi courant de trouver des images Docker sur des plateformes comme GitHub, où les développeurs publient souvent leurs projets et les images associées.

Les images Docker contiennent tout le nécessaire pour exécuter une application, y compris le système d’exploitation, les bibliothèques, les dépendances, et le code de l’application. L’un des risques majeurs dans l’utilisation de Docker réside dans l’utilisation d’images obsolètes, vulnérables, voire directement piégées. Ces images peuvent se trouver sur des registres non officiels ou sur GitHub, mais aussi sur le registre officiel (Docker Hub) !

Le risque d’utiliser une image vulnérable est d’introduire des vulnérabilités au sein de votre système d’information sans vraiment le savoir. On parle ici notamment d’images qui comportent des versions non à jour de paquets, qui sont impactés par des vulnérabilités publiques (CVE). Pour démontrer ce constat et sensibiliser les utilisateurs, il est fréquent que des rapports et des résultats d’analyses automatisées paraissent publiquement et annoncent avoir identifié des milliers d’images contenant des vulnérabilités, même sur celles provenant du Docker Hub officiel !

Également, les images piégées sont des images se faisant passer pour légitimes, avec un nom se rapprochant d’images populaires, une description et tout ce qu’il faut, mais qui contiennent du code malveillant qui s’exécutera dès que celle-ci sera instanciée en conteneur. Souvent, l’intérêt pour l’attaquant peut-être soit le minage de cryptomonnaie, il utilise alors les ressources de votre infrastructure pour se faire de l’argent, soit l’implantation dans votre SI de portes dérobées (un accès distant et discret). Ces portes dérobées peuvent ensuite être revendues au plus offrant, qui s’en servira pour s’introduire plus profondément dans votre système d’information.

Sur IT-Connect, nous vous rapportons fréquemment la découverte de plusieurs milliers d’images Docker piégées découvertes sur les registres officiels :

Un retour d’expérience intéressant à lire sur ce sujet est celui de l’équipe de recherche de TrendMicro :

Les cas d’utilisation d’images vulnérables ou piégées viennent la plupart du temps d’une méconnaissance des risques associés à Docker ou de négligences de l’administrateur/développeur qui ne vérifie pas avec attention les images téléchargées et utilisées.

• Comment s’en protéger ?

Pour se protéger contre ce risque, il est dans un premier temps important de maîtriser le fonctionnement de Docker, savoir qu’une image peut contenir des paquets non à jour, des binaires tiers et du code malveillant. Il ne s’agit pas d’un système d’exploitation « propre » comme lorsque l’on installe une Debian à partir d’une image ISO fraîchement téléchargée.

Ensuite, il faut se restreindre à utiliser des registres officiels d’images et rester très vigilant sur les images utilisées en privilégiant les éditeurs de confiance avec une bonne réputation et les bons « badges« .

Pour finir, il ne faut pas hésiter à vérifier soi-même les images utilisées en analysant leur contenu (paquets, binaires), leur Dockerfile (fichier d’initialisation) et leur comportement. Cela est possible via des outils comme Trivy, Snyk.io et d’autres qui sont mentionnés dans notre article dédié à ce sujet :

B. Risque n°2 : Docker Escape

Un autre risque notable concernant l’utilisation de Docker est celui du Docker Escape, aussi nommé « Container Breakout ». Il s’agit de la possibilité pour un attaquant ayant compromis un conteneur de s’échapper de celui-ci pour obtenir un accès à l’hôte sous-jacent.

Le risque de Docker Escape est bien plus présent qu’on ne le pense, et cela ne passe pas uniquement par l’exploitation de vulnérabilités relatives à des manques de mise à jour. La configuration de Docker permet d’effectuer bien des choses dangereuses à ce niveau, partages de ressources, d’espace de stockage, permissions spéciales, etc. Il existe un grand nombre de configurations et contextes d’utilisation qui peuvent être exploités par un attaquant afin de tenter d’obtenir un accès à l’hôte.

On peut citer les cas où la configuration autorise le partage de l’espace PID entre l’hôte et le conteneur (directive « –pid« ), ou l’exécution de conteneurs privilégiés (directive « -privileged« )

Pour illustrer ce risque et notamment le grand nombre de cas où un Docker Escape est possible, je vous oriente vers le site Hacktrickz, qui référence les techniques des hackers et pentesters, ici concernant précisément les méthodes de Docker Escape :

Également, différentes vulnérabilités publiques provenant du code de Docker lui-même et permettant de s’échapper d’un conteneur Docker sont régulièrement découvertes et publiées. La dernière en date est la CVE-2024-21626, nommée « Leaky Vessels« . Pour les curieux, vous trouverez une analyse approfondie de cette vulnérabilité sur le blogpost suivant :

On peut également citer l’investigation faite par l’Unit42 de TrendMicro sur l’activité du groupe d’attaquants TeamTNT et du malware Hildegard ciblant les clusters Kubernetes. Ce malware intègre notamment des codes d’exploitation de vulnérabilités (CVE), mais aussi de mauvaises configurations afin de réaliser un Docker Escape :

Le risque des Docker Escape est bien entendu de permettre à un attaquant de se propager et continuer sa compromission au-delà du simple conteneur Docker qu’il a initialement compromis. Ceci ouvrant un accès à tout le système d’exploitation avec ses binaires, aux autres conteneurs Docker, et plus globalement au reste du système d’information. Ainsi, il ne faut pas oublier que les conteneurs Docker ont une surface d’attaque qui leur est propre. Ils peuvent être compromis au même titre que n’importe quels systèmes et applications et qu’ils représentent, eux aussi, un vecteur d’entrée sur le SI ou sur un serveur, notamment s’il s’agit d’images piégées.

• Comment s’en protéger ?

Pour se protéger de ces Docker Escape, il est nécessaire de connaître les contextes et configurations où ils sont possibles et d’opter pour une configuration sécurisée et durcie. Cela requiert donc de bonnes connaissances de Docker, mais aussi des méthodologies et techniques des attaquants ainsi que les risques associés à chaque directive de configuration utilisée.

Également, le maintien à jour des paquets Docker sur l’hôte permettra de se protéger des Docker Escape utilisant une vulnérabilité interne à Docker et ses dépendances.

C. Risque n°3 : Compromission interconteneurs et réseau

Au-delà des Docker Escape, un risque que l’on oublie souvent concernant Docker est la possibilité de rebond d’un attaquant ayant compromis un conteneur vers d’autres conteneurs voisins, voire vers l’intégralité du système d’information. Les conteneurs Docker possèdent, en effet, une exposition réseau et une adresse IP, ce qui leur permet de servir de serveur de rebond en cas de compromission.

Ainsi, il est tout à fait possible de chercher à compromettre d’autres conteneurs (ceux du même nœud/hôte par exemple) via le réseau et non via Docker Escape. Mais aussi de s’attaquer directement à l’Active Directory, ou aux postes utilisateurs si le cloisonnement nécessaire n’est pas mis en place. Il est également très fréquent que l’ensemble des conteneurs d’un même namespace Kubernetes soient tous au sein d’un même réseau et qu’ils ne soient protégés par aucun filtrage (entrant, sortant ou entre chaque conteneur). Ainsi, la compromission d’un seul conteneur permet d’en atteindre plusieurs autres, de voir s’ils possèdent les mêmes vulnérabilités, des accès ou des données supplémentaires, etc.

Le risque est donc bien entendu que ce défaut d’isolation réseau permette à l’attaquant d’aller beaucoup plus loin au sein du système d’information. Et, cela à partir d’un seul conteneur Docker que nous pensions inoffensif et sans intérêt.

• Comment s’en protéger ?

Pour se protéger d’une compromission d’un conteneur Docker vers le réseau, vers d’autres systèmes ou conteneurs, il faut mettre en place la segmentation et le cloisonnement réseau adéquat. Il faut non seulement protéger l’accès réseau aux conteneurs, mais aussi, et surtout protéger le reste du réseau des conteneurs, cela grâce au filtrage sur les flux entrants et sortants des conteneurs ou du réseau dans lequel ils se situent.

Au final, ils doivent se conformer aux mêmes restrictions que n’importe quel système du réseau. Les conteneurs sont souvent oubliés dans la politique de filtrage, ce qui est d’autant plus impactant sur les grandes infrastructures utilisant les conteneurs.

D. Risque n°4 : Déni de service

L’utilisation de conteneurs Docker expose également à la possibilité de subir des attaques par déni de service (DoS). Par défaut, un conteneur possède un accès illimité à la mémoire et au CPU de son hôte. Un conteneur configuré de manière inadéquate peut être facilement utilisé pour effectuer une attaque DoS. Par exemple, un script infini consommant du CPU ou de la mémoire peut bloquer les conteneurs ou l’accès aux autres services exécutés sur le même hôte.

Ces attaques peuvent donc impacter la disponibilité des applications en consommant de manière excessive les ressources système, telles que le CPU, la mémoire, le stockage ou le réseau.

L’absence de ces limitations peut permettre à un seul conteneur malveillant ou mal configuré de consommer toutes les ressources disponibles, entraînant une dégradation des performances ou un arrêt complet des services.

Comment s’en protéger ?

Pour se protéger contre les attaques DoS venant des conteneurs Docker, il est recommandé de mettre en place des quotas de ressources pour chaque conteneur. Mais aussi de surveiller l’utilisation des ressources à l’aide d’outils de monitoring comme Prometheus ou Grafana.

Vous pouvez, par exemple, limiter la mémoire (« –memory), l’utilisation du CPU (« –cpus« ), le nombre maximal de redémarrages, le nombre maximal de descripteurs de fichiers ou encore le nombre maximal de processus pour chaque conteneur. Accessoirement, cela vous permettra également de limiter les possibilités d’exploitation de votre infrastructure pour le cryptomining.

Enfin, il est aussi recommandé d’isoler les applications critiques sur des hôtes ou des clusters séparés pour éviter qu’une attaque n’affecte l’ensemble votre infrastructure.

E. Risque n°5 : Persistance et évasion

Les opérations de persistance et d’évasion dans les environnements Docker sont des tactiques utilisées par les attaquants pour maintenir un accès continu et furtif à un système compromis, et donc au système d’information.

Les techniques de persistance permettent à un attaquant de maintenir son accès même après des redémarrages, changement de mot de passe ou mises à jour. On retrouve dans ce risque de persistance des conteneurs compromis, dans lesquels l’attaquant ajoute une porte dérobée, les images piégées que nous avons déjà mentionné dans cet article, mais aussi des cas où l’attaquant télécharge une image, voir installe lui-même Docker sur un hôte compromis afin d’y positionner sa porte dérobée.

Enfin, il faut savoir que les conteneurs Docker peuvent également être utilisés pour échapper aux systèmes de protection et de surveillance de son hôte. En effet, un EDR aura par exemple, plus de mal à contrôler et alerter sur l’activité d’un conteneur Docker, plus difficile à analyser et souvent pas du tout intégré à sa configuration ou son fonctionnement. C’est d’autant plus le cas pour les groupes d’attaquants cherchant à compromettre des infrastructures pour utiliser leur puissance de calcul pour du cryptomining.

• Comment s’en protéger ?

Pour se protéger de ce risque, il faut être conscient que Docker peut être utilisé pour de la persistance et de l’évasion. Il convient d’intégrer l’activité et les flux réseau des conteneurs dans la surveillance active des évènements de sécurité (envoi au SIEM/SOC, alertes de sécurité, etc.).

Également, lors des opérations d’investigation numérique et de threat hunting (recherche proactive de la menace), les conteneurs Docker doivent être totalement intégrés à l’analyse et ne pas être considérés comme optionnels ou inoffensifs.

III. Pour aller plus loin : ATT&CK Containers Matrix

Pour aller plus loin dans la compréhension des risques liés à l’utilisation à Docker et la conteneurisation, et donc d’une meilleure maîtrise et protection face à ces risques, je vous invite à consulter la matrice ATT&CK Containers du MITRE.

Cette matrice référence les techniques d’attaques observées dans des conditions réelles et étudiées, par exemple, dans des publications d’analyses forensics, d’équipe CERT, etc. Cela permet d’observer très concrètement les techniques qui sont effectivement utilisées par les attaquants, et donc de mieux s’en protéger.

Vous pouvez notamment voir que ces techniques sont organisées selon 9 colonnes, appelées « Tactics« , qui permettent de mieux comprendre le but recherché par l’attaquant lors de l’exécution de l’attaque (persistance, accès initial, prise d’information, etc.).

La particularité de cette matrice « Containers » est qu’elle contient uniquement les techniques relatives là ’exploitation de Docker et des technologies de conteneurs.

N’hésitez pas à accéder à chaque technique (nommée TTP) afin d’avoir une description de l’attaque :

Mais aussi des cas concrets, rapports d’analyse et exemples réels d’attaquant ayant utilisé cette technique :

IV. Conclusion

Pour résumer, voici une illustration qui récapitule les 5 risques dont nous avons parlé dans cet article :

Docker offre de nombreux avantages en termes de déploiement et de gestion des applications, mais il est important de comprendre et de gérer les risques de sécurité associés. En suivant les meilleures pratiques et en utilisant les outils appropriés, vous pouvez réduire considérablement ces risques et renforcer la sécurité de votre environnement Docker. Les cinq principaux risques abordés ici ne sont pas exhaustifs, mais ils représentent un point de départ pour être sensibilisés et mieux informés.

Pour continuer sur ce sujet, consultez notre article sur les outils d’analyse de la sécurité des images Docker (Hadolint, Trivy, Snyk et Dive):