if ( !emtpy($headline_subheadline ) ) : ?>
Chaque secret de référentiel et d’organisation est regroupé dans un dump JSON, y compris les fichiers d’informations d’identification provenant de chemins bien connus, les historiques de shell et les clés API pour les services d’IA.
endif; ?>
Les chercheurs ont découvert une campagne dans laquelle des comptes GitHub piratés propageaient des logiciels malveillants voleurs de secrets sur des milliers de référentiels. La charge utile exécutée dans au moins 1 806 dépôts, exfiltrant les secrets CI/CD et les informations d’identification cloud.
Aikido Security, qui a détecté et documenté la campagne, a déclaré que les attaquants ont utilisé les 4 837 comptes compromis pour ouvrir des demandes d’extraction d’enquête dans 61 764 référentiels à partir du 10 novembre. Environ 92 % de ces demandes d’extraction, intitulées « documents : notes d’audit des dépendances », sont toujours ouvertes, ce qui suggère que la plupart des propriétaires de projets ne les ont pas vues.
Cependant, les sondes en elles-mêmes sont inoffensives et ont été effectuées uniquement pour vérifier si les comptes piratés avaient un accès en écriture dans ces dépôts afin que les attaquants puissent effectuer un suivi avec des commits contenant la charge utile malveillante : un script shell de 1 500 lignes qui collecte les secrets des actions GitHub, les informations d’identification cloud et les clés API pour les services d’IA et les outils de développement.
La charge utile a été livrée en utilisant au moins trois méthodes : modification des workflows GitHub Actions existants, ajout d’un postinstall crochet dans le package.json fichier qui l’exécute sur n’importe quel npm install et créer une branche jetable avec un workflow d’actions malveillantes à exécuter.
« Nous avons identifié des indications selon lesquelles la charge utile s’est déroulée dans au moins 1 806 référentiels, mais ce nombre pourrait sous-estimer l’impact », ont déclaré les chercheurs d’Aïkido dans leur rapport. « Le journal d’exécution a été supprimé dans les référentiels concernés, ce qui signifie que l’auteur de la menace a probablement collecté les informations d’identification et couvert ses traces. »
Le hook npm qui a échappé à GitHub
La protection de GitHub contre ce type d’attaque a fonctionné comme prévu pour les charges utiles qu’il pouvait voir. La plate-forme a émoussé les récentes campagnes d’injection de flux de travail en exigeant une approbation explicite avant l’exécution des flux de travail malveillants, et GitGuardian a découvert que les sept exécutions de charge utile de novembre étaient toujours visibles dans les fichiers de flux de travail stockés dans un fichier de flux de travail. action_required état et n’a jamais commencé.
« GitHub détenait les formulaires de flux de travail, mais un hook npm a échappé à la attente et s’est exécuté », a déclaré Gaetan Ferry, chercheur en sécurité chez GitGuardian, dans une analyse.
En effet, le hook npm n’a modifié aucun fichier de workflow. Au lieu de cela, l’attaquant a ajouté un script caché à la racine du référentiel et une seule ligne dans package.jsonqui s’exécute sur chaque npm install. Les propres workflows inchangés du référentiel exécutés npm install comme hygiène de construction de routine.
Jeudi, l’attaquant avait également modifié sa méthode d’exfiltration. La dernière charge utile envoie les données volées uniquement à un chat Telegram, le rappel HTTP pointant désormais vers une adresse morte. Le blocage des adresses IP précédemment publiées n’arrête plus les dernières versions.
Ce que vole le malware
Une fois le script exécuté, il reçoit tous les secrets du référentiel et de l’organisation via un dump JSON de l’objet secrets du workflow. Il analyse la mémoire du processus d’exécution, qui contient des secrets sous forme déchiffrée, y compris ceux que le flux de travail n’a jamais référencés, et collecte des fichiers d’informations d’identification à partir de chemins bien connus, d’historiques de shell et de clés API pour les services d’IA et les outils de développement tels que OpenAI, Anthropic, Copilot et Cursor.
Le script va plus loin et échange des jetons OIDC pour les sessions AWS, GCP et Azure, crée de nouvelles clés d’accès AWS de longue durée, usurpe l’identité des comptes de service GCP et rejoue les jetons d’actualisation Azure mis en cache pour atteindre Microsoft Graph et Key Vault.
Il regroupe tout ce qu’il collecte dans une archive compressée et l’envoie à l’attaquant, puis il nettoie. Dans la plupart des référentiels, l’attaquant a annulé la validation malveillante en une minute et supprimé l’exécution du workflow et ses journaux.
Des portes dérobées qui survivent à la rotation des informations d’identification
Le script prend également des mesures pour permettre aux attaquants de conserver l’accès même si les informations d’identification sont réinitialisées. Pour AWS, il réécrit la politique de confiance du rôle assumé pour accepter n’importe quel compte AWS, ouvrant le rôle à n’importe qui, et appelle le iam:CreateAccessKey API pour créer des clés à long terme pour les utilisateurs IAM.
Sur Azure, il injecte des informations d’identification d’identité fédérée nommées wfx-ci-* dans les applications, en les redirigeant vers le référentiel compromis, afin que tout flux de travail de ce référentiel puisse s’authentifier auprès d’Azure sans secret stocké, même après la rotation de chaque jeton.
Si une demande d’extraction de sonde ou l’une des chaînes de validation de la campagne apparaît dans un référentiel que vous contrôlez, supposez que tous les secrets que les flux de travail du référentiel pourraient atteindre sont volés. Faites pivoter les secrets du référentiel et de l’organisation, les jetons de registre des packages et toutes les clés cloud, et rappelez-vous que l’analyse de la mémoire signifie que la liste de ce qui a été pris est plus large que celle référencée par les flux de travail.
Recherchez ensuite les signes des mécanismes persistants : les politiques de confiance des rôles AWS qui acceptent n’importe quel compte, les clés IAM créées depuis le 10 novembre et les informations d’identification fédérées Azure nommées. wfx-ci-*.
Le wfx-loot la charge utile est également livrée dans les packages publiés : le package Packagist neuronai-studio 3.14.3 et les modules Go docker-env et gocurl. Dans les modules Go, la charge utile se trouve uniquement dans un fichier de workflow que les outils Go n’exécutent jamais, de sorte que les consommateurs n’ont peut-être pas été affectés ; les machines qui ont installé la version Packagist doivent être traitées comme compromises.
Environ un cinquième des comptes GitHub utilisés pour lancer cette campagne avaient déjà été compromis lors de l’attaque GhostAction en octobre, a déclaré GitGuardian. Pendant ce temps, les chercheurs de StepSecurity ont retracé 173 des demandes d’extraction de sonde jusqu’aux jetons émis vers l’application Fly.io GitHub.
Fly.io a confirmé que ces jetons avaient été divulgués lorsque son processus de déploiement les avait laissés en place. .git/config fichiers dans les répertoires de construction que certaines applications ont servi publiquement, mais a noté que Fly.io lui-même n’avait pas été violé. La révocation massive par GitHub des jetons de l’application Fly.io s’est arrêtée à mi-chemin, de sorte qu’une partie du pool de jetons volés peut toujours être valide.
