Docker et la sécurité des chaînes de déploiement
Docker est une technologie permettant d’embarquer une application dans un container virtuel, et pouvant s’exécuter sur n’importe quelle machine. Aujourd’hui, elle est de plus-en-plus utilisée dans les entreprises afin de faciliter les déploiements d’application. Selon une étude menée par Docker en 2016, 58% des entreprises interrogées se servent de cette technologie en environnement de production. Le marché des conteneurs représentera d’ici 2020 plus de 2,6 milliards de dollars (Cabinet d’etude 451 Research). L’objectif de cet article est de montrer comment les vulnérabilités actuelles des chaînes de déploiement posent de réels problèmes quant à la sécurisation et à l’intégrité des containers Docker. Nous aborderons aussi les éventuelles vulnérabilités de Docker connues à ce jour et les bonne pratiques à adopter pour son utilisation en environnement de production.
1 — La sécurité des chaînes de déploiement mise à mal
Cette année nous avons assisté à des cyberattaques trouvant leur origine dans la corruption des chaînes de production (supply chain). La plus célèbre d’entre elles est survenue en Ukraine au mois de Juin dernier. Le ransomware NotPetya exploitant la même vulnérabilité que Wannacry survenu un mois avant, s’est répandu principalement d’après les analyses de Microsoft, Kaspersky Lab et Talos Cisco, au travers du logiciel de comptabilité et de taxes MEDoc utilisé par de nombreuses entreprises ukrainiennes. C’est par le biais d’une mise à jour que le malware aurait été diffusé. L’impact d’une telle cyberattaque est d’autant plus important si le logiciel corrompu est mondialement répandu, à l’exemple de CCleaner qui a été piraté en Septembre dernier et qui a infecté plus de 2 millions de machines. Les hackers ont réussi à s’introduire dans les systèmes d’Avast, société ayant racheté CCleaner, afin d’y publier une mise à jour du logiciel en y incluant le malware Floxit permettant au pirate de récolter des informations sur l’ordinateur infecté.
En résumé une supply chain attack consiste en premier lieu à s’introduire dans le système informatique de la chaîne de production par l’un des points d’entrée, d’y implanter ensuite un malware et enfin d’utiliser les circuits de distribution classique disponibles (dépôts officiels, mise à jour, conteneurs) pour infecter le plus de monde possible. Se prémunir face à ce type d’attaque est à l’heure actuelle très compliqué. Prenons l’exemple d’un logiciel : il est régulièrement mis à jour par les développeurs afin de corriger d’éventuels bugs et de proposer de nouvelles fonctionnalités. Sa réalisation requiert l’intervention de plusieurs sous-traitants informatiques fournissant de fait une partie du logiciel final. Ainsi chaque fournisseur ou sous-traitant devient un point d’entrée dans la chaîne de production pour les cybercriminels. Sécuriser une supply chain revient d’une part à sécuriser chaque point d’entrée possible afin d’éviter toute intrusion. Et d’autre part à appliquer la revue de code (code review) avant la mise en production, de manière à intercepter les versions de logiciels infectées.
2 — Docker, une nouvelle technique de déploiement
Le déploiement des applications a toujours eu un objectif : optimiser les ressources matérielles utilisées. Le matériel coûte cher, plus on optimise la répartition des ressources, plus bas sera le coût. Pour cela plusieurs techniques ont été utilisées, à chaque fois encouragées par des innovations technologiques.
On a tout d’abord installé un logiciel par serveur, cependant si l’application n’est pas utilisée au maximum de ses capacités hardware, la puissance de calcul est perdue. La virtualisation des systèmes est venu pallier ce problème. On a ainsi pu répartir de nouveau les ressources entre les applications. On les a alors déployées à l’aide d’hyperviseur. Cette technique a tout de même eu une limite, les ressources perdues pour faire tourner chaque application.
On a alors essayé de joindre les deux concepts, avec un seul système qui tourne mais un cloisonnement des processus : la conteneurisation est alors devenue évidente. Depuis 4 ans et demi, Docker, logiciel libre automatisant le déploiement d’applications dans des conteneurs logiciels, est de plus en plus utilisé dans ce domaine.
Cependant, le cloisonnement n’est pas parfait et engendre de nombreux problèmes de sécurité. L’utilisation également de chaînes de déploiement (rendu possible par les conteneurs) crée une vulnérabilité au niveau de la chaîne de distribution.
3 — Le déploiement avec Docker
Ces chaînes sont devenues les cibles privilégiées des pirates, Docker n’échappe pas à cette règle. Cela permet au code d’un pirate de se retrouver validé par les outils de déploiement de l’entreprise. La recherche en sécurité sur Docker est récente, c’est une technologie nouvelle et est maintenant sous la dissection d’experts en sécurité. Des sociétés en on fait leur activité principale tel que Aqua Security ou encore SysDig.
L’attaque d’une chaine de déploiement n’est pas simple. On peut l’imaginer tel un tuyau fermé où toutes les sécurités sont mises en œuvre entre l’ordinateur du développeur jusqu’à l’environnement de production.
Cela nous donne deux principaux vecteurs d’attaques : l’ordinateur du développeur qui est le point d’entrée et l’environnement de production chez un client. Comme on a pu voir lors de l’attaque de Petya, cela peut venir d’un code infecté. Cependant Docker expose énormément de nouvelles surfaces d’attaque de supply-chain depuis le poste du développeur.
Dans le cadre de son fonctionnement, Docker est constitué de deux éléments principaux :
- Le serveur utilise un socket web pour recevoir les commandes.
- Le client envoie des requêtes au serveur et affiche les résultats dans la console.
Sur un poste Linux, le serveur tourne à l’aide d’un socket Linux sur le système et Linux est chargé des vérifications des droits d’accès à partir des permissions d’accès au socket. Sur Mac et Windows, l’implémentation de Docker est différente (Docker4Mac et Docker4Windows, nous ne traitons ici que la version boot2docker pour Windows et non la nouvelle version de conteneur de Docker Windows). Docker lance une VM Linux où Docker lance uniquement son serveur et écoute sur un port de communication réseau TCP. De cette façon le client Docker tournant sur Windows ou Mac fait ses requêtes à destination de `localhost:2375`.
Ce schéma de fonctionnement rend possible une attaque dirigée vers l’ordinateur d’un développeur depuis une simple page web. En effet celle-ci va demander au démon local de construire et de lancer une image depuis le code d’un dépôt GIT en ligne.
De cette façon le pirate peut accéder à toute la machine du développeur en montant des répertoires locaux et en y accédant à distance.
4 — Sécuriser une chaîne de déploiement Docker
Docker tente de palier de plus en plus à ce problème de sécurité majeur au moyen de limitations d’appel du démon. C’est un jeu du chat et de la souris entre les équipes de développement de Docker et les attaquants.
Une autre façon de sécuriser la supply-chain est de la considérer dès le début comme corrompue et à ce moment d’optimiser les moyens de contrôle en production. Docker fournit de nombreuses fonctionnalités de cloisonnement qui sont activées par défaut. Un conteneur lancé sur un serveur Docker est directement cloisonné et ne peut accéder qu’à lui même, aux volumes qui lui sont liés et aux réseaux qui lui sont reliés. Pour sécuriser un conteneur en production, voici les règles à respecter :
- Vérifier les volumes que l’on monte dans un conteneur. Dans l’idéal, aucun chemin local ne doit être monté. Les volumes doivent exister dans une zone dédiée.
- Ne pas lier le conteneur à n’importe quel réseau. Est-ce que le conteneur nécessite un accès à Internet ? A un réseau de base de données ?
- Les privilèges ne doivent être donnés qu’en dernier recours. Docker est un programme qui tourne en administrateur sur le poste, il faut donc limiter les droits root cédés au programme du conteneur.
Si un doute persiste, il faut exécuter le code dans une sandbox dédiée afin d’éviter toute propagation d’une éventuelle infection.
L’ajout de règles de sécurité à l’entrée de la supply-chain permettra de garantir une meilleure sécurité du code distribué chez un client. Des processus de vérification de code doivent être mis en place dans les entreprises distribuant les logiciels afin d’éviter qu’un ajout de code malicieux passe inaperçu pour l’éditeur de logiciel. De plus, lors de l’exécution de logiciel provenant de tierces parties, l’utilisation de sandbox est recommandée et les permissions octroyées aux applications doivent être raisonnées.
Philippe VIENNE et Wilfried GATA
