La chaîne logistique logicielle est un élément essentiel du cycle de vie des applications et des sites web. Les interdépendances et les composants courants dans le développement logiciel moderne peuvent accroître la surface d’attaque et parfois permettre aux hackers de contourner les solides couches de sécurité que vous avez ajoutées à votre infrastructure.
En effet, une seule faille dans le code source peut suffire à compromettre toute la chaîne logistique. Le problème, c’est que les projets modernes comptent énormément de dépendances. Cette situation est connue sous le nom d’« enfer des dépendances », car vos dépendances ont leurs propres dépendances, et ainsi de suite. Essayer de retracer toutes ces dépendances pourrait vous rendre fou.
En outre, le développement logiciel repose largement sur des plateformes open source et des fournisseurs tiers, tout simplement parce que cela accélère le processus et fournit aux développeurs des bibliothèques standard. Un grand nombre de personnes ou d’organisations assurent la maintenance du code, ce qui rend la prévention des failles de sécurité particulièrement difficile.
Cela est peut-être nulle part plus évident que dans les gestionnaires de paquets. Récemment, le dépôt de paquets RubyGems a corrigé une vulnérabilité récemment enregistrée sous le nom de CVE-2022-29176. RubyGems.org est LE service d’hébergement de gems de la communauté Ruby, tout comme NPM est le registre officiel de l’écosystème JavaScript.
Ces plateformes gigantesques hébergent des centaines de milliers de paquets, avec des millions de téléchargements, et sont constamment attaquées. Les hackers tentent régulièrement des attaques par détournement, confusion de dépendances ou typosquattage, et il existe même un risque d’auto-sabotage désormais.
À lire également : Comment les hackers compromettent la chaîne logistique logicielle
Coup d’œil sur la vulnérabilité de RubyGems
La faille CVE-2022-29176 a été découverte sur RubyGems.org, le registre de paquets de toute la communauté du langage de programmation Ruby, et permettait à « n’importe quel utilisateur de supprimer et de remplacer certains gems, même s’il n’était pas autorisé à le faire ».
Certaines conditions supplémentaires s’appliquaient toutefois : le gem, autrement dit le paquet Ruby, « devait comporter un ou plusieurs tirets dans son nom au cours de sa création dans les 30 jours OU n’avoir reçu aucune mise à jour depuis plus de 100 jours ». Il pouvait cependant correspondre à de nombreux gems présents sur la plateforme.
Un acteur malveillant pouvait remplacer le contenu d’un gem légitime par un script destiné à voler des identifiants ou à installer un mineur de cryptomonnaie : une vulnérabilité critique.
RubyGems.org n’a reçu aucune plainte de la part des propriétaires de gems, ce qui laisse penser que la vulnérabilité critique n’a probablement pas encore été exploitée. Quoi qu’il en soit, Bundler, le gestionnaire de paquets de Ruby, recommande d’utiliser « Bundler en mode verrouillé--frozen or --deployment en CI et lors du déploiement. »
Cette bonne pratique empêche votre application Ruby de basculer silencieusement vers une version détournée, ce que les hackers cherchent précisément à obtenir avec ce type d’exploit.
Les utilisateurs qui doivent vérifier si leur application a été victime d’exploits par le passé peuvent examiner le fichier Gemfile.lock et rechercher des changements de plateforme indésirables survenus dans les gems alors que le numéro de version n’avait pas changé.
À lire également : SBOM : sécuriser la chaîne logistique logicielle
Les plateformes sont vulnérables aux attaques
Qu’il s’agisse de RubyGems, de NPM ou même de pip pour les paquets Python, ces grandes plateformes constituent des éléments essentiels de la chaîne logistique logicielle. NPM fait régulièrement la une de l’actualité en raison de diverses campagnes qui touchent des millions de projets et d’utilisateurs.
L’équipe JFrog Security Research a récemment détecté une nouvelle attaque visant la chaîne logistique de NPM, similaire à une attaque déjà signalée sur Azure. Les hackers ont utilisé une attaque par confusion de dépendances en ciblant des entreprises industrielles allemandes : Bertelsmann, Bosch, Stihl et DB Schenker.
Les chercheurs ont déclaré qu’il s’agissait d’une attaque « très ciblée ». Jfrog a mis à jour son article pour préciser qu’ils ne pouvaient pas déterminer, au moment de la rédaction, s’il s’agissait d’un véritable acteur malveillant ou d’un pentester « très agressif » à l’origine de l’attaque.
Divers IoC (indicateurs de compromission) ont été relevés, mais les hackers n’ont pas pris le temps de masquer le nom de leur cible sur NPM et ont utilisé un outil public d’obfuscation facilement détectable et réversible, ce qui semble plutôt inhabituel pour des cybercriminels.
La confusion de dépendances consiste à utiliser les noms de paquets privés pour créer des paquets publics portant un numéro de version plus élevé. Lorsque les utilisateurs lancent une installation ou une mise à jour, le gestionnaire de paquets s’emmêle et récupère ce qui semble être le paquet le plus récent.
Les hackers qui souhaitent attaquer la chaîne logistique disposent de nombreuses possibilités. La confusion de dépendances et le typosquattage sont des techniques ingénieuses, mais pas forcément les plus faciles à mettre en œuvre.
Voler les identifiants des propriétaires ou des mainteneurs peut être une approche plus pratique, car les attaquants peuvent usurper l’identité d’utilisateurs légitimes pour commettre toutes sortes d’abus, notamment distribuer des logiciels malveillants ou des portes dérobées sur des millions d’installations.
À lire également : Principaux outils de débogage et de sécurisation du code
Comment se protéger contre les attaques visant la chaîne logistique
La plupart du temps, la meilleure chose à faire est d’atténuer une menace visant la chaîne logistique, mais certaines mesures simples permettent de réduire les risques :
- suivre les bonnes pratiques de déploiement et d’intégration continue (par exemple, les recommandations de Bundler)
- effectuer régulièrement des contrôles et des audits de sécurité, et ne jamais déployer en production un élément qui n’a pas été testé
- enregistrer un registre public sous le nom de votre registre privé afin de prévenir toute attaque par typosquattage
- adopter une politique plus stricte vis-à-vis des fournisseurs (par exemple, utiliser le numéro de version exact plutôt que « * » ou « ^ » afin d’empêcher toute mise à jour silencieuse lors des installations)
- si vous êtes propriétaire ou mainteneur d’un paquet, activer l’authentification multifacteur
- ne jamais déployer de fichiers de configuration ni de sourcemaps en production
- maintenir toutes les dépendances à jour
Le dernier point peut sembler quelque peu paradoxal, car les hackers tentent de compromettre les mécanismes de mise à jour pour inciter leurs victimes à déployer des logiciels malveillants. Cependant, l’évolution des menaces est trop rapide pour négliger les correctifs de sécurité. Les composants obsolètes sont parmi les tout premiers éléments que les hackers vérifieront pour voir s’ils peuvent exploiter une vulnérabilité connue.
La chaîne logistique logicielle est semée d’embûches, et pourtant ces ressources externes sont importantes pour accélérer le développement et standardiser les pratiques. En tant que développeur, vous ne pouvez pas contrôler le code que vous ne maintenez pas — et, de nos jours, la majeure partie du code de votre projet n’est pas la vôtre. La meilleure réponse consiste à rester au fait de vos pratiques de sécurité.
À lire ensuite : Meilleurs outils de gestion des risques liés aux tiers (TPRM)