Attaquez la chaîne d'approvisionnement GlassWorm extension vole les lettres d'identité de Open VSX

Une nouvelle alerte de sécurité montre à quel point la chaîne de distribution de code peut être fragile : des acteurs malveillants ont réussi à manipuler des mises à jour légitimes hébergées dans l'enregistrement Open VSX pour diffuser un chargeur de logiciels malveillants appelé GlassWorm. La recherche publiée par la firme Socket décrit comment les extensions détenues par un développeur légitime ont été mises à jour avec des versions contaminées qui, avant leur élimination, avaient accumulé des dizaines de milliers de téléchargements.

Open VSX est une plate-forme ouverte pour la publication d'extensions compatibles avec les éditeurs de Code Visual Studio, et son écosystème facilite la productivité quotidienne et les outils d'utilité pour atteindre les programmeurs à travers le monde. C'est précisément cette confiance et cette portée qui rendent ce type de dépôt attrayants cibles pour les attaquants qui veulent maximiser l'impact de leur code malveillant. L'explication technique et l'analyse médico-légale de l'incident figurent dans le rapport publié par Socket Voilà., et le dépôt concerné a également enregistré le débat public à GitHub sur l'intrusion dans cette incidence.

Selon l'analyse disponible, le mécanisme d'attaque n'était pas la création de faux paquets avec des noms similaires ou une arnaque typosquating à cette occasion: les attaquants auraient obtenu l'accès aux identifiants de publication d'un véritable développeur et utilisé ce compte pour télécharger des versions malveillantes d'extensions déjà populaires. Pour cette raison, les échantillons sont passés relativement inaperçus au début, jusqu'à ce que le comportement malveillant ait été détecté et que les versions compromises aient été retirées de l'enregistrement.

Le logiciel livré dans les mises à jour agit comme un chargeur: c'est-à-dire un composant conçu pour déchiffrer et exécuter du code supplémentaire dans le temps de fonctionnement. Socket relie ces charges à la famille GlassWorm, qui utilise des techniques de plus en plus sophistiquées pour cacher ses serveurs de communication, de commande et de contrôle. Ces techniques incluent ce que les chercheurs décrivent comme "EtherHelling" et l'utilisation de mémos dans le réseau Solana comme un mécanisme dynamique pour publier des points de contact alternatifs sans la nécessité de redistribuer l'extension malveillante.

Le comportement des malwares montre une phase de reconnaissance avant qu'il ne soit activé: le code évalue l'environnement de la machine victime et évite d'exploser s'il détecte une configuration locale de la Russie ou des territoires voisins, une pratique courante entre les campagnes attribuées aux acteurs russophones cherchant à réduire la possibilité d'une action en justice contre leur propre. Lorsque l'exécution se poursuit, l'objectif principal de l'acteur est de collecter des identifiants et des données sensibles.

Les éléments d'information que GlassWorm recherche vont des identifiants de navigateur et des cookies - navigateurs basés sur Firefox et Chrome, y compris les extensions de panneaux d'affichage Web3 et MetaMask - aux fichiers de panneaux d'affichage cryptomoneda (par exemple, Electrum, Exode, et solutions matérielles et logicielles telles que Ledger Live et Trezor Suite). En outre, selon la recherche, l'expéditeur tente d'extraire des données de la clé iCloud, des cookies Safari, des notes et documents locaux, des paramètres clients VPN (cités comme FortiClient) et des artefacts utilisés par les développeurs, tels que des paramètres npm avec des jetons d'authentification ou des identifiants GitHub qui pourraient permettre l'accès à des dépôts privés et des secrets CI / CD.

Voler l'accès aux outils de développement et aux identifiants sur la machine d'un développeur est particulièrement dangereux car il facilite les mouvements latéraux et les engagements de compte cloud : avec une clé jeton ou privée vous pouvez exécuter des déploiements, accéder à l'infrastructure ou activer des automatismes qui affectent une organisation entière. Les experts soulignent donc que la menace n'est pas seulement un individu mais une menace commerciale.

Un autre aspect pertinent de l'incident est la façon dont l'agresseur essaie d'être confondu avec les flux de travail normaux du développeur. Au lieu de se fonder uniquement sur des indicateurs statiques - des hachages ou des URL en béton qui changent fréquemment - l'opérateur de malware utilise des charges cryptées qui sont décodées en mémoire et une infrastructure de contrôle qui est brisée par des signaux publics dans la chaîne de verrouillage, ce qui rend difficile de détecter les signatures traditionnelles basées et augmente le besoin de détection par comportement et réponse agile. Socket explique ces tactiques et la difficulté qu'elles impliquent pour les défenseurs dans son rapport Voilà..

Pour les utilisateurs et les administrateurs, la recette d'atténuation est mesurée sur plusieurs fronts : examiner et révoquer les justificatifs d'identité engagés, forcer la rotation des jetons et des clés, permettre l'authentification multi-facteurs pour la publication de comptes et de dépôts, et vérifier les environnements CI / CD par des dispositifs suspects. Il est également important de surveiller les comportements atypiques dans les paramètres, tels que les processus qui déchiffrent et exécutent des blobs en mémoire ou des connexions à des domaines / schémas inhabituels. Des ressources institutionnelles sur la sécurité de la chaîne d'approvisionnement et les bonnes pratiques sont disponibles sur les pages officielles telles que la CISA sur la sécurité de la chaîne d'approvisionnement Voilà. et la documentation sur la gestion des secrets et la sécurité sur les plateformes de développement est utile pour réduire les risques.

Pour les développeurs qui publient des extensions, la leçon est double : protéger le processus d'édition avec des contrôles robustes, et supposer que tout artefact qui atteint l'utilisateur final peut être rapidement vérifié et inversé. Tenir des copies vérifiées des paquets, enregistrer et limiter les jetons de publication, examiner les dossiers d'accès et utiliser le balayage automatique des unités sont des pratiques qui réduisent la fenêtre d'exposition. GitHub et d'autres fournisseurs fournissent des guides de sécurité pour ces scénarios; il est conseillé de les examiner et de les appliquer dans les flux de travail.

En fin de compte, cet incident rappelle que la sécurité du logiciel ne commence pas ou ne se termine pas dans le code que nous écrivons : La confiance dans les outils et les chaînes de distribution est essentielle et doit être géré avec le même sérieux que la protection des infrastructures. Pour ceux qui veulent approfondir les détails techniques et la preuve de l'affaire, l'analyse de Socket et la discussion du dépôt concerné offrent un point de départ fiable: Rapport sur les chaussettes, fil dans GitHub et la page d'inscription Ouvrir VSX suivre les mesures prises par la communauté.