73 nouvelles extensions frauduleuses ont été ajoutées ce mois-ci, selon les chercheurs de Socket, alors que les attaques contre la chaîne d’approvisionnement se poursuivent.
L’acteur malveillant qui sème le marché du code Open VSX avec des extensions frauduleuses qui téléchargent le malware GlassWorm a téléchargé 73 liens supplémentaires usurpés d’identité, alors que sa tentative d’infecter les chaînes d’approvisionnement logicielles se poursuit.
Philipp Burckhardt, responsable du renseignement sur les menaces chez Socket, qui a révélé la dernière activité, l’a qualifié d’« escalade significative » de l’activité du gang, après que celui-ci ait ajouté 72 extensions malveillantes le mois dernier.
Les extensions usurpent l’identité d’outils de développement fiables. Plus récemment, les extensions répertoriées contiennent du code inoffensif et échapperont donc aux scanners de logiciels malveillants. Plus tard, après s’être connectés automatiquement au GitHub nouvellement créé ou à d’autres comptes publics, ils téléchargent GlassWorm sur les ordinateurs des développeurs en tant que mise à jour. Cette dernière vague inclut certaines extensions qui s’appuient sur des binaires natifs groupés.
« L’extension elle-même agit comme un chargeur léger », explique Socket dans son rapport. « En déplaçant la logique critique en dehors de ce que les outils analysent habituellement et en la répartissant sur plusieurs mécanismes de diffusion, l’acteur malveillant augmente la probabilité d’échapper à la détection. »
Sur les 73 nouvelles extensions vues par Socket la semaine dernière, six ont été activées pour se connecter à des sources de malwares. Cette semaine, huit autres ont été activés, a déclaré Burckhardt dans une interview.
Socket a informé la Fondation Eclipse, qui supervise le marché Open VSX, des derniers ajouts frauduleux, et Burckhardt s’attend à ce que les 73 aient désormais été supprimés.
Mais les attaques continues sont un autre exemple de la manière dont les acteurs malveillants tentent d’utiliser les marchés de code ouvert utilisés par les développeurs, tels que Open VSX et npm, pour compromettre les applications au fur et à mesure de leur création, afin de permettre la distribution ultérieure de logiciels malveillants volant des données.
(Contenu associé : Le malware GlassWorm se propage via un abus de dépendance)
Les extensions sont des modules complémentaires qui aident les développeurs à accélérer la création d’applications. Étant donné que Visual Studio Code de Microsoft est l’un des éditeurs de code les plus courants dans le monde, les extensions VS Code sont une cible tentante pour les acteurs malveillants. Les extensions populaires incluent des utilitaires qui font tout, depuis l’analyse de JavaScript, TypeScript et d’autres langages pris en charge pour détecter des erreurs potentielles, jusqu’aux outils d’IA qui suggèrent des complétions de code. La Fondation Eclipse affirme que le registre Open VSX héberge plus de 12 000 extensions provenant de plus de 8 000 éditeurs.
Une lacune systémique dans la sécurité de l’environnement de développement
GlassWorm, malgré son nom, n’est pas un ver, mais un chargeur. Selon StepSecurity, la charge utile de l’étape 3 de GlassWorm comprend un module dédié au vol d’informations d’identification qui récupère les jetons GitHub et npm à partir de plusieurs sources. L’attaquant utilise ensuite ces informations d’identification pour forcer l’envoi de logiciels malveillants dans tous les référentiels de la victime.
Le chargeur inclut un contrôle d’hôte qui détecte et annule le lancement de logiciels malveillants sur les ordinateurs en langue russe, laissant Burckhardt soupçonner que les acteurs de la menace derrière cette campagne sont russes.
Tanya Janca, qui enseigne le codage sécurisé dans son entreprise SheHacksPurple, a observé : « ce qui rend la campagne GlassWorm particulièrement dangereuse et intéressante, c’est qu’elle révèle une lacune systémique dans la façon dont nous sécurisons les environnements des développeurs. »
« Avec les progiciels, nous avons des fichiers de verrouillage, des hachages épinglés et des versions reproductibles. Avec les extensions IDE (environnement de développement intégré), nous n’avons presque rien. Il n’y a pas de vérification d’intégrité, pas d’équivalent de package-lock.json, et la plupart des organisations n’ont aucune politique régissant ce que les développeurs sont autorisés à installer dans leurs IDE. «
Des acteurs malveillants ont remarqué l’écart. Pour eux, le ciblage des extensions VS Code est une surface d’attaque moins difficile que le ciblage des packages, a-t-elle déclaré, en particulier parce que les contrôles que les organisations ont passé des années à construire autour de leurs pipelines de dépendances n’existent tout simplement pas pour les extensions.
La raison pour laquelle seules certaines des 73 extensions ont été activées avant la propagation de l’avertissement est certainement délibérée, a ajouté Janca. « Cela ressemble à un déploiement intentionnel : publiez-les tous largement pour établir la crédibilité et accumuler les téléchargements, puis activez les sous-ensembles nuisibles au fil du temps pour éviter de déclencher une détection massive et pour préserver une réserve d’actifs prêts si certains sont supprimés ou remarqués.
Conseils aux développeurs
Janca a déclaré que les développeurs qui souhaitent réduire leur exposition à la campagne GlassWorm devraient commencer par les bases : installer moins d’extensions et traiter chacune d’entre elles comme une dépendance comportant un risque réel. Désactivez la mise à jour automatique afin de contrôler le moment où les mises à jour sont appliquées et d’évaluer soigneusement chacune d’entre elles. Utilisez un outil SCA de nouvelle génération qui couvre les extensions IDE et d’autres domaines de la chaîne d’approvisionnement, et pas seulement les packages et composants tiers.
« Une chose que la plupart des gens négligent », a-t-elle ajouté : « Vérifiez ce que vous avez déjà installé. Les extensions s’accumulent au fil des ans et le développeur qui a construit cette extension en 2022 n’est peut-être pas la même personne qui la gère aujourd’hui. «
Les équipes qui souhaitent des garanties plus solides devraient utiliser un outil de surveillance comportementale qui surveille l’activité d’exécution, a déclaré Janca, et pas seulement le contenu au moment de l’installation. Établissez un processus d’approbation formel pour les nouvelles extensions, avec approbation de sécurité. Maintenez une liste verte d’extensions approuvées et n’installez pas à partir de marchés alternatifs comme Open VSX sans la traiter comme une source à plus haut risque.
« La même discipline que nous appliquons aux packages open source doit être appliquée aux outils présents dans nos IDE et au reste de notre chaîne d’approvisionnement logicielle », a-t-elle déclaré.
Former les développeurs à reconnaître les signes
Les développeurs devraient également être limités dans ce qu’ils peuvent télécharger, a-t-il ajouté, en particulier les extensions nouvellement ajoutées à un référentiel. Il peut également être nécessaire de désactiver la possibilité de télécharger automatiquement les mises à jour des extensions, a-t-il déclaré, et les développeurs doivent être avertis de ne télécharger que les extensions dont ils ont besoin, et non celles avec lesquelles expérimenter.
Et pour aider à détecter les problèmes d’Open VSX, la Fondation Eclipse a annoncé plus tôt ce mois-ci le programme de reconnaissance des chercheurs en sécurité Open VSX pour encourager la divulgation responsable des vulnérabilités.
