Ver auto-propagatif trouvé sur les marchés pour les extensions Visual Studio Code

Lucas Morel

Considérez cela comme un incident de sécurité immédiat, conseillent les RSSI ; Les chercheurs affirment qu’il s’agit de l’une des attaques de chaîne d’approvisionnement les plus sophistiquées qu’ils aient vues, et qu’elle se propage.

Un mois après la découverte d’un ver auto-propagatif dans le référentiel de code open source NPM, un ver similaire a été découvert ciblant les extensions Visual Studio Code sur les marchés ouverts.

Les chercheurs de Koi Security, basé en Israël, affirment que le malware, qu’ils surnomment GlassWorm, a été trouvé dans des extensions des marchés OpenVSX et Microsoft VS Code.

« Il s’agit de l’une des attaques de chaîne d’approvisionnement les plus sophistiquées que nous ayons jamais analysées », préviennent les chercheurs. « Et ça se propage en ce moment. »

Si les extensions compromises sont intégrées dans le code, elles récoltent les informations d’identification NPM, GitHub et Git laissées par les développeurs dans leur travail, drainent les fonds de 49 portefeuilles de crypto-monnaie, déploient des serveurs proxy SOCKS sur les ordinateurs des développeurs, installent des serveurs VNX cachés pour un accès à distance et utilisent des informations d’identification volées pour compromettre des packages et des extensions supplémentaires.

Sept extensions OpenVSX ont été compromises la semaine dernière et ont été téléchargées plus de 35 000 fois, indique le rapport. De plus, une autre extension infectée a été détectée sur le marché VS Code au cours du week-end.

Les vers présents dans les extensions échappent à la détection en utilisant une ancienne technique : inclure des logiciels malveillants écrits avec des sélecteurs de variantes Unicode. Ce sont des caractères spéciaux qui font partie de la spécification Unicode mais ne produisent aucune sortie visuelle.

« Pour un développeur effectuant une révision de code, cela ressemble à des lignes vides ou à des espaces », explique Koi Security. « Pour les outils d’analyse statique recherchant le code suspect, cela ne ressemble à rien du tout. » Mais pour un interpréteur JavaScript, il s’agit d’un code exécutable.

« Les RSSI devraient traiter cela comme un incident de sécurité immédiat si leurs développeurs utilisent VS Code », déclare Tanya Janca, responsable du cabinet de conseil canadien en formation au codage sécurisé SheHacksPurple.

« Étant donné que les extensions héritent des autorisations complètes de VS Code, une fois installées, elles peuvent voler des informations d’identification, exfiltrer le code source et activer la commande et le contrôle à distance (par exemple, via les proxys VNC et SOCKS). Niveau de risque : très élevé. « 

Les RSSI devraient démarrer immédiatement leurs processus de réponse aux incidents, a-t-elle déclaré, en effectuant un inventaire pour voir quelles applications d’entreprise utilisent VS Code, quelles extensions elles contiennent et en déterminant si certaines figurent sur la liste des personnes concernées connues.

Ils devraient également surveiller les comportements suspects des applications, a-t-elle ajouté, en particulier les connexions et processus sortants étranges mentionnés dans la recherche, les serveurs VNC non approuvés et les processus proxy SOCKS de longue durée.

Formez vos développeurs

En attendant, Janca recommande de désactiver toutes les mises à jour automatiques des applications et d’informer tous les développeurs de la situation et des extensions à surveiller.

« Bloquez définitivement l’accès au registre OpenVSX et à tous les autres marchés non fiables/inconnus », conseille-t-elle. « Demandez aux développeurs de se déconnecter de leurs outils de développement et de redémarrer. Révoquez puis alternez toutes les informations d’identification qui auraient pu être divulguées avant de vous reconnecter à tout. »

Suivez les pratiques normales de réponse aux incidents, a-t-elle conclu : détecter, contenir, éradiquer, récupérer.

Marketplaces ciblées

Le rapport de Koi Security est le dernier d’une série d’avertissements indiquant que les acteurs malveillants ciblent de plus en plus les marchés VS Code dans le cadre d’attaques sur la chaîne d’approvisionnement. La semaine dernière, Koi Security a révélé qu’un acteur malveillant surnommé TigerJack diffusait des extensions malveillantes. Et les chercheurs de Wiz viennent de publier une étude montrant les abus généralisés des marchés OpenVSX et VS Code.

L’utilisation d’Unicode pour masquer les logiciels malveillants a été révélée le mois dernier par des chercheurs de Radware, qui ont découvert qu’il était utilisé pour compromettre ChatGPT.

Ces rapports ne devraient pas surprendre. Les marchés de code ouvert, où les développeurs peuvent télécharger du code pour que d’autres puissent l’utiliser dans leurs applications, sont depuis longtemps des cibles pour les acteurs malveillants en tant que véhicules permettant d’insérer du code malveillant dans des projets. Le code se propage ensuite dans les environnements des développeurs ou des clients pour voler les informations d’identification et les données. Collectivement, ces attaques sont connues sous le nom d’attaques contre la chaîne d’approvisionnement.

Parmi les référentiels les plus ciblés figurent GitHub, GitLab et NPM.

Microsoft offre aux développeurs la possibilité d’ajouter des extensions et des thèmes à Visual Studio Code 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.

Tire parti de la blockchain

Les chercheurs de Koi Security ont découvert l’extension vermifugée dans OpenVSX lorsque leur moteur de risque a signalé une activité suspecte dans une mise à jour d’une extension appelée CodeJoy. un outil de productivité pour les développeurs avec des centaines de téléchargements. Cependant, la version 1.8.3 a introduit des changements de comportement suspects. Le code source comprenait ce qui ressemblait à un énorme espace entre les lignes qui était en fait du code malveillant codé en caractères Unicode non imprimables qui ne peuvent pas être visualisés dans un éditeur de code.

Pire encore, le malware utilise la blockchain publique Solana comme infrastructure de commande et de contrôle (C2) dans son objectif de recherche d’identifiants de connexion, notamment ceux des portefeuilles cryptographiques. Le malware utilise également un événement Google Calendar comme mécanisme de sauvegarde C2.

Les informations d’identification NPM, GitHub, Git et OpenVSX volées aident également le malware à se propager sous forme de ver.

Enfin, le malware injecte un cheval de Troie d’accès à distance sur les postes de travail des développeurs victimes, les transformant en serveurs proxy SOCKS. Les postes de travail peuvent ensuite être utilisés pour accéder aux systèmes informatiques d’une organisation, devenant ainsi des points d’accès au réseau interne, des portes dérobées persistantes, des proxys pour attaquer d’autres systèmes internes et des canaux d’exfiltration de données.

Les développeurs sont une « cible privilégiée »

Les développeurs sont aujourd’hui une cible privilégiée des attaques, a souligné Johannes Ullrich, doyen de la recherche à l’Institut SANS. Ce qu’ils ne réalisent souvent pas, c’est que toute extension qu’ils installent, même si elle semble inoffensive, a un accès complet à leur code et peut y apporter des modifications sans en informer explicitement le développeur.

Les RSSI doivent inclure les développeurs dans les discussions sur la sécurisation des outils de développement, conseille-t-il. Limiter les outils autorisés est souvent contre-productif, car les développeurs identifieront des solutions de contournement pour accomplir leur travail. La sécurité doit coopérer avec les développeurs pour les aider à utiliser les outils dont ils ont besoin en toute sécurité, et tout produit de protection des points finaux doit être optimisé pour prendre en charge les modèles d’utilisation uniques des développeurs.

Il ne s’agit pas seulement d’un problème de chaîne d’approvisionnement, a déclaré Will Baxter, RSSI de terrain chez Team Cymru, il s’agit d’une nouvelle couche d’infrastructure fusionnant les outils de cybercriminalité, la résilience de la blockchain et l’orientation des outils de développement. Les opérateurs de registre, les chercheurs sur les menaces et les partenaires de surveillance de la blockchain doivent partager des renseignements et travailler ensemble plus étroitement pour signaler ces attaques hybrides, a-t-il ajouté.

Plus de conseils aux OSC

Janca affirme que pour réduire le risque d’attaques de la chaîne d’approvisionnement, les responsables de la sécurité et les professionnels de la sécurité des applications devraient :

  • réduire la surface d’attaque autant que possible : installez uniquement les fonctionnalités et autres logiciels qu’ils utilisent, par exemple, désinstallez toutes les extensions VS Code qui ne sont pas utilisées et supprimez toutes les dépendances inutilisées du code ;
  • surveillez tous les postes de travail des employés pour déceler tout comportement anormal, en mettant davantage l’accent sur ceux qui disposent d’un accès privilégié, tels que les développeurs de logiciels.
  • appliquer le moindre privilège pour la gestion des identités et des accès, en particulier pour les machines des développeurs
  • mettre en œuvre un processus de gestion du changement rapide et efficace qui inclut les changements dans la chaîne d’approvisionnement logicielle ;
  • former les développeurs au codage sécurisé, à la protection de leur chaîne d’approvisionnement et à leur rôle lors de la réponse aux incidents, pour aider à prévenir de tels problèmes à l’avenir ou à réagir plus rapidement et avec plus de grâce
    Il existe divers outils d’analyse de sécurité qui peuvent être utilisés pour réduire les risques et détecter les problèmes avant qu’ils ne se transforment en incidents de sécurité, tels que les scanners d’extension, les scanners secrets, les outils de sécurité de la chaîne d’approvisionnement (SCA et SBOM) et la protection des points finaux ;
  • suivez les meilleures pratiques appropriées en matière de gestion des secrets, afin que les packages malveillants comme ceux-ci ne puissent pas récolter les informations d’identification ;
  • seuls les référentiels, marchés, etc. approuvés doivent être utilisés dans une organisation. Bloquez tous les emplacements inconnus ou non fiables pour télécharger du code, des packages, des images et des extensions ;
  • renforcer l’ensemble de la chaîne d’approvisionnement logicielle, et pas seulement les composants et le code tiers. Cela inclut des mises à jour régulières et le verrouillage de l’accès au CI/CD, aux IDE et postes de travail des développeurs, aux artefacts, etc.
  • pousser les gouvernements à fournir une solution à l’écosystème logiciel open source très peu sécurisé dont beaucoup d’entre nous dépendent. Ou encore, privilégiez les langages et frameworks de développement à source fermée, même si cela, admet-elle, n’aurait pas aidé dans ce cas, car .Net est une source fermée mais VS Code Marketplace ne l’est pas.