Des codes malveillants continuent d'être téléchargés dans des référentiels open source, ce qui rend difficile pour les développeurs responsables de faire confiance à leur contenu et pour les RSSI aux applications qui incluent du code open source. Dernier exemple en date : la découverte par des chercheurs en sécurité de Datadog le mois dernier dans le référentiel npm de 17 paquets (23 versions) contenant un malware pour les systèmes Windows qui s'exécute via un script de post-installation. Usant de typosquatting, les paquets associés se font passer pour ceux d'aide aux bots Telegram, de bibliothèques d'icônes ou de forks apparemment légitimes de projets préexistants tels que Cursor et React. Ces paquets offrent des fonctionnalités légitimes, mais leur objectif réel est d'exécuter l’infostealer Vidar sur le système de la victime. Datadog estime qu'il s'agit de la première divulgation publique du logiciel malveillant Vidar distribué via des paquets npm. Depuis, les deux comptes proposant ces paquets (aartje et saliii229911) ont été bannis. Mais, ils sont restés dans le registre pendant environ deux semaines, et les paquets malveillants ont été téléchargés au moins 2 240 fois. Les chercheurs pensent cependant que bon nombre de ces téléchargements ont probablement été effectués par des scrapers automatisés, certains ayant eu lieu après que les paquets ont été supprimés et remplacés par des paquets de sécurité vides.

Le typosquatting, c'est-à-dire la création de paquets dont les noms sont similaires à ceux de paquets officiels afin de tromper les développeurs qui recherchent une bibliothèque particulière, est l’une des tactiques préférées des acteurs malveillants qui tentent d'infecter la chaîne d'approvisionnement des logiciels open source. Par exemple, en 2018, un chercheur a découvert que des acteurs malveillants avaient créé de fausses bibliothèques dans le référentiel Python appelées « diango », « djago » et « dajngo » afin de tromper les développeurs qui recherchaient la célèbre bibliothèque Python « django ». Les RSSI doivent s'assurer que les employés sont au fait de ce problème de typosquatting et qu’ils savent ce qu'ils doivent rechercher. Les services IT doivent tenir un inventaire complet des composants utilisés par tous les logiciels approuvés, sur la base duquel des audits peuvent être effectués, afin de s'assurer que seuls les composants approuvés sont en place. Cet inventaire et cet audit doivent être effectués pour valider tout nouveau composant introduit.

Des conséquences fâcheuses

La compromission malveillante de composants open source peut entraîner toutes sortes de choses désagréables. Tout d'abord, les auteurs de la menace peuvent voler les identifiants des développeurs et insérer des portes dérobées dans leur code. Ensuite, le code malveillant contenu dans le composant téléchargé peut se propager dans le monde entier et atteindre les clients du développeur. La découverte de Datadog n'est qu'un exemple parmi d'autres de codes malveillants téléchargés sur npm, PyPI, GitHub et d'autres référentiels open source. La semaine dernière, Koi Security a signalé avoir trouvé 126 paquets malveillants dans npm, et en septembre, les chercheurs de Step Security ont signalé que des dizaines de bibliothèques npm avaient été remplacées par du code permettant de voler des identifiants. Le même mois, les chercheurs d'Aikido ont signalé que 18 paquets npm très populaires et téléchargés avaient été contaminés. « Je ne vois pas comment résoudre facilement ce problème sans une vue complète de la sécurité de tout nouveau code soumis, et ce n'est ni rapide, ni bon marché, ni facile », a commenté Roger Grimes, conseiller en sécurité informatique chez KnowBe4. « Mais c'est vraiment la seule solution si l’on veut un code open source fiable et sûr », a-t-il ajouté.

« Paradoxalement, l'une des principales raisons invoquées pour inciter à utiliser du code open source, c’est de dire qu'il est aisément vérifiable, de sorte que n'importe qui peut le consulter pour détecter et corriger les vulnérabilités », a-t-il souligné. « Sauf que, en réalité, presque personne ne vérifie la sécurité des dizaines de millions de lignes de code open source », a-t-il fait remarquer. « Des dizaines de projets open source ont tenté de mettre en place davantage de révisions de code par défaut, mais tous ont échoué », a-t-il rappelé. « L'une de mes citations préférées à ce sujet est la suivante : demander aux utilisateurs de réviser le code open source avant de l'utiliser revient à demander aux passagers d'un avion de descendre de l'appareil et de vérifier sa sécurité avant le décollage. Je ne sais pas qui est le premier à avoir dit cela, mais ça résume parfaitement les raisons pour lesquelles la révision volontaire du code open source ne fonctionne pas. »

Des actions correctives possibles

Les conseils ne manquent pas pour éviter aux développeurs et responsables IT et du SI pour éviter qu’ils ne soient victimes de paquets malveillants dans les référentiels open source. Une tactique consiste à inclure une nomenclature logicielle dans chaque application acquise par un service IT. Grâce à elle, les équipes DevOps/DevSecOps peuvent suivre les composants logiciels, identifier les vulnérabilités et garantir la conformité. Dans un avis intitulé « Defending Against Software Supply Chain Attacks » (Se défendre contre les attaques de la chaîne d'approvisionnement logicielle), et publié en 2021, l'Agence américaine de cybersécurité et de sécurité des infrastructures (Cybersecurity and Infrastructure Security Agency, CISA) et le National Institute for Standards and Technology (NIST) proposent plusieurs conseils pour créer des applications open source sécurisées. En premier lieu, elles suggèrent de créer un programme officiel de gestion des risques liés à la chaîne d'approvisionnement afin de garantir que ces risques soient pris en compte dans toute l’entreprise, y compris par les cadres et les responsables des opérations et du personnel occupant des fonctions de soutien, comme l’IT, les acquisitions, le service juridique, la gestion des risques et la sécurité.

Selon l'avis, il est possible de réduire sa surface d'attaque logicielle grâce à la gestion de la configuration, laquelle comprend :

- La mise en place d'un contrôle des modifications des configurations ;
- Des analyses d'impact sur la sécurité ;
- La mise en œuvre des directives fournies par les fabricants pour renforcer la sécurité des logiciels, des systèmes d'exploitation et des firmwares ;
- La tenue d'un inventaire des composants du système d'information.

Par ailleurs, l'Open Source Web Application Security Project (OWASP) conseille aux développeurs qui utilisent npm :

- De toujours vérifier et effectuer les contrôles nécessaires sur les modules tiers qu’ils prévoient d’installer afin de confirmer leur état et leur crédibilité ;
- De ne pas procéder immédiatement à la mise à niveau vers les nouvelles versions ; de laisser les nouvelles versions des paquets circuler pendant un certain temps avant de les essayer ;
- Avant de procéder à la mise à niveau, de veiller à consulter les journaux des modifications et les notes de mise à jour de la version mise à niveau ;
- De veiller à ajouter le suffixe ignore-scripts afin de désactiver l'exécution de tout script par des paquets tiers lors de l'installation de paquets ;
- D’envisager l’ajout de ignore-scripts au fichier de projet .npmrc ou à la configuration globale npm.

Enfin, Andrew Krug, responsable de la sécurité chez Datadog, recommande encore :

 - De donner aux développeurs la possibilité d'installer un scan des paquets en temps réel lors de l'installation ;
- De se protéger contre le typosquatting et la confusion des dépendances en privilégiant l'utilisation de référentiels de paquets internes comme garde-fou pour les paquets approuvés ;
- De maintenir des nomenclatures logicielles ;
- De déployer l'analyse de la composition logicielle (Software Composition Analysis, SCA) à chaque phase du cycle de vie du développement logiciel. « Les outils SCA traditionnels n'analysent que périodiquement des instantanés de code », a fait remarquer M. Krug, « or, une détection efficace doit être complétée par une visibilité en temps réel sur les services déployés, y compris en production, afin de redéfinir les priorités et de se concentrer sur les problèmes exposés dans des environnements sensibles ».