Bon retour pour cette nouvelle étape dans l’aventure de la sécurité et des conteneurs !
Aujourd’hui je te propose d’aborder ensemble la question de l’analyse des images et le patch de CVE découvert.
Lecteur : « Attends, une CVE c’est quoi ? D’ailleurs on va voir une notion agnostique pour tous les types de conteneurs ? On va enfin passer à la pratique ? »
Oui cet article sera avec de la pratique, car je te proposerai de manipuler des outils (choisi gratuit et open source, pour que tous puissent suivre cet article). Concernant la technologie on utilisera des conteneurs Docker (solution la plus répandue à la rédaction de ces lignes) ainsi que le moteur d’analyse Trivy[1].
Comme tous les lecteurs ne sont pas nécessairement familiers avec la notion de construction d’image ou de CVE, nous commencerons par introduire ces éléments. Si ce sont des éléments que vous maîtrisez déjà, vous pouvez directement sauter vers la seconde partie de l’article.
Un peu de théorie avant la pratique !
CVE quèsaco ?
Le terme anglais Common Vulnerabilities Exposures (CVE) définit simplement les vulnérabilités informatiques connues au sein de la communauté. Ce sont des éléments émis publiquement par les éditeurs de logiciels ou des CERT (Computer Emergency Response Team) sur des vulnérabilités détectées au sein de produits informatiques (système d’exploitation, logiciel …).
L’objectif d’une CVE est de prévenir et d’informer le plus grand nombre de l’existence d’une faille de sécurité et de conseiller sur les mesures à suivre pour empêcher des acteurs malintentionnés de l’exploiter.
Chaque CVE possède un score qui est calculé en fonctions de nombreux facteurs dont l’impact qu’elle a sur le système, ainsi que du vecteur d’attaque[2].
Image Docker
Pour la partie pratique nous utiliserons une image docker. Avant de parachuter des éléments, je te propose de faire un point sur comment fonctionne les conteneurs avec Docker.
Il existe 2 éléments qu’il faut distinguer dans docker qui sont l’Image et le Conteneur. Une image Docker est en fait un fichier tar contenant config et exécutable, les images sont immuables (liée à un hash propre). Un conteneur est une instance de l’image en cours d’exécution, il peut donc y avoir plusieurs conteneurs de la même image en cours d’exécution sur une machine.
La première étape dans notre aventure de conteneurisation est de créer un « manifeste » qui donne les instructions au Daemon Docker des étapes à suivre pour la création d’une image. Ce fichier appelé Dockerfile regroupe 3 éléments :
- La base de l’image
- Les instructions à exécuter lors de la création
- Les instructions à exécuter lors du démarrage du conteneur
Une fois ce fichier rédigé, il convient de faire construire l’image par Docker, puis de créer un conteneur à partir de cette dernière.
Pour l’analyse de CVE, nous pratiquerons un scan de vulnérabilité sur l’image de l’application, c’est une sorte d’analyse SAST (Static Application Security Testing) / SCA (software composition analysis) étendue à l’image de base. L’avantage que nous offre Trivy est la possibilité de faire un scan sur les packages installés et donc de répondre en plus à un scan SCA (software composition analysis).
Une fois les vulnérabilités détectées … il ne reste plus qu’à les patcher !
Commençons la pratique moussaillon !
Tout d’abord, je te propose de suivre cet article, car rien ne vaut la pratique pour comprendre ! Toutes les sources sont disponibles sur ce dépôt git : https://gitlab.com/security-and-container/detect-and-patch-cve
Le ReadMe te guidera sur ce qu’il te faut installer pour suivre pas à pas cet article si tu souhaites pratiquer … sinon, bonne lecture J
Quelle application patcher ?
Alors le premier défi est de trouver quelque chose à colmater, mais ne crains rien jeune moussaillon, j’ai tout prévu pour toi.
Dans le dépôt Git, tu trouveras un Dockerfile contenant un simple site internet … dont l’image est pleine de CVEs ! Cette image est simplement un serveur Appache2 servant une page HTML simple qui a été récupéré avec une commande curl[3].
Je te propose de lancer l’image avec la ligne de commande : « docker run -p 80:80 -d securiteandconteneurs/art3:vuln »
En allant sur ce lien (http://localhost) en local dans ton navigateur web, tu devrais voir apparaitre le magnifique site web de l’image ci-dessous.
Scan de l’image & patch
Pour exécuter ce scan, il suffit d’utiliser la commande “`trivy securiteandconteneurs/art3 :vuln “`
Voici le résultat du scan au jour de la rédaction de l’article :
Comme vous pouvez le constater, il existe déjà 16 CVEs présentes dans l’image, mais pas de panique, nous allons y remédier ! Interprétons tout d’abord le résultat du scan.
Il existe 6 colonnes qui contiennent dans l’ordre :
- Library correspond au package touché par la CVE
- Vulnerability ID qui correspond au code de référence de la CVE découpé comme suit : CVE-année-numéro_CVE_de_l_année
- Severity correspond à un niveau de criticité réparti de la plus faible à la plus haute comme suit : Negligible, Low, Medium, High, Critical et une classe Unknown pour les vulnérabilités dont la criticité est inconnue
- Installed version correspond à la version actuelle du package installer sur l’image
- Fixed version correspond à la version du package qui corrige la CVE sur le package
- Title est un bref résumé sur la CVE
Il y a un point d’attention important à considérer : il est possible que les nouvelles versions des packages touchés ne disposent pas des mêmes fonctionnalités que ceux utilisés précédemment. Dans notre cas pas de soucis, mais pour des applications plus complexes, il faut passer par une longue phase de tests en patchant les CVE une à la fois puis en retestant l’application, pour être certain de ne pas rendre inutilisables des fonctionnalités de l’application.
La première étape dans notre cas est de faire une mise à jour des paquets. Il existe 2 solutions pour y arriver :
- Patcher chacun d’entre eux manuellement en ajoutant une ligne « RUN apk add paquet1~=version paquet2~=version … »
- Faire une update & upgrade de tous les paquets. Tous les paquets étant mis à jour, ceux qui sont vulnérable devrait être patchés sur la dernière version disponible (à condition que cette version n’ait pas non plus de failles !)
La première est plus longue et fastidieuse (surtout quand on se retrouve avec plusieurs dizaines de CVEs à traiter) mais permet un meilleur contrôle de ce que l’on introduit dans ses images.
La seconde version est déconseillée pour les environnements de prod, car les versions de tous les paquets sont mises à jour avec la dernière disponible … qui peut ne pas être compatible avec les logiciels qui sont déployés.
Choisis ta méthode de patch et il n’y a plus qu’à ^^.
Les corrections sont disponibles sur le git dans les dossiers methode1 et methode2.
Pour ceux faisant les manipulations en même temps, vous pouvez build l’image comme suit (le fichier patché étant disponible sur le dépôt git) :
- Méthode 1 : “docker build -t securiteandconteneurs/art3:patch-m1 patch-image-m1/.”
- Méthode 2 : “docker build -t securiteandconteneurs/art3:patch-m2 patch-image-m2/.”
Cette image est maintenant construite, mais est-elle pour autant invulnérable ?
Je te propose de faire un scan de celle-ci avec la commande (prenons la méthode 2 par exemple): “`trivy securiteandconteneurs/art3:patch-m2 “`
Et voilà, nous nous sommes débarrassés des failles inhérentes à la conteneurisation.
Conclusion
Nous avons pu voir ensemble comment détecter et patcher des CVEs sur docker, tu sais désormais comment rendre tes images plus sécurisées … mais cette sécurité ne correspond qu’aux images Docker !
En effet, les bonnes pratiques de codage ainsi que des audits de code sont tout autant nécessaires que ce que nous avons pu voir ensemble lors de cet article pour garantir une bonne sécurité applicative.
J’espère te revoir pour la prochaine étape de ce voyage avec le prochain article : Monitoring et détection d’intrusion sur conteneurs.
par Cédric PAOLI, Consultant en Cybersécurité
[1] Il existe d’autres solutions Open Source comme Anchore, ou Clair, mais les techniques utilisées restent les mêmes pour la détection et le patch. Cependant, Trivy a tendance à être plus performant en vitesse d’analyse ainsi qu’en précision des résultats (faux positifs ou non détection).
[2] Pour aller plus loin sur les différentes modalités du scoring des CVE (appelé CVSS) tu peux commencer par explorer ce lien : https://www.first.org/cvss/calculator/3.0
[3] Source de la page web : https://www.york.ac.uk/teaching/cws/wws/webpage1.html
