Photographie de presse documentaire montrant une machine à écrire vintage sur un bureau en bois sombre, avec un code imprimé sur le papier.

Malware RubyGems injecte un worm Miasma dans les outils de développement

Une bibliothèque Ruby, strutil-core, a été mise en circulation sur RubyGems, et une analyse de ses versions récentes révèle l’implantation d’un code malveillant faisant partie de la famille Miasma. Socket’s Threat Research Team a examiné la version 1.0.1 de ce paquet, constatant qu’il contient un worm capable de s’exécuter dès l’installation pour voler des informations sensibles.

Le mécanisme est particulièrement insidieux : strutil-core est un ajout autonome, et non un paquet compromis préexistant. Son script d’installation natif, extconf.rb, ne contient pas de logique de construction traditionnelle. Au lieu de cela, il télécharge le runtime Bun et exécute un fichier JavaScript adjacent, ce qui déclenche le payload malveillant dès l’exécution de gem install strutil-core -v 1.0.1, sans qu’aucune application cliente n’ait besoin de dépendre explicitement de la gem.

Ce que ce paquet exfiltre est substantiel. Le code collecte des identifiants provenant de sources variées : services cloud (AWS, Azure, GCP), systèmes de contrôle d’intégration continue (CI), registres de paquets, clés SSH, et même les outils d’aide à l’écriture d’IA. Une fois les données volées, elles sont envoyées vers l’adresse paleasbest[.]top, avec des mécanismes de repli vers GitHub et GitLab.

Illustration en collage de papier découpé représentant un manifeste de paquet logiciel fragmenté avec des icônes de services cloud cachées.

Propagation et persistance dans l’écosystème de développement

L’attaque ne se limite pas au vol d’informations. Le payload incorpore des routines de propagation actives. Il est capable de s’auto-républier sur RubyGems, npm et PyPI. De plus, il intègre des fonctions pour infecter JFrog Artifactory, GitHub et GitLab. Ce qui est troublant, c’est sa capacité à pérenniser son accès : il installe un backdoor Python qui permet à l’attaquant d’exécuter n’importe quel script annoncé via un message de commit signé sur GitHub.

Si l’attaquant parvient à obtenir un jeton GitHub, la menace devient létale. Le code contient un moniteur conditionnel : si un jeton volé commence à renvoyer des codes d’erreur HTTP 401 ou 403, le programme lance un effaceur de fichiers qui supprime tout le répertoire personnel de l’utilisateur.

Selon l’analyse menée par Socket, le déploiement de la version 1.0.1 est survenu moins de deux heures après la publication d’une version propre (1.0.0), ce qui suggère une séquence calculée : une publication initiale innocente suivie d’une mise à jour injectée. GitHub.com, quant à lui, maintient des dépôts comme geliuz/miasma-azure-durabletask, qui contiennent des copies normalisées et déobfusquées de payloads similaires, destinées à la recherche défensive et à la réponse aux incidents.

L’architecture de l’infection

L’infection repose sur une chaîne d’exécution bien huilée. L’installation déclenche le téléchargement et l’exécution de Bun 1.2.18, ce qui permet à l’attaquant d’exploiter des fonctions natives. Le mécanisme de propagation RubyGems est particulièrement sophistiqué : en utilisant une clé API, il liste les paquets publiables, télécharge chaque archive, et y insère ses propres fichiers d’extension (index.js et extconf.rb), tout en modifiant méticuleusement le gemspec pour déclarer la nouvelle extension.

Cette technique est un rappel sombre de la vulnérabilité de la chaîne d’approvisionnement logicielle. BleepingComputer avait déjà alerté sur des projets de sécurité frauduleux sur GitHub déployant des portes dérobées et des voleurs d’informations, mais l’attaque via un paquet de dépendance est une méthode d’infiltration plus discrète et plus profonde.

Les dépôts de recherche comme celui de GitHub sont explicitement marqués comme étant du code malveillant et sont destinés à la défense, ce qui confirme que cette menace n’est pas une erreur de développement, mais une opération ciblée. La question qui demeure est de savoir comment les systèmes de déploiement continu filtrent des artefacts aussi parfaitement camouflés au moment de l’installation.

Sources