Série Coders Conquer Security Infrastructure as Code - Utilisation de composants provenant de sources non fiables

Nous approchons de la fin de notre série sur l'Infrastructure as Code, et nous avons été ravis d'accompagner des développeurs comme vous dans leur parcours de sécurité IaC.

Avez-vous participé aux défis ? Quel est votre score jusqu'à présent ? Avant de commencer, voyons ce que vous savez déjà sur les pièges liés à l'utilisation de composants provenant de sources non fiables :

Vous avez encore des progrès à faire ? Lisez la suite :

Le comportement vulnérable sur lequel nous allons nous pencher aujourd'hui est l'utilisation de code provenant de sources non fiables, une pratique apparemment anodine qui cause de sérieux problèmes. L'utilisation de code et de ressources open source présente de nombreux avantages. En général, cela permet aux experts de contribuer avec leurs idées, leur travail et même du code complet sur des dépôts comme GitHub, afin qu'ils soient utilisés par d'autres personnes ayant des difficultés à faire fonctionner correctement un programme ou une application. Utiliser du code déjà prêt pour gérer les fonctions d'un programme évite aux développeurs de devoir réinventer la roue à chaque fois qu'ils créent une nouvelle application.

Cependant, l'utilisation d'extraits de code provenant de sources peu fiables, non vérifiées, voire potentiellement dangereuses, comporte de nombreux risques. En fait, l'utilisation de code provenant de sources non fiables est l'un des moyens les plus courants par lesquels des vulnérabilités de sécurité, majeures ou mineures, s'introduisent dans des applications par ailleurs sécurisées. Parfois, ces vulnérabilités sont introduites accidentellement par leurs créateurs. Il existe également des cas où du code malveillant a été écrit par des attaquants potentiels. Ce code est ensuite partagé dans l'espoir de piéger des victimes qui l'intégreront dans leurs applications.

Pourquoi l'utilisation de code provenant de sources non fiables est-elle dangereuse ?

Imaginons qu'un développeur soit pressé et doive configurer une application en cours de développement. C'est un processus délicat. Au lieu de passer beaucoup de temps à essayer de trouver chaque configuration possible, il effectue une recherche Google et trouve quelqu'un qui a déjà réalisé un fichier de configuration apparemment parfait. Bien que le développeur ne sache rien de l'auteur du code, l'ajouter à une nouvelle application est relativement simple. Cela peut être fait dans l'environnement Docker en deux lignes :

RUN cd /etc/apache2/sites-available/ && \
   wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
   9d372cfa8855a6be74bcca86efadfbbf/raw/\
   fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Désormais, l'image Docker récupérera dynamiquement le fichier de configuration tiers. Et même si le fichier est testé et jugé sûr au moment de l'intégration, le fait que le pointeur soit désormais intégré au code de la nouvelle application crée une dépendance permanente. Quelques jours, semaines ou mois plus tard, le fichier pourrait être modifié par l'auteur original ou par un attaquant ayant compromis le dépôt de code. Soudainement, le fichier de configuration partagé peut ordonner à l'application de se comporter très différemment de ce qui était prévu, permettant potentiellement l'accès à des utilisateurs non autorisés, voire volant et exfiltrant directement des données.

Une meilleure façon d'utiliser les ressources partagées

Si votre organisation autorise l'utilisation de code provenant de sources externes, des processus doivent être mis en place pour garantir que cela se fasse en toute sécurité. Lors de l'évaluation d'un code externe, assurez-vous de ne récupérer des composants qu'auprès de sources officielles et via des liens sécurisés. Même dans ce cas, vous ne devriez jamais créer de lien vers une source externe pour récupérer ce code, car cela vous fait perdre le contrôle du processus. Au lieu de cela, le code approuvé doit être importé dans une bibliothèque sécurisée et utilisé uniquement à partir de cet emplacement protégé. Dans un environnement Docker, le code ressemblerait donc à ceci :

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

Au lieu de dépendre de fichiers de configuration tiers distants, cette méthode repose sur une copie locale de ces fichiers. Cela empêchera toute modification inattendue ou malveillante.

En plus d'utiliser une bibliothèque de code sécurisée, un processus de gestion des correctifs doit être mis en place pour surveiller en permanence les composants tout au long du cycle de vie du logiciel. Tous les composants côté client et côté serveur doivent également être vérifiés pour détecter les alertes de sécurité à l'aide d'outils comme NVD ou CVE. Enfin, supprimez toutes les dépendances et fonctionnalités inutilisées ou superflues qui pourraient accompagner le code externe.

En suivant ces étapes, les développeurs peuvent utiliser plus sereinement des ressources externes sans introduire accidentellement des vulnérabilités dans leurs applications et leur code.

Consultez les pages du blog de Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre les ravages d'autres failles de sécurité. Vous pouvez également essayer une démo des défis IaC sur la plateforme de formation Secure Code Warrior pour garder toutes vos compétences en cybersécurité aiguisées et à jour.