GlassWorm attaque OpenVSX: 73 extensions de sommeil qui cachent les logiciels malveillants et volent vos secrets

Publié 5 min de lectura 85 lecture

Une nouvelle vague de la campagne Verre a rehit l'écosystème des extensions de l'éditeur en apparaissant 73 paquets "sleeping" dans OpenVSX, dont six ont déjà été activés et fournissent une charge malveillante, selon la recherche publiée par Socket. La technique utilisée est préoccupante pour sa simplicité et son efficacité : les extensions sont initialement téléchargées comme des appareils inoffensifs et, après une mise à jour ultérieure, changent leur comportement pour télécharger et installer du code supplémentaire ou charger des modules compilés (.node) qui contiennent une logique malveillante.

Ce qui rend cette campagne particulièrement insidieuse est la tactique visuelle supplantantant les listes légitimes : icônes, noms et descriptions très similaires qui trompent le développeur qui fait confiance à l'apparence plutôt que de vérifier l'éditeur ou l'identificateur unique. Dans de nombreux cas, le premier paquet agit comme un "chargeur" léger qui, dans le temps d'exécution, télécharge les paquets VSIX des dépôts dans GitHub, exécute les commandes CLI pour les installer, ou exécute le code JavaScript fortement obfusqué qui défigure les URLs de sauvegarde et les charges utiles.

GlassWorm attaque OpenVSX: 73 extensions de sommeil qui cachent les logiciels malveillants et volent vos secrets
Image générée avec IA.

L'impact potentiel n'est pas seulement l'exécution à distance du code sur la machine d'un développeur : c'est une passerelle vers des secrets sensibles. précédentes campagnes GlassWorm ont cherché des clés de portefeuille cryptomoneda, des identifiants, des jetons d'accès, des clés SSH et des données d'environnement de développement. Si un seul poste de travail engagé peut exfilter les identifiants CI / CD ou jetons qui donnent accès aux dépôts et aux services cloud, la portée peut rapidement s'étendre aux engagements en matière d'infrastructure et aux chaînes d'approvisionnement.

Si vous pensez avoir installé l'une des extensions concernées, la première chose est de prendre une exposition possible et agir rapidement: Désinstaller les extensions suspectes, vérifie les processus et connexions réseau inhabituels, isole la machine affectée et, surtout, fait tourner toutes les identifiants et jetons qui auraient pu être accessibles à partir de cet ordinateur (jetons de dépôt, clés SSH, identifiants de service cloud, clés API et clés portefeuille). Socket a publié la liste complète des extensions identifiées et est le point de départ pour identifier les installations touchées: Socket - 73 extensions de couchettes VSX ouvertes.

Au-delà de la réponse immédiate, il existe des mesures pratiques pour atténuer ce type de risque à l'avenir : appliquer des contrôles d'évacuation (filtrage des sorties) pour bloquer les téléchargements automatiques à partir d'URL peu fiables, éviter d'installer des extensions à partir de dépôts non vérifiés dans des environnements de production ou CI, et utiliser des environnements isolés (machines virtuelles ou conteneurs éphémères) pour tester de nouvelles extensions avant de les intégrer dans le flux de travail. Il est également conseillé aux organisations de mettre en œuvre des politiques de gestion secrète et de rotation automatique, et de surveiller l'abonnement et les autorisations des comptes qui publient des extensions.

Pour les opérateurs et les responsables de l'écosystème tels qu'OpenVSX et les marchés d'extension, l'affaire souligne à nouveau la nécessité de mécanismes plus stricts pour la vérification et la détection des clones par les annonceurs: les paquets signés, la validation de l'identifiant de l'éditeur et la détection de similitude visuelle devrait être des exigences minimales, ainsi qu'une analyse automatisée qui détecte les comportements de « sommeil » ou les modèles de décharge dans le temps de fonctionnement. Vous pouvez consulter la plateforme OpenVSX pour connaître les détails et les politiques du dépôt : OuvrirVSX.

GlassWorm attaque OpenVSX: 73 extensions de sommeil qui cachent les logiciels malveillants et volent vos secrets
Image générée avec IA.

Du point de vue de la conformité et des risques, les campagnes telles que GlassWorm exigent des équipes de sécurité qu'elles intègrent l'examen de la chaîne d'approvisionnement logicielle dans les processus de déploiement : audits des unités, numérisation des appareils et SBOM (liste des composants) pour détecter les changements non autorisés et réduire la fenêtre d'exposition. Pour obtenir des conseils généraux sur la gestion des risques dans les chaînes d'approvisionnement, l'ACIS offre des documents utiles qui peuvent aider à établir des priorités dans les contrôles : CISA - Gestion des risques de la chaîne d'approvisionnement.

Si vous détectez des preuves d'engagement, documentez et conservez des billes et des artefacts avant de nettoyer l'équipement, informez votre équipe de sécurité et les annonceurs (OpenVSX et, le cas échéant, l'équipement Socket ou des plates-formes équivalentes) et préparez-vous à la reconstruction sécuritaire de l'environnement (réinstallation et restauration propres à partir de sauvegardes vérifiées). Le confinement rapide et la rotation des secrets sont les actions qui réduisent le plus les dommages à court terme.

GlassWorm est un exemple de la façon dont les attaquants affinent les tactiques d'approvisionnement: au lieu d'introduire directement des logiciels malveillants, ils préfèrent entrer par la porte d'entrée avec des artefacts bénins et activer la charge malveillante plus tard. Pour les développeurs et les responsables de la sécurité, il faut passer d'une mentalité de confiance par défaut à une vérification continue.- vérifier l'identité de l'éditeur, surveiller les mises à jour d'extension, limiter les autorisations et automatiser la rotation des secrets sont des étapes concrètes qui réduisent le risque de devenir victime de cette ou d'autres campagnes similaires.

Couverture

Autres

Plus de nouvelles sur le même sujet.