Les packages NPM malveillants contiennent un voleur d’informations Vidar

Du code malveillant continue d’être téléchargé dans des référentiels open source, ce qui rend difficile pour les développeurs responsables de faire confiance à ce qui s’y trouve, et pour les RSSI de faire confiance aux applications qui incluent du code open source.

Le dernier exemple vient des chercheurs de Datadog Security, qui ont déclaré avoir trouvé le mois dernier 17 packages (23 versions) dans le référentiel npm contenant des logiciels malveillants de téléchargement pour les systèmes Windows qui s’exécutent via un script de post-installation.

Les packages associés se font passer pour des packages d’assistance de robot Telegram, des bibliothèques d’icônes ou des forks apparemment légitimes de projets préexistants tels que Cursor et React. Ils fournissent des fonctionnalités légitimes, mais leur objectif réel est d’exécuter le malware Vidar infostealer sur le système de la victime. Datadog estime qu’il s’agit de la première divulgation publique d’un malware Vidar diffusé via des packages npm.

Les deux comptes proposant ces forfaits (aartje et saliii229911 ) ont depuis été interdits. Cependant, ils sont restés dans le registre pendant environ deux semaines et les packages malveillants ont été téléchargés au moins 2 240 fois. Cependant, les chercheurs pensent qu’un grand nombre de ces téléchargements ont probablement été effectués par des grattoirs automatisés, certains se produisant après que les packages aient été supprimés et remplacés par des packages de sécurité vides.

Toutes sortes de choses désagréables

Une compromission malveillante des composants open source peut conduire à toutes sortes de choses désagréables. Premièrement, les acteurs malveillants peuvent voler les identifiants des développeurs et insérer des portes dérobées dans leur code. Deuxièmement, le code malveillant contenu dans le composant téléchargé lui-même pourrait se propager dans le monde entier jusqu’aux clients du développeur.

La découverte de Datadog n’est qu’un autre parmi une longue liste 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 packages 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 de vol d’informations d’identification. Le même mois, des chercheurs de l’Aïkido ont signalé que 18 packages npm très populaires et hautement téléchargés avaient été contaminés.

« Je ne sais pas comment résoudre facilement ce problème sans avoir besoin d’une vue complète de la sécurité de tout code nouvellement soumis, et ce n’est ni rapide, ni bon marché, ni facile », a commenté Roger Grimes, conseiller RSSI en matière de défense numérique chez KnowBe4.

« Mais c’est vraiment la seule réponse si vous voulez un code source fiable, sûr et open source. »

Ironiquement, dit-il, l’une des principales raisons invoquées pour justifier l’utilisation du code open source est qu’il est facilement révisable, de sorte que tout le monde peut le consulter pour détecter et détecter les vulnérabilités. « Mais la réalité est que presque personne dans le domaine de la sécurité n’examine les dizaines de millions de lignes de code open source », a-t-il souligné.

« Des dizaines de projets open source ont tenté de mettre en œuvre davantage de révisions de code par défaut et tous ont échoué », a-t-il déclaré. « L’une de mes citations préférées de tous les temps est : « Demander aux utilisateurs de consulter le code open source avant de l’utiliser, c’est comme demander aux passagers d’un avion de ligne de sortir de l’avion et de l’examiner pour des raisons de sécurité du vol avant de voler. » Je ne sais pas qui a dit cela en premier, mais c’est un brillant résumé des raisons pour lesquelles la révision volontaire du code open source ne fonctionne vraiment pas.

Typosquattage

L’une des tactiques préférées des acteurs malveillants qui tentent d’infecter la chaîne d’approvisionnement des logiciels open source est le typosquatting, la création de packages portant des noms similaires à ceux de packages légitimes pour tromper les développeurs involontaires recherchant une bibliothèque particulière. 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 », « dajngo », pour tromper les développeurs à la recherche de la populaire bibliothèque Python « django ».

Les RSSI doivent veiller à ce que les employés soient informés du problème du typosquatting et sachent ce qu’il faut rechercher. Les services informatiques doivent conserver un inventaire complet des composants utilisés par tous les logiciels approuvés sur lesquels des audits peuvent être effectués, afin de garantir que seuls les composants approuvés sont en place. Cet inventaire et cet audit doivent être effectués pour valider tout nouveau composant introduit.

Que faire de plus ?

Les conseils ne manquent pas pour les développeurs et les responsables informatiques et de sécurité de l’information pour les aider à éviter d’être victimes de packages malveillants dans les référentiels open source.

Une tactique consiste à inclure une nomenclature logicielle dans chaque application acquise par un service informatique. Grâce à lui, les équipes DevOps/DevSecOps peuvent suivre les composants logiciels, identifier les vulnérabilités et garantir la conformité.

En 2021, l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) et l’Institut national américain des normes et de la technologie (NIST) ont publié un avis, fournissant des conseils pour la création d’applications open source sécurisées. Cela commence par la création d’un programme formel de gestion des risques liés à la chaîne d’approvisionnement pour garantir que les risques liés à la chaîne d’approvisionnement reçoivent une attention dans toute l’organisation, même parmi les cadres et les gestionnaires des opérations et le personnel dans les rôles de soutien, tels que l’informatique, les acquisitions, les services juridiques, la gestion des risques et la sécurité.

Une organisation peut réduire sa surface d’attaque logicielle grâce à la gestion de la configuration, indique l’avis, qui comprend :

• placer les configurations sous contrôle des modifications ;
• effectuer des analyses d’impact sur la sécurité ;
• mettre en œuvre les directives fournies par le fabricant pour renforcer les logiciels, les systèmes d’exploitation et les micrologiciels ;
• • tenir à jour un inventaire des composants du système d’information.

De plus, l’Open Source Web Application Security Project (OWASP) offre ce conseil aux développeurs utilisant npm :

• examinez et effectuez toujours une vérification diligente sur les modules tiers que vous installez pour confirmer leur santé et leur crédibilité ;
• attendre les mises à niveau immédiates vers les nouvelles versions ; laissez aux nouvelles versions de packages un certain temps pour circuler avant de les essayer.
• avant la mise à niveau, assurez-vous de consulter les journaux de modifications et les notes de publication de la version mise à niveau.
• lors de l’installation de packages, assurez-vous d’ajouter le suffixe pour désactiver l’exécution de tout script par des packages tiers.
• envisagez de l’ajouter au fichier de projet .npmrc ou à la configuration globale npm.

Enfin, Andrew Krug, responsable du plaidoyer en matière de sécurité chez Datadog, a proposé ces conseils supplémentaires :

• donner aux développeurs la possibilité d’installer une analyse des packages en temps réel lors de l’installation ;
• se prémunir contre le typosquatting et la confusion des dépendances en donnant la priorité à l’utilisation de référentiels de packages internes comme garde-fou pour les packages approuvés ;
• tenir à jour les nomenclatures des logiciels ;
• Déployez SCA (analyse de la composition logicielle) à chaque phase du cycle de vie du développement logiciel. Les outils SCA traditionnels n’analysent que périodiquement les instantanés de code, a-t-il déclaré, mais une détection efficace doit être complétée par une visibilité en temps réel sur les services déployés, y compris la production, afin de redéfinir les priorités des problèmes et de se concentrer sur ceux exposés dans des environnements sensibles.