GlassWorm : comment cette campagne infecte les IDE des développeurs
GlassWorm, une campagne malveillante récemment découverte, utilise un dropper développé en Zig pour cibler et infecter les environnements de développement intégrés (IDE). Cette attaque supply chain vise directement les développeurs, transformant leurs outils de travail en vecteurs d’infection. Voici comment s’en protéger concrètement.
Comprendre l’attaque GlassWorm et son dropper Zig
La campagne GlassWorm se distingue par son approche sophistiquée : au lieu de cibler les utilisateurs finaux, elle cible les développeurs via leurs IDE — Visual Studio Code, JetBrains, Sublime Text et d’autres éditeurs populaires. Le dropper, compilé en Zig (un langage bas niveau difficile à analyser pour les antivirus), s’installe sous forme d’extension ou de plugin légitime.
Le choix du langage Zig n’est pas anodin. Sa compilation produit des binaires difficiles à détecter par les solutions EDR traditionnelles, avec une empreinte mémoire minimale et aucune dépendance au runtime C. Cette technique d’évasion rend l’analyse statique particulièrement complexe.
Vecteurs d’infection identifiés
- Extensions IDE malveillantes : packages publiés sur les marketplaces officiels avec des noms proches d’extensions populaires (typosquatting)
- Dépendances npm/pip compromises : librairies légitimes modifiées pour inclure le dropper Zig
- Repositories GitHub clonés : projets open-source populaires dupliqués avec du code malveillant injecté dans les scripts de build
Tutoriel : détecter GlassWorm dans votre environnement
Étape 1 : auditer vos extensions IDE
Commencez par lister toutes les extensions installées dans votre IDE. Pour VS Code, exécutez cette commande :
code --list-extensions --show-versions > extensions_audit.txt
Comparez chaque extension avec sa source officielle. Vérifiez les points suivants :
- Le nombre de téléchargements (les copies malveillantes en ont souvent très peu)
- L’éditeur vérifié (badge bleu sur le marketplace)
- La date de publication (les faux packages sont récents)
- Les permissions demandées (accès réseau, système de fichiers)
Étape 2 : scanner les binaires Zig suspects
Les dropper GlassWorm laissent des traces caractéristiques. Recherchez les binaires Zig compilés dans les répertoires d’extensions :
find ~/.vscode/extensions -type f -executable -exec file {} \; | grep -v "text\|script"
Pour les IDE JetBrains :
find ~/.local/share/JetBrains -type f -executable -exec file {} \; | grep -v "Java\|text"
Tout binaire natif dans un répertoire d’extension qui n’est pas un fichier Java ou un script doit être considéré comme suspect et analysé.
Étape 3 : surveiller les connexions réseau suspectes
GlassWorm établit des connexions C2 (Command & Control) sortantes. Utilisez ss ou netstat pendant l’utilisation de votre IDE :
ss -tnp | grep -E "code|java|idea" | grep ESTAB
Toute connexion vers une IP ou un domaine inconnu mérite une investigation approfondie. Croisez les résultats avec des bases de threat intelligence comme VirusTotal ou AlienVault OTX.
Mesures de protection recommandées
Politique de sécurité pour les extensions
- Whitelister les extensions autorisées : configurez votre IDE pour n’autoriser que les extensions approuvées par votre équipe sécurité
- Désactiver l’auto-update des extensions : vérifiez manuellement chaque mise à jour avant de l’appliquer
- Isoler l’IDE dans un conteneur : utilisez des environnements sandboxés (Dev Containers, Gitpod) pour limiter l’impact d’une compromission
Renforcer la supply chain de développement
- Vérifier les signatures des packages : utilisez
npm audit signaturespour les projets Node.js - Épingler les dépendances : utilisez des lockfiles stricts et vérifiez les checksums
- Scanner avec des outils SAST : intégrez Semgrep, Snyk ou des scanners de packages malveillants dans votre CI/CD
- Activer la journalisation IDE : VS Code propose des logs détaillés via
Developer: Open Extension Host Log
Indicateurs de compromission (IoC) à surveiller
- Binaires compilés en Zig dans les répertoires d’extensions (taille souvent < 500 Ko)
- Connexions sortantes inhabituelles depuis les processus IDE
- Modifications non autorisées dans
settings.jsonou les fichiers de configuration IDE - Extensions récemment installées sans action utilisateur documentée
- Augmentation inexpliquée de l’utilisation CPU/RAM par l’IDE
Conclusion
La campagne GlassWorm illustre une tendance croissante : les attaquants ciblent désormais directement les outils des développeurs pour maximiser l’impact de leurs attaques supply chain. En auditant régulièrement vos extensions, en surveillant les connexions réseau et en appliquant une politique stricte de gestion des dépendances, vous réduisez significativement votre surface d’attaque. La sécurité de votre IDE est aussi critique que celle de votre code.