Quelques semaines après avoir été déclaré éradiqué, GlassWorm infeste à nouveau les extensions open source en utilisant les mêmes astuces invisibles Unicode et blockchain C2.
Les logiciels malveillants omniprésents et évasifs que l’on croyait éliminés ont réapparu dans les environnements de développement.
Un peu plus de deux semaines après que GlassWorm a été déclaré « entièrement confiné et fermé » par le projet open source OpenVSX, le ver auto-propagé cible à nouveau les extensions Visual Studio Code, des modules complémentaires qui améliorent le VS Code open source, en fournissant de nouvelles fonctionnalités, des débogueurs et d’autres outils pour améliorer les flux de travail des développeurs. Les chercheurs de Koi ont découvert une nouvelle vague d’infections et trois autres extensions compromises.
Découvert pour la première fois en octobre, GlassWorm utilise des caractères Unicode illisibles pour rendre le code malveillant invisible aux éditeurs de code dans les environnements VS Code. Le ver s’est également frayé un chemin dans les référentiels GitHub, cachant des charges utiles dans des validations générées par l’IA qui semblent être des modifications de code légitimes.
Lancé par un groupe d’attaque basé en Russie, le malware infecte des victimes partout dans le monde. Cela comprenait des dizaines de développeurs individuels et d’entreprises aux États-Unis, en Europe, en Asie, en Amérique du Sud et « une entité gouvernementale majeure » au Moyen-Orient.
« Même infrastructure d’attaquant, toujours pleinement opérationnelle », notent les chercheurs de Koi. Ils ajoutent : « Il ne s’agit plus seulement d’extensions compromises. Il s’agit de victimes réelles, d’infrastructures critiques en danger et d’un ver qui fait exactement ce que nous avions prévenu : se propager dans l’écosystème des développeurs. »
Compromettant également les dépôts GitHub
Les chercheurs de Koi ont identifié trois nouvelles extensions de code OpenVSX contenant GlassWorm qui ont été téléchargées au moins 10 000 fois au total :
- (téléchargé 4 000 fois)
- (téléchargé 3 300 fois)
- (téléchargé 2 400 fois)
Les trois extensions GlassWorm sont « encore littéralement invisibles » dans les éditeurs de code, notent les chercheurs. Ils sont codés en caractères Unicode non imprimables qui ressemblent à des espaces vides à l’œil humain, mais s’exécutent en JavaScript.
Les attaquants ont publié de nouvelles transactions sur la blockchain Solana qui décrivent les points de terminaison de commande et de contrôle à distance (C2) mis à jour pour distribuer des charges utiles malveillantes. Mais même si ces transactions sont récentes, les serveurs restent inchangés, notent les chercheurs.
« Cela démontre la résilience de l’infrastructure C2 basée sur la blockchain : même si les serveurs de charge utile sont supprimés, l’attaquant peut publier une nouvelle transaction pour une fraction de centime et toutes les machines infectées récupèrent automatiquement le nouvel emplacement », écrivent-ils.
Les développeurs signalent également que leurs référentiels GitHub ont été compromis par des validations qui apparaissent comme des modifications de code « spécifiques au projet » générées par l’IA dans le cadre d’une activité de développement normale. Ces commits contiennent les mêmes logiciels malveillants Unicode invisibles que ceux de VS Code. De plus, les attaquants volent les informations d’identification GitHub et utilisent des techniques de vers pour transférer les validations vers des référentiels supplémentaires.
« Il est profondément inquiétant mais pas surprenant de voir GlassWorm réapparaître si rapidement », a noté Ensar Seker, RSSI de la société de renseignement sur les menaces SOCRadar.
Ce qui rend cette situation particulièrement dangereuse est la manière dont les attaquants ont refait surface le ver de la chaîne d’approvisionnement après sa suppression, a-t-il noté. « La suppression de quelques extensions ne suffit pas lorsque l’attaquant contrôle les mécanismes de propagation et exploite les points sur plusieurs marchés. »
Met en évidence une « faiblesse fondamentale »
Il est intéressant de noter que les attaquants semblent avoir négligé leur propre infrastructure, laissant un point final exposé que les chercheurs de Koi ont exploité pour faire apparaître des données et une liste partielle des victimes. Ils ont également découvert à partir des données de l’enregistreur de frappe de l’acteur malveillant qu’ils utilisaient l’extension de navigateur du framework open source C2 RedExt et étaient en mesure d’accéder aux identifiants utilisateur des attaquants pour plusieurs plates-formes de messagerie et échanges de crypto-monnaie.
La liste des victimes a depuis été remise aux forces de l’ordre, les victimes ont été informées et une enquête active est en cours, notent les chercheurs de Koi.
David Shipley de Beauceron Security a qualifié ces exploits de technologiques, de processus et de marché. OpenVSX ne semble pas disposer des ressources nécessaires en tant que communauté pour examiner manuellement le code soumis, a-t-il noté, s’appuyant plutôt sur des outils automatisés et des accords avec les éditeurs.
Ce problème met en évidence une « faiblesse fondamentale » du modèle de marché open source : les approches gratuites ou peu coûteuses signifient que les ressources ne sont pas disponibles et que les incitations ne sont pas alignées pour appliquer le niveau de sécurité requis dans l’environnement de menace actuel, a déclaré Shipley.
« En termes simples, lorsque vous n’êtes pas suffisamment payé pour effectuer des révisions manuelles du code, vous ne le faites pas », a-t-il noté. « Lorsque vous n’avez pas d’humains capables de rechercher des hacks intelligents, les hacks intelligents entrent en jeu. »
Remettre en question la valeur d’OpenVSX
Les équipes de sécurité devraient remettre en question la proposition de valeur d’OpenVSX, a conseillé Shipley. S’ils souhaitent examiner manuellement et envoyer des alertes sur le code du registre open source, ils peuvent atténuer les risques. Sinon, ils devraient envisager d’obtenir du code à partir d’une source organisée avec davantage de contrôles de révision.
« La chaîne d’approvisionnement et l’open source sont désormais les incontournables du jeu mondial de la cybersécurité, et ils vont le rester pendant longtemps », a déclaré Shipley. Cela pourrait potentiellement être le cas jusqu’à ce que l’économie soit rééquilibrée pour permettre plus de sécurité, ou que le modèle « s’effondre sous le poids de l’insécurité ».
« Il n’existe pas de poussière magique de lutin automatisée par l’IA qui puisse arrêter 100 % de ces menaces de manière fiable », a-t-il déclaré. « Des analyses automatisées suffisamment efficaces étaient suffisantes jusqu’à ce que les attaquants réalisent qu’il s’agissait d’une méthode de lancement d’attaque extrêmement viable. »
Seker de SOCRadar convient que le problème principal n’est pas le malware, mais le « changement systémique » dans les menaces liées à la chaîne d’approvisionnement.
« La chaîne d’approvisionnement logicielle n’est plus seulement une question de dépendances », a-t-il déclaré, mais plutôt de ses chaînes d’outils, de ses marchés et de l’ensemble de l’écosystème de développement. « Vous devez traiter l’infrastructure des développeurs comme une infrastructure de production. »
Les développeurs et les équipes de sécurité doivent saisir les signaux critiques : extensions malveillantes contenant des caractères Unicode invisibles en cours de téléchargement ; canaux C2 cachés utilisant des mémos blockchain et des services légitimes comme Google Calendar pour échapper aux retraits ; et les machines de développement infectées sont utilisées comme nœuds proxy pour lancer d’autres infections.
Les entreprises devraient réduire les surfaces d’attaque en autorisant uniquement les composants provenant d’éditeurs de confiance, en désactivant les mises à jour automatiques lorsque cela est possible et en maintenant un inventaire des extensions installées, a conseillé Seker, ainsi qu’en surveillant les connexions sortantes anormales des postes de travail, l’activité de collecte d’informations d’identification pour les jetons de niveau développeur (npm, GitHub, VS Code) et la création de serveurs proxy ou VNC. De plus, les équipes de sécurité doivent appliquer la « même rigueur » qu’elles utilisent pour les bibliothèques tierces à leurs propres chaînes d’outils de développement.
« Lorsque des acteurs malveillants traitent votre IDE (environnement de développement intégré) comme une rampe de lancement, l’exposition de votre chaîne d’approvisionnement augmente considérablement », a déclaré Seker.
En fin de compte, il a prévenu : « Il ne s’agit pas d’attaques typiques de la chaîne d’approvisionnement où vous corrigez une seule bibliothèque et passez à autre chose. Elles sont conçues pour persister. »
