Piratage GitHub : la campagne wfx-loot vole des secrets

Qu'est-ce que la campagne GitHub wfx-loot ?

wfx-loot est une campagne dans laquelle un attaquant utilise des identifiants GitHub volés pour pousser un workflow malveillant dans les dépôts où ces comptes peuvent écrire, afin de voler des secrets de GitHub Actions et des identifiants cloud ^[1]. Aikido Security, qui l'a signalée en premier, l'a nommée d'après le nom que l'attaquant donne à son logiciel malveillant (« wfx ») et le mot qu'il emploie pour les secrets volés (« loot ») ^[1]. SafeDep attribue aussi à Aikido le premier signalement ^[5].

StepSecurity appelle le même voleur « wfx » et insiste sur un point essentiel : l'attaquant n'exploite pas de bug dans GitHub Actions ^[2]. Il utilise des jetons valides de vrais comptes de développeurs et de bots, ouvrant des pull requests et poussant des commits comme le ferait un développeur ^[2][4].

Aikido estime que l'objectif principal est de récupérer des secrets CI plutôt que de se propager via des paquets logiciels, bien que la charge utile ait atteint au moins un paquet Packagist et un paquet Go par des déclencheurs de publication automatisés ^[1]. BleepingComputer, s'appuyant sur l'analyse d'Aikido, rapporte que certains des comptes compromis appartenaient à de grandes organisations ^[3].

Quelle est l'ampleur de l'attaque wfx-loot ?

Aikido compte 4.837 comptes compromis qui ont ouvert des pull requests de sondage dans 61.764 dépôts, le voleur s'étant exécuté dans au moins 1.806 dépôts ^[1]. Les chiffres diffèrent légèrement d'un chercheur à l'autre, car chacun a interrogé GitHub à un moment différent alors que la campagne était encore active.

• Aikido : 4.837 comptes, 61.764 dépôts ; 10.431 pull requests visaient des dépôts dont le compte n'est pas propriétaire ; 92 % sont toujours ouvertes ; au moins 50 utilisateurs compromis publient des paquets sur npm, Go, Packagist, PyPI ou crates ^[1].
• Aikido (chiffre de synthèse) : au moins 1.835 dépôts ont exécuté la charge utile et se sont fait dérober des identifiants ; BleepingComputer reprend ce chiffre ^[1][3].
• StepSecurity : plus de 63.000 pull requests de sondage au 12 novembre à 07:40 UTC, dont environ 90 % toujours ouvertes ^[2].
• SafeDep : 8.093 dépôts ont reçu des commits malveillants entre le 10 et le 12 novembre, un chiffre qui, comme le note SecurityWeek, ne signifie pas nécessairement que le voleur s'est exécuté ^[5][4].

Aikido avertit que son décompte des exécutions peut sous-estimer l'impact, car les journaux d'exécution ont été supprimés dans les dépôts touchés ^[1].

Comment fonctionne le voleur wfx-loot ?

Pour chaque dépôt où un jeton volé peut écrire, l'attaquant sonde, pousse la charge utile, puis nettoie en une minute environ ^[1].

1. Sondage : une pull request intitulée « docs: dependency audit notes », issue d'une branche nommée wfx-docs, ajoute un minuscule fichier de notes. « La pull request ne fait rien par elle-même », dit StepSecurity ; elle montre seulement que le jeton a un accès en écriture ^[2][4].
2. Charge utile : un script shell d'environ 1.500 lignes arrive de trois façons : injecté dans un workflow existant (« ci: refresh build cache »), sous forme de script avec un hook npm postinstall (« chore: add ci helper »), ou sous forme de nouveau workflow sur une branche chore/ jetable (« chore: add dependency audit workflow ») ^[1].
3. Nettoyage : l'attaquant annule la modification et supprime l'exécution du workflow et ses journaux ^[1]. Un numéro d'exécution manquant est souvent la seule trace ^[1].

Le script collecte les secrets et jetons de GitHub Actions, tout l'environnement du runner, des fichiers d'identifiants pour AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH et d'autres, des historiques de shell, ainsi que des clés de fournisseurs d'IA et d'outils de développement ^[1][3]. Il lit même la mémoire des processus en cours sur le runner ^[1][4]. Aikido a constaté que les copies qu'elle a analysées n'envoyaient les données volées que par HTTP POST vers des serveurs contrôlés par l'attaquant ^[1]. StepSecurity a ensuite observé un changement : à partir d'environ 05:30 UTC le 12 novembre, de nouvelles copies n'envoient les données que via Telegram, si bien que bloquer uniquement les adresses de serveurs publiées ne les arrête plus ^[2].

Pourquoi renouveler les secrets ne suffit-il pas ?

Parce que le voleur tente d'installer des portes dérobées qui survivent au renouvellement des identifiants ^[1][2]. Aikido décrit trois techniques de persistance ^[1] :

• Fausses vérifications d'état : Aikido indique qu'il publie de fausses vérifications « success » sous les noms des vérifications requises d'un dépôt, ce qui peut franchir les barrières de fusion de la protection de branche ^[1]. StepSecurity a constaté que cette fonction était désactivée dans les 101 échantillons qu'elle a examinés ^[2].
• Réécriture de la politique de confiance AWS : il peut régler la politique de confiance d'un rôle pour autoriser n'importe quel compte AWS ^[1].
• Injection d'identité fédérée Azure : il peut ajouter des identifiants fédérés nommés wfx-ci-… à des applications Azure AD, permettant aux workflows du dépôt compromis de s'authentifier sans secret stocké ^[1].

Il peut aussi générer des jetons OIDC GitHub et les échanger contre des sessions AWS, Google Cloud et Azure, s'enchaîner vers d'autres rôles IAM et créer des clés d'accès AWS de longue durée ^[1][3]. C'est pourquoi StepSecurity dit de « supprimer la persistance, car le renouvellement seul ne le fait pas » ^[2].

Comment vérifier si mes dépôts GitHub ont été touchés ?

Recherchez la pull request de sondage et les messages de commit de l'attaquant depuis le 10 novembre, puis cherchez des trous dans les numéros d'exécution des workflows ^[2][1].

1. Recherchez dans les pull requests « docs: dependency audit notes » et des branches nommées wfx-docs ou chore/ suivi de huit caractères ^[1][2].
2. Recherchez dans les commits depuis le 10 novembre « ci: refresh build cache », « ci: restore », « ci: cleanup », « chore: add ci helper » et « chore: add dependency audit workflow » ^[2].
3. Pour chaque résultat, ouvrez l'onglet Actions et cherchez un numéro d'exécution manquant juste après le commit ; StepSecurity y voit le signe le plus fiable que le voleur s'est exécuté ^[2].
4. Notez quel compte a poussé les commits : les jetons de ce compte sont volés ^[2]. Si une pull request de sondage existe, le compte est compromis même si aucune charge utile ne s'est exécutée ^[1].

Ne vous fiez pas à l'absence d'artefacts. Aikido indique que l'absence d'artefacts wfx-loot, d'entrées de cache wfx- ou de résumés d'étapes spéciaux ne signifie pas que des données n'ont pas été prises, car ces canaux étaient désactivés dans cette campagne ^[1]. Aikido suggère aussi que la charge utile peut être déployée dans des dépôts privés comme publics ^[1].

Que faire si le voleur s'est exécuté ?

Partez du principe que tous les secrets et rôles cloud accessibles au workflow touché sont compromis, renouvelez-les, puis recherchez la persistance ^[1][2].

• Renouveler : tous les secrets de dépôt, d'environnement et d'organisation que la tâche pouvait atteindre, pas seulement ceux que le workflow nomme ; les jetons de publication npm, PyPI et autres ; et les clés cloud stockées comme secrets ^[2].
• Vérifier les paquets : recherchez les versions de paquets publiées après le commit malveillant ^[2].
• AWS : recherchez des politiques de confiance autorisant n'importe quel principal AWS, des clés d'accès IAM créées depuis le 10 novembre et des sessions CloudTrail commençant par wfx- ^[2].
• Azure : supprimez les identifiants d'identité fédérée nommés wfx-ci-* sur les inscriptions d'applications ^[2].
• Google Cloud, Vault, Kubernetes : examinez la génération de jetons et les connexions effectuées avec des jetons de connexion GitHub Actions ^[2].
• GitHub : supprimez les branches restantes, fermez les pull requests de sondage, vérifiez que rien n'a été fusionné sur une fausse vérification, et révoquez les jetons, autorisations OAuth et clés SSH du compte ^[2].
• Jetons, selon la documentation de GitHub : examinez vos jetons d'accès personnels sous Settings, Developer settings et supprimez ceux que vous ne reconnaissez pas ou dont vous n'avez pas besoin ; GitHub recommande des jetons à granularité fine, uniquement les autorisations minimales nécessaires et une date d'expiration, car un jeton classique peut accéder à tous les dépôts auxquels vous avez accès ^[6].

Le hook npm s'exécute aussi sur les machines des développeurs : toute personne ayant lancé npm install pendant la courte fenêtre a exécuté le voleur en local et doit renouveler ses propres identifiants aussi ^[2]. SecurityWeek résume les conseils de plusieurs sociétés de sécurité : révoquer les jetons compromis, renouveler les secrets exposés et rechercher des modifications cloud non autorisées ^[4]. Pour les comptes de bots, StepSecurity suggère aussi de vérifier s'ils ont vraiment besoin de l'autorisation de contourner la protection de branche ^[2]. Une protection de connexion solide complique les campagnes de vol de comptes ; voir Two-Factor Authentication Explained: Which 2FA Method Is Safest?.

Quels paquets ont été touchés ?

Aikido recense un paquet Packagist et un module Go qui ont récupéré la charge utile via la publication automatisée ^[1].

• Packagist : digitalelvis/neuronai-studio version 3.14.3 ; Aikido dit de considérer comme compromise toute machine qui l'a installé ou ouvert ^[1].
• Go : github.com/onuragtas/docker-env v1.0.278 et v1.0.280 ; la charge utile se trouve uniquement dans un fichier de workflow GitHub Actions, le code source Go et les binaires sont inchangés, et les builds Go n'exécutent jamais de fichiers de workflow, mais Aikido recommande tout de même de retirer ces versions ^[1].

Les décomptes diffèrent : SafeDep parle de trois paquets sur Packagist et le proxy de modules Go qui contiennent la charge utile, et SecurityWeek mentionne des versions de deux modules Go ^[5][4]. SafeDep ajoute que la charge utile ne s'est pas exécutée pour les utilisateurs habituels qui installent ces paquets avec composer require ou go get ^[5]. Consultez la liste actuelle de chaque chercheur avant de vous fier à l'une d'elles.

Qui est derrière wfx-loot et comment a-t-il obtenu les jetons ?

Aucun des rapports cités ici n'identifie l'attaquant, et StepSecurity dit ne pas avoir établi comment les jetons ont été obtenus ^[2][4].

StepSecurity a trouvé 173 pull requests de sondage, issues de 19 comptes, faites avec des jetons émis pour l'application GitHub Fly.io ; elle dit ne pas avoir pu déterminer comment ils ont été obtenus et ne disposer d'aucune preuve que l'infrastructure de Fly.io ait été compromise ^[2][4].

Aikido a trouvé un recoupement avec des comptes touchés par la vague GhostAction d'octobre et a vu wfx-loot injecté dans des fichiers de workflow GhostAction dans plus de 100 dépôts, mais a jugé qu'il s'agissait de deux campagnes distinctes, vraisemblablement menées par des acteurs différents, car des identifiants volés finissent souvent entre les mains de plusieurs groupes ^[1]. Elle a aussi remarqué des commentaires en indonésien dans certaines versions plus récentes du logiciel malveillant ^[1]. Bien conserver ses jetons compte ici ; Password Managers Explained: How They Work and Whether They Are Safe en présente les bases.