💻 computer science

Beyond Takedown: Measuring Malicious Go Module Persistence in the Wild

Cet article révèle une attaque de la chaîne d'approvisionnement Go à grande échelle où des adversaires reconditionnent des modules légitimes avec des logiciels malveillants obfusqués, démontrant que le fait de se fier uniquement aux recherches GitHub ne permet pas de détecter l'ampleur réelle du compromis car plus de 99 % des artefacts malveillants supprimés restent récupérables via les proxys Go.

Auteurs originaux : Minjae Bae, Carter Yagemann

Publié 2026-06-26

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Minjae Bae, Carter Yagemann

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez le monde du développement logiciel comme une immense bibliothèque animée où les programmeurs empruntent des « modules » (des blocs de code pré-écrits) pour construire leurs propres applications. Dans le langage de programmation Go, cette bibliothèque possède un bibliothécaire très strict : le Go Proxy.

Voici l'histoire d'un récent casse dans cette bibliothèque, racontée simplement.

Le Casse : « Le Faux Club de Lecture »

Des attaquants ont décidé de voler dans la bibliothèque, mais ils n'ont pas enfoncé les portes. À la place, ils ont joué un jeu d'impersonnalisation.

La Mise en Place : Ils ont trouvé des livres légitimes et populaires (des modules de code légitimes) que tout le monde respectait.
La Falsification : Ils ont créé de fausses copies de ces livres sous leurs propres noms. À l'intérieur de ces faux livres, ils ont caché un piège minuscule et invisible.
Le Piège : Dans le monde de Go, quand vous « importez » (empruntez) un livre, la bibliothèque exécute automatiquement quelques tâches de configuration. Les attaquants ont caché une instruction malveillante à l'intérieur de ces tâches de configuration. C'était comme un livre qui, dès que vous l'ouvriez, murmurait secrètement une commande à votre ordinateur pour télécharger et exécuter un virus.
Le Buzz : Pour que leurs faux livres paraissent réels, les attaquants ont utilisé une « armée de bots » pour leur donner des milliers d'« étoiles » (mentions j'aime) sur GitHub, trompant ainsi les développeurs en leur faisant croire : « Oh, celui-ci doit être populaire et sûr. »

L'Enquête : Deux Façons de Regarder

Les chercheurs (Minjae Bae et Carter Yagemann) voulaient voir à quel point ce problème était important. Ils ont utilisé deux lampes de poche différentes pour chercher les voleurs.

Lampe de poche 1 : La recherche GitHub (La vue de « l'Étagère »)
Ils ont cherché manuellement sur le site d'hébergement principal (GitHub), en cherchant des modèles suspects et en suivant les connexions d'« étoiles » entre les comptes.

Ce qu'ils ont trouvé : Ils ont trouvé 2 113 dépôts frauduleux.
Le Problème : Cette lampe de poche ne fonctionne que si le faux livre est encore posé sur l'étagère. Si le personnel de la bibliothèque retire le livre, ou si le voleur ne l'a jamais posé sur l'étagère principale, cette lampe de poche ne voit rien.

Lampe de poche 2 : Le Scan du Proxy (La vue de la « Circulation »)
Ils ont construit un scanner spécial appelé GOAST (un robot qui lit le code sans l'exécuter) pour scanner le Go Proxy. C'est le système de sauvegarde de la bibliothèque. Il conserve une copie parfaite et immuable de chaque livre qui a déjà été emprunté, même si le livre original est supprimé de l'étagère.

Ce qu'ils ont trouvé : Ils ont trouvé 2 289 versions malveillantes.
La Surprise : La lampe de poche du Proxy a trouvé 83 % de livres malveillants en plus que la lampe de poche GitHub. Beaucoup de ces faux livres n'étaient même pas sur l'étagère principale, ou avaient déjà été retirés, mais le Proxy les possédait toujours.

La Grande Découverte : « Supprimer » ne signifie pas « Réparer »

C'est la partie la plus importante de l'histoire.

Habituellement, lorsqu'une équipe de sécurité trouve un mauvais livre, elle demande à la bibliothèque de le supprimer. Ils suppriment le dépôt sur GitHub. Ils pensent : « Super, la menace est écartée. »

Les chercheurs ont prouvé que c'est faux.

Parce que le Go Proxy conserve une copie permanente et immuable de chaque module, supprimer la source sur GitHub ne supprime pas le virus de l'écosystème.

Les chercheurs ont découvert que même après que les dépôts des attaquants ont été supprimés ou suspendus (les rendant « invisibles » sur GitHub), 99,4 % de ces modules malveillants étaient toujours disponibles et téléchargeables via le Go Proxy.
C'est comme si le personnel de la bibliothèque jetait un faux livre à la poubelle, mais que le drone de livraison automatisé de la bibliothèque (le Proxy) possède toujours une copie parfaite dans son entrepôt et continue de la livrer aux clients qui la demandent.

Le Résultat

Les chercheurs ont informé le personnel de la bibliothèque (GitHub et Google) du problème.

GitHub a supprimé 684 dépôts malveillants.
Google (l'équipe du Proxy) a nettoyé 1 377 versions de modules malveillants de son stockage permanent.

La Leçon

On ne peut pas résoudre un problème de chaîne d'approvisionnement logicielle simplement en nettoyant la couche d'« hébergement » (GitHub). Si la couche de « distribution » (le Proxy) conserve le mauvais code, la menace perdure. Pour vraiment résoudre le problème, il faut nettoyer à la fois l'étagère et l'entrepôt.

Résumé technique : Au-delà du démantèlement : Mesurer la persistance des modules Go malveillants dans la nature

Énoncé du problème

L'écosystème Go, pilier des infrastructures logicielles modernes, est de plus en plus la cible d'attaques de la chaîne d'approvisionnement. Contrairement aux écosystèmes traditionnels (ex. npm, PyPI) où les attaques sont bien documentées, Go présente des défis uniques en raison de son modèle d'exécution et de son infrastructure de distribution. Les attaquants reconditionnent des modules Go légitimes sous des comptes contrôlés par l'attaquant, en y intégrant un code obscurci qui se déclenche lors de l'importation.

Un fossé critique existe entre le démantèlement de la couche d'hébergement (suppression des dépôts sur GitHub) et la remédiation de l'écosystème. Le modèle de distribution de Go repose sur proxy.golang.org et index.golang.org pour garantir la reproductibilité. Une fois qu'une version d'un module malveillant est publiée et mise en cache par le proxy, elle reste immuable et récupérable, même après que le dépôt source original a été supprimé ou suspendu. Par conséquent, s'appuyer uniquement sur la visibilité centrée sur GitHub ne permet pas de saisir toute l'étendue de la compromission ni d'assurer une véritable remédiation.

Méthodologie

Les auteurs ont employé une approche de mesure à deux étapes et complémentaires pour capturer l'empreinte de la campagne à travers la couche d'hébergement et la couche de distribution.

Étape 1 : Découverte manuelle (Jeu de données M)

Portée : Une recherche manuelle dans les dépôts GitHub menée entre mars et juin 2025.
Technique : Les chercheurs sont partis d'un ensemble de graines de dépôts malveillants connus et ont étendu la recherche via le « pivotement basé sur les étoiles » (stargazer-based pivoting), identifiant les comptes qui étoilaient de manière coordonnée plusieurs modules malveillants.
Vérification : Les candidats ont été filtrés à l'aide de pré-filtres par mots-clés (ex. exec.Command, /bin/sh, .Start()) et vérifiés manuellement pour s'assurer qu'ils contenaient des chaînes de caractères obscurcies reconstruisant des commandes de récupération et d'exécution (ex. wget ou curl suivis d'une exécution).
Résultat : Une base de référence de haute confiance de 2 113 dépôts malveillants ( $|M| = 2 113$ ).

Étape 2 : Mesure automatisée de la couche de distribution (Jeu de données G)

Portée : Un scan à grande échelle de l'infrastructure de distribution de Go utilisant index.golang.org et proxy.golang.org.
Outil : Les auteurs ont développé GOAST (Go AST-based Scanner for Threat), un moteur d'analyse statique conçu pour détecter des signatures spécifiques à la campagne plutôt que des malwares généraux.
- GOAST analyse les fichiers sources Go en Arbres de Syntaxe Abstraite (AST).
- Il identifie les appels de création de processus (exec.Command combiné avec Start, Run ou Output).
- Il effectue une propagation de valeurs intra-procédurale légère pour reconstruire les arguments de chaînes de caractères obscurcis.
- Il signale un module comme malveillant uniquement si un appel d'exécution reconstruit est couplé à une instruction de téléchargement (ex. wget/curl vers une URL HTTP(S)).
Collecte de données : L'équipe a collecté un flux chronologique de 12,3 millions d'entrées d'index de juillet 2024 à juillet 2025. Après déduplication et filtrage pour les comportements de partage de noms (clonage de noms de modules légitimes), ils ont scanné 60 232 candidats suspects.
Résultat : 2 289 versions de modules malveillants confirmées ( $|G| = 2 289$ ).

Principaux résultats

1. Caractérisation de la campagne (RQ1)

La campagne opère via un pipeline automatisé rigide avec deux vagues distinctes :

Vague 1 (mars 2025) : Ciblait Linux, utilisant l'indexation de tranches (slice indexing) pour reconstruire les commandes.
Vague 2 (mai 2025) : S'est étendue à Windows, utilisant un mélange de concaténation littérale et d'indexation de tranches.
Vecteur d'exécution : Les deux vagues exploitent les initialiseurs de variables globales de Go, exécutant le code malveillant immédiatement lors de l'importation du package.
Infrastructure : La campagne repose sur une empreinte étroite de 20 domaines distincts. Les charges utiles Linux servent des stagers ELF statiques, tandis que les charges utiles Windows font tourner des binaires PE uniques selon un cycle strict de 31 jours.

2. Les limites des vues centrées sur GitHub (RQ2)

La comparaison entre le jeu manuel GitHub ( $M$ ) et le jeu du proxy ( $G$ ) a révélé deux angles morts critiques :

Écart de portée de découverte (Manquement #1) : 83,0 % des modules malveillants trouvés dans le proxy ( $G \setminus M$ ) n'ont jamais été découverts par le flux de travail manuel centré sur GitHub. Ces modules circulaient dans le proxy sans les signaux sociaux (étoiles) nécessaires à la découverte manuelle.
Volatilité de la couche d'hébergement (Manquement #2) : Au moment de l'analyse, 69,3 % des modules de l'empreinte du proxy ( $G$ ) étaient déjà « inobservables sur GitHub » (dépôts supprimés ou suspendus).
Double manquement : 64,3 % de l'empreinte totale du proxy tombaient dans les deux catégories : ils étaient manqués par la découverte manuelle et leurs dépôts d'hébergement avaient déjà disparu.

3. Le fossé entre démantèlement et remédiation (RQ3)

L'étude a quantifié la persistance des menaces après la suppression de la source :

Preuve A (Chevauchement) : Pour les 74 modules de l'intersection ( $M \cap G$ ) confirmés comme étant « morts » sur GitHub lors de l'instantané de juin, 100 % restaient récupérables via le proxy Go en juillet.
Preuve B (Échelle) : Parmi les 1 586 modules du jeu du proxy ( $G$ ) qui étaient inobservables sur GitHub en août, 99,4 % (1 577 modules) ont été confirmés comme récupérables via les journaux du proxy en juillet.
Conclusion : La simple suppression d'un dépôt de GitHub ne remédie pas à la menace ; les versions de modules malveillants persistent dans la couche de distribution.

Contributions et importance

Le papier apporte trois contributions principales :

Mesure à l'échelle de l'écosystème : Il fournit la première mesure complète d'une campagne active de la chaîne d'approvisionnement Go, caractérisant son automatisation, l'évolution de ses deux vagues et la structure rigide de son obscurcissement.
Quantification des écarts de visibilité : Il démontre que les vues centrées sur GitHub sous-estiment systématiquement l'empreinte réelle de la menace en raison des limites de portée de la découverte et de la volatilité de la couche d'hébergement.
Preuve du fossé de remédiation : Il prouve empiriquement que « démantèlement $\neq$ remédiation » dans l'écosystème Go, montrant que les modules mis en cache par le proxy restent disponibles bien après que leurs dépôts sources ont été supprimés.

Importance :
Les auteurs soutiennent que la réponse aux incidents et la remédiation dans l'écosystème Go ne peuvent pas reposer uniquement sur les signaux de la couche d'hébergement. Parce que l'infrastructure de proxy garantit la reproductibilité, elle maintient par inadvertance les artefacts malveillants. Une remédiation efficace nécessite une coordination entre la couche d'hébergement (GitHub) et la couche de distribution (Go Proxy/Index). Suite à la divulgation responsable, GitHub a supprimé 684 dépôts et l'équipe Go de Google a remédié à 1 377 versions de modules, validant la nécessité de cette approche multi-couches.