Les acteurs malveillants diffusent des extensions malveillantes via les VS Marketplaces

Des développeurs imprudents publiant des extensions Visual Studio sur deux marchés ouverts ont inclus des jetons d’accès et d’autres secrets qui peuvent être exploités par des acteurs malveillants, a découvert un fournisseur de sécurité.

La découverte a été faite plus tôt cette année par des chercheurs de Wiz, qui ont discrètement travaillé avec Microsoft et son marché VSCode ainsi qu’avec ceux à l’origine du marché OpenVSX pour améliorer les garde-fous de leurs plates-formes. Il a publié cette semaine un rapport sur son enquête.

Wiz a trouvé plus de 550 secrets validés, répartis sur plus de 500 extensions provenant de centaines d’éditeurs d’extensions VS. Ils comprenaient des secrets de fournisseurs d’IA pour des plates-formes telles que OpenAI, Gemini, Anthropic, xAI, DeepSeek, HuggingFace et Perplexity ; secrets de plate-forme professionnelle à haut risque pour AWS, Github, Stripe, Auth0 et Google Cloud Platform ; et les secrets de base de données pour MongoDB, Postgres et Supabase.

Plus de 100 jetons d’accès personnels Azure DevOps valides ayant fait l’objet d’une fuite ont été identifiés dans les extensions VSCode Marketplace. Ensemble, ils représentaient une base d’installation de plus de 85 000 installations d’extensions.

Plus de trente jetons d’accès OVSX divulgués ont été identifiés, dans les extensions VSCode Marketplace ou OVSX. Ensemble, ils représentaient plus de 100 000 installations d’extensions.

Le plus grand contributeur aux fuites de secrets a été le regroupement par les développeurs de fichiers cachés, également connus sous le nom de dotfiles, indique le rapport. La quantité de fichiers .env était particulièrement importante, même si les informations d’identification codées en dur dans le code source de l’extension étaient également répandues.

Au cours de l’enquête Wiz, les chercheurs ont constaté une augmentation des fuites de secrets via des fichiers de configuration liés à l’IA, notamment config.json, mcp.json ; et .cursorrules. D’autres sources courantes incluent les configurations de build (par exemple, package.json) et la documentation telle que README.md.

Microsoft et Wiz ont lancé une campagne de notification pour alerter les éditeurs concernés et les aider à remédier à ces vulnérabilités. Microsoft a également intégré des fonctionnalités d’analyse des secrets avant la publication des extensions sur son marché, et bloque désormais les extensions avec des secrets vérifiés, avertissant les propriétaires d’extensions lorsque des secrets sont détectés. Les détails sont dans une annonce de juin.

OpenVSX ajoute également un préfixe (ovsxp_) à ses jetons.

« Nous avons constaté que les éditeurs ne considéraient souvent pas que tout le contenu du package était accessible au public, ou ne parvenaient pas à nettoyer leurs extensions de secrets codés en dur », a déclaré Wiz dans son rapport.

Pire encore, certains acteurs malveillants ont réalisé qu’il existait une opportunité de profiter de ces marchés pour empoisonner la chaîne d’approvisionnement des extensions, tout comme ils ont tenté ces dernières années, avec succès dans de nombreux cas, d’implanter du code malveillant dans le NPM, GitHub et d’autres référentiels de code ouvert. L’enquête Wiz a été déclenchée par la découverte en février que des acteurs malveillants avaient tenté d’introduire des logiciels malveillants dans le VSCode Marketplace dans le cadre d’une attaque classique de la chaîne d’approvisionnement qui aurait pu se propager largement.

Un attaquant qui aurait découvert cette faiblesse dans la sécurité de la plateforme aurait été en mesure de distribuer directement des logiciels malveillants aux 150 000 installations cumulées, indique le rapport de Wiz.

Les développeurs sont des cibles privilégiées

Les développeurs sont une cible privilégiée des attaques, a commenté Johannes Ullrich, doyen de la recherche à l’Institut SANS. « Ce qu’ils ne réalisent souvent pas, c’est que les extensions qu’ils installent, même si elles semblent inoffensives, comme, par exemple, les extensions permettant de changer la couleur du code, ont un accès complet à leur code et peuvent apporter des modifications sans en informer explicitement le développeur. Les marchés d’extensions ne sont qu’un autre référentiel de code tiers. Ils souffrent du même manque de surveillance et d’examen que les autres référentiels de code (par exemple, pip, npm, NuGet et autres). Lors de l’installation de l’extension, le développeur exécutera le code et fournira à l’extension un accès persistant de grande envergure à sa base de code.

Les cybercriminels et les États-nations ont découvert le nouveau maillon faible de la chaîne de sécurité : l’écosystème des fournisseurs de logiciels, a déclaré David Shipley, directeur de la société canadienne de sensibilisation à la sécurité Beauceron Security. « Il y a eu tellement de cas de ce genre qu’il s’agit clairement d’un problème systémique », a-t-il déclaré.

« Et ce n’est pas un problème que nous allons simplement résoudre avec ‘l’IA’, car cela continuera d’être un jeu du chat et de la souris. C’est l’un de ces problèmes épineux qui nécessitent des changements dans le paysage de la responsabilité juridique, un changement de culture en consacrant la sécurité dès la conception et en continuant à enseigner aux développeurs les principes de sécurité. Nous avons été extraordinairement chanceux cette année, avec des attaques comme le ver Shai-Hulud ne nous brûlant pas à l’échelle de WannaCry. Cette chance va s’épuiser », a déclaré Shipley.

Que sont les extensions VS

Des extensions et des thèmes peuvent être ajoutés au code Visual Studio pour faciliter la vie des développeurs et améliorer les fonctionnalités. Une extension peut ajouter des fonctionnalités telles que des débogueurs, de nouveaux langages ou d’autres outils de développement, tandis qu’un thème est un type d’extension qui modifie l’apparence de l’éditeur, contrôlant des éléments tels que les couleurs et les polices.

Microsoft a créé VSCode Marketplace pour permettre aux développeurs de rechercher facilement des extensions et des thèmes. Mais les développeurs qui ne nettoient pas leur travail avant de télécharger le code terminé sur les marchés VSCode ou OpenVSX risquent de révéler des jetons d’accès qui donnent à quiconque la possibilité de mettre automatiquement à jour l’extension. Si ces jetons sont contrôlés par un acteur menaçant, celui-ci peut automatiquement mettre à jour toutes les instances de l’extension vers une version malveillante.

Le rapport Wiz souligne que les professionnels de la sécurité et les développeurs doivent comprendre que non seulement les extensions VS mal écrites ou compromises peuvent constituer un problème, mais les thèmes aussi. En fait, le rapport Wiz note qu’une grande partie de cette énorme base d’installation vulnérable est en réalité constituée de thèmes.

Généralement, indique le rapport, les thèmes sont considérés comme plus sûrs que les autres extensions car ils ne contiennent aucun code. Cependant, ils augmentent encore la surface d’attaque car il n’existe aucun contrôle technique pour empêcher les logiciels malveillants d’y être regroupés.

Rapport similaire

Selon Koi Security, l’une de ces extensions malveillantes télécharge discrètement le code source d’un développeur sur des points de terminaison externes, une autre utilise des ressources locales pour le cryptomining et la variante la plus sophistiquée peut exécuter JavaScript à distance sans avoir besoin de nouvelles mises à jour pour étendre ou modifier les fonctionnalités.

McCarthy affirme que le problème identifié par Wiz Research était encore plus grave, car il aurait pu permettre aux attaquants de militariser plus d’une centaine d’extensions légitimes, installant automatiquement des logiciels malveillants sur plus de 185 000 machines de développeurs. Wiz a également trouvé des preuves selon lesquelles certains attaquants gonflent le nombre de téléchargements via le « pompage de téléchargement », ce qui peut rendre peu fiables les chiffres d’installation rapportés.

Il n’existe pas encore de modèle de menace cohérent pour les marchés d’extension, a déclaré McCarthy, ce qui rend difficile pour toute plateforme d’anticiper ces risques. Cependant, a-t-il ajouté, le marché de Microsoft a bénéficié d’investissements en matière de sécurité plus importants qu’Open VSX, et la recherche montre pourquoi c’est important.

Il a convenu que le rapport est un autre exemple de la raison pour laquelle les développeurs doivent faire plus attention à nettoyer leur code avant de le publier sur des marchés ouverts. Mais, a-t-il ajouté, c’est aussi un exemple de la façon dont les plates-formes peuvent intégrer des garde-fous pour minimiser les risques d’erreurs individuelles des développeurs.

« La sécurité des développeurs est une responsabilité partagée entre les éditeurs et les écosystèmes qui hébergent leur travail », a-t-il déclaré.

Conseils aux OSC, développeurs

Wiz dit que les utilisateurs de VSCode devraient :

• limiter le nombre d’extensions installées dans leur travail. Chaque extension introduit une surface de menace étendue, qui doit être mesurée par rapport aux avantages de son utilisation ;
• examiner les critères de confiance des extensions. Tenez compte de la prévalence des installations, des avis, de l’historique des extensions et de la réputation de l’éditeur, entre autres métadonnées, avant l’adoption ;
• envisagez des compromis en matière de mise à jour automatique. Les extensions de mise à jour automatique garantissent que vous recevez des mises à jour de sécurité, mais présentent le risque qu’une extension compromise propage des logiciels malveillants sur votre ordinateur.

Les équipes de sécurité de l’entreprise doivent :

• développer un inventaire des extensions IDE, afin de répondre aux rapports d’extensions malveillantes ;
• envisagez de créer une liste blanche centralisée pour les extensions VSCode ;
• envisagez de vous procurer des extensions auprès de VSCode Marketplace, qui présente actuellement une rigueur et des contrôles d’évaluation plus élevés, que sur OpenVSX Marketplace.

Les dirigeants devraient utiliser des outils de gestion des appareils et de sécurité des points finaux pour inventorier et appliquer des listes autorisées pour les extensions, a déclaré McCarthy de Wiz. L’approbation centralisée des extensions permet de réduire les risques, mais il est également important de préserver la flexibilité des développeurs, afin de leur permettre d’utiliser des outils qui stimulent l’innovation. Les extensions apportent une réelle valeur ajoutée, mais leur longue traîne peut introduire une surface d’attaque importante si elles ne sont pas gérées.

Il n’existe aucun bon moyen de vérifier qu’une application n’a pas été compromise, a prévenu Ullrich de l’Institut SANS. Les solutions standard de sécurité des points de terminaison et des réseaux peuvent contribuer à protéger les développeurs, mais elles doivent être optimisées pour être efficaces et il est difficile d’identifier les extensions malveillantes. En particulier, les postes de travail des développeurs ont souvent des modèles d’utilisation spécifiques et bénins qui provoquent un nombre excessif de faux positifs si la solution n’est pas soigneusement réglée. Ainsi, les développeurs doivent tenter de minimiser le nombre d’extensions qu’ils installent.