Heureux de te retrouver pour cette seconde étape de ton aventure sur la sécurité des conteneurs (si tu ne l’as pas encore fait, je te conseille de commencer par l’article d’introduction :).
Il y a quelque chose de pourri au Royaume du Danemark !
Pour commencer cet article, je te propose le scénario de départ suivant : « Fière d’être entrée dans l’air du cloud, l’équipe vient de finaliser la conteneurisation de son application. On a même mis en place un pipeline CI/CD avec du déploiement automatique sur les versions passant les tests.
Mais quelque chose ne va pas … vos conteneurs consomment beaucoup trop de ressources, y compris sur des plages horaires de faible influence. Vous menez votre enquête et là, catastrophe vous vous rendez compte qu’il y a des mineurs de cryptomonnaie sur vos conteneurs. Comment est-ce arrivé ?»
Hercule Poirot enquête …
Trois raisons peuvent expliquer un tel fait : soit vous avez un stagiaire qui a trouvé le moyen de se financer sa prime, soit vos credentials ont été compromis, soit vous venez de subir un supply chain poisonning.
Considérons que vos stagiaires sont des anges[1] et que suite à une consultation de vos logs, vous n’avez pas de connexions suspectes (ni d’intrus sur votre SI après une enquête un peu plus poussée) … Il ne reste plus qu’une seule possibilité, le supply chain poisoning (SCP) !
Je vous propose dans cet article de faire le point sur le concept de cette attaque, qui a été récemment la source d’une faille de sécurité majeure pour de nombreux acteurs à cause de la compromission de Solarwinds puis je vous guiderai dans un second temps vers des solutions pour vous en prémunir.
[1] Méfiez-vous tout de même, j’ai un professeur qui jurait que c’était une espèce variante de gremlins, grignotant les câbles ou les inversant pendant la nuit … mais ça ne devrait plus poser de problème à l’heure du cloud 🙂
Source : https://xebia.com/blog/open-source-supply-chain-attacks/
Un concept simple pour une attaque efficace
Le supply chain poisoning (ou l’empoisonnement par les chaines d’approvisionnement en français) repose sur un principe simple : utiliser la confiance en vos fournisseurs de contenu pour vous atteindre.
Mais comment cela fonctionne-t-il dans le cadre de la conteneurisation ?
Ce type d’attaque peut intervenir à 2 niveaux dans le cadre des environnements conteneurisés :
- Sur l’image servant de base pour l’application
- Sur les dépendances utilisées
Des images non fiables
Pour conteneuriser une application, il est dans la plupart des cas nécessaire d’utiliser des images comme base pour leur création (le fameux FROM dans le Dockerfile).
Cependant, à partir du moment où ces images ne sont pas des distributions officielles, mais une version mise en ligne par la communauté, elles présentent plus de risques.
En effet, vous n’avez pas de contrôle sur ce qui a été ajouté par rapport à une distribution officielle[1].
Dans ce cas si vous utilisez une image qui est compromise comme base pour votre conteneur, vous venez d’ouvrir la porte à des pirates !
Des dépendances non contrôlées
Lors du codage de l’application, vos développeurs vont surement avoir recours à des bibliothèques pour gagner du temps (cela ne sert à rien de réinventer la roue !).
Là où le supply chain poisoning peut intervenir à cette étape est l’utilisation d’éléments qui contiennent des codes malveillants qui vont se charger d’installer des éléments supplémentaires sur votre SI.
Comment se prémunir d’une telle attaque ?
La première et la plus simple des bonnes pratiques est d’utiliser uniquement des images officielles.
Pour s’assurer qu’il n’y ait pas de problème lors de la création de votre image, assurez-vous que le hash de l’image sur laquelle elle sera basée correspond bien à celui de l’image officielle sur dockerhub.
Ainsi, il est possible de contrôler la conception des images de votre application, mais également les éléments constitutifs. Si vous tenez absolument à utiliser une image de la communauté, assurez-vous d’avoir accès à son fichier de construction[2] pour vérifier ce qu’il y a de présent sur l’image (quitte à la construire en local comme vous avez accès au fichier source). Si l’image que vous souhaitez utiliser n’a pas cette référence à minima, passez votre chemin !
Pour la question des dépendances, la question est plus délicate : il est complexe et coûteux de faire des audits de code sur les dépendances utilisées.
Dans ce cas de figure, il vaut donc mieux utiliser des bibliothèques connues et largement utilisées au sein de la communauté. Ce dernier point n’est pas gage de fiabilité ou d’exemption de failles, mais cela permet de limiter les surprises et d’avoir des codes mieux maintenus et patchés en cas de faille de sécurité.
Quoi qu’il en soit ça ne vous exempte pas de mettre en place des SCA (Software Composition Analysis) dans votre pipeline pour détecter des failles connues sur les dépendances que vous utilisez.
Si votre application relève du domaine de la sécurité ou de la défense … mon conseil est d’obliger vos fournisseurs à passer des audits de code avant qu’ils ne soient intégrés à votre projet. En effet, les outils SCA ne fonctionnent d’une part que sur des éléments Open Sources, mais ne font pas réellement d’audit de sécurité, ils se contentent de remonter les failles connues.
Exemple de mise en pratique de ces conseils
J’ai pu mener le projet de la création d’une application de reporting de vulnérabilités sur des applications conteneurisé il y a quelques mois. L’objectif était d’avoir une application déployable sur un cluster qui s’assurerait de contrôler les autres conteneurs en cours d’exécution.
Dans ce cas de figure la majorité du code a été développé en interne pour des soucis de sécurité et de contrôle qualité, mais voici quelques-uns des éléments que j’ai eu l’occasion de mettre en place pour éviter de tomber dans les pièges du supply chain poisonning.
Contrôle de hash
Ce premier point est le plus simple à mettre en place et a permis d’éviter de mauvaises surprises. J’ai simplement mis en place une liste de hash d’image autorisée comme bases pour les images applicatives créées.
Les images n’ont donc été créées que sur une liste de sources contrôlées au préalable.
Contrôle des dépendances
Cette phase du projet s’est décomposée en 2 volets : La mise en place d’un scanneur SCA au sein du pipeline, puis une revue manuelle de code pour les éléments cruciaux au projet.
Pour le premier volet, l’outil de scan de vulnérabilité des images sélectionnées (Trivy) ayant la possibilité de détecter les vulnérabilités des dépendances, il n’a pas fallu faire d’ajout d’outils SCA supplémentaires.
Pour le second volet, il a fallu manuellement scanner le code de certaines les dépendances.
L’objectif étant durant cette analyse de s’assurer que des failles importantes, non détectées existaient au sein de ces codes.
Au vu du temps à investir dans une telle analyse, elle n’a été réalisée que pour certaines dépendances de l’application (principalement pour le conteneur front-end de l’application).
Contrôle automatique de vulnérabilité avant déploiement
Lors de la conduite de ce projet, j’ai pu mettre en place un pipeline CI/CD qui a servi pour le test de code ainsi que pour le déploiement. C’est au sein de celui-ci qu’a été instauré un job de scan d’image avant le déploiement.
Sur cette étape du pipeline, le job échouait en cas de détection de CVEs non whitelistesés pour assurer que les images déployées n’avaient pas de failles connues détectables au moment du déploiement.
Cet élément est justement le thème du prochain article de la série.
Conclusion
Vous voici maintenant éclairés sur la notion de supply chain poisoning. Avec un développement orienté « Security by design », en intégrant les notions de bonnes pratiques ainsi que les outils d’analyse de sécurité dans le pipeline, il est possible de réduire ce risque.
Une maitrise avancée du risque de SCP est synonyme d’un niveau de maturité fort en contrôle des risques cyber d’un produit. Outre une bonne organisation interne, il existe également des outils qui permettent de prévenir ce type d’attaques en empêchant le déploiement d’images basées sur des images non approuvées ou en proposant des techniques de sandboxing pour détecter des comportements dangereux.
Ce sont des outils que nous aurons l’occasion de parcourir ensemble, notamment dans le prochain article.
Je te donne rendez-vous dans notre prochain volet sur la sécurité des conteneurs : « Technique d’analyse et de patch de CVE » !
[1] Ce qui n’empêche pas de scanner et de patcher les images officielles qui ne sont pas exempte de failles elles aussi !
[2] Dans le cas de Docker, nous parlons du Dockerfile
par Cédric PAOLI, Consultant Cybersécurité
