L’origine de ce problème se trouve dans la séparation trop faible entre les conteneurs quand le système hôte crée un espace utilisateur virtualisé pour chaque conteneur. Des travaux de R&D ont eu lieu pour concevoir de véritables conteneurs « bacs à sable » étanches. La plupart des solutions passent par une reconstruction des frontières entre les conteneurs pour augmenter leur isolation. Cette analyse couvre quatre projets uniques venus d’IBM, Google, Amazon et OpenStack, respectivement, qui utilisent différentes techniques pour atteindre ce même but, créer une isolation plus grande pour les conteneurs. IBM Nabla construit les conteneurs au-dessus de Unikernels, Google gVisor crée un noyau « guest » dédié pour faire tourner les conteneurs, Amazon Firecracker est un hyperviseur extrêmement léger dédié aux applications mises en « bac à sable », et OpenStack place les conteneurs dans une machine virtuelle spécialisée qui est optimisée pour chaque plate-forme d’orchestration des conteneurs.

Configuration des conteneurs et sécurité, ce qu’il faut retenir

Il y a plus de 40 000 instances uniques hébergeant des conteneurs qui ont une configuration par défaut permettant une identification rapide. Les plates-formes de conteneurs Kubernetes et Docker ont chacune plus de 20 000 instances uniques. Cela ne veut pas forcément dire que chacune de ces 40 000 plateformes sont vulnérables à des attaques ou même à des fuites de données sensibles : cela montre juste que des habitudes de configurations trop faibles existent et qu’elles peuvent faire des entreprises qui les utilisent des cibles pour de futures compromissions. Des défauts de configuration apparemment simples au sein d’un service cloud peuvent avoir un impact sévère pour les entreprises. Ainsi, la perte des clés et jetons d’identifications pour 190 000 comptes de Docker Hubétait due à un attaquant qui avait tiré parti de la mauvaise configuration du stockage des clés et jetons dans un environnement cloud.

Ladders, en laissant fuiter plus de 13 millions de dossiers d’utilisateurs, est l’exemple des conséquences graves qu’une simple mauvaise configuration de conteneurs peut avoir. La leçon à retenir du cas Ladder serait que la sécurité des configurations devrait être au premier plan des préoccupations de toutes les entreprises déployant des services de conteneurs. Lors de notre enquête, nous avons été capables de trouver facilement 20 353 conteneurs Kubernetes partout dans le monde à partir de simples mots-clés. Ces instances étaient situées en Chine, aux États-Unis, en Allemagne à Hong Kong et en France. Dans le cas de Docker, bien qu’Amazon était encore une fois, l’hôte le plus fréquent, il y avait une distribution plus large des hôtes dans ces instances.

L’Unit42 a alors approfondi les recherches sur certaines de ces instances exposées pour voir quels étaient les services exposées et les informations susceptibles d’être récupérées. Ses chercheurs ont trouvé des sites exposant leurs instances de bases de données au public, mais également des sites exposant des données personnelles.

L’analyse (à retrouver dans son intégralité ci-dessous) montre les résultats des recherches de l’Unit 42 sur les conteneurs mal configurés, les méthodes utilisées pour identifier les services exposés au public, et les mesures à prendre pour sécuriser les services de conteneurs.

Dans cette analyse, l’Unit42 identifie les mauvaises configurations les plus courantes dans les services de conteneurs. Vos lecteurs pourront ainsi déployer leurs plates-formes de conteneur de façon plus sécurisée et privé, évitant les méthodes de récupération des données que l’Unit42 a démontrées dans cette analyse.