GitHub Actions malveillants : 340 dépôts visés par un vol d’accès

Une campagne de vol d'identifiants a piraté deux comptes de mainteneurs et injecté un workflow GitHub Actions malveillant dans plus de 340 dépôts.
Les GitHub Actions malveillants sont au cœur d’une campagne de vol d’identifiants toujours en cours. Des chercheurs en cybersécurité ont détaillé la méthode utilisée. En effet, un attaquant a compromis les comptes de deux mainteneurs open source très en vue. Ensuite, il s’en est servi pour pousser un workflow piégé dans plus de 340 dépôts. Ainsi, l’affaire rappelle à quel point l’automatisation de la chaîne de développement est devenue une cible de choix.
GitHub Actions malveillants : ce que l'on sait de la campagne
D’après l’analyse de la société StepSecurity, l’attaquant ne s’est pas contenté de viser des projets anonymes. En effet, il a pris le contrôle de comptes appartenant à des développeurs reconnus. Il a donc obtenu la légitimité nécessaire pour modifier des dépôts. Par conséquent, les soupçons n’ont pas été éveillés immédiatement.
L’un des comptes détournés est celui de Takashi Kitao, auteur de pyxel. Il s’agit d’un moteur de jeu rétro qui totalise 18 400 étoiles sur GitHub. Depuis ce compte, un workflow malveillant a été poussé vers 27 dépôts, à partir de 13 h 20 UTC. De plus, un second compte de mainteneur très visible a été exploité de la même manière. Au total, la campagne touche plus de 340 dépôts.
Le workflow injecté a pour objectif de dérober des identifiants. Par ailleurs, l’opération est toujours active. Le décompte pourrait donc encore évoluer.
Pourquoi les workflows GitHub Actions malveillants font autant de dégâts
GitHub Actions permet d’exécuter automatiquement des tâches à chaque événement sur un dépôt. Il peut s’agir de tests, de compilation, de publication de paquets ou de déploiement. Ces fichiers de workflow sont stockés dans le dépôt lui-même. Or, ils s’exécutent dans un environnement qui a souvent accès à des éléments sensibles :
- des secrets de dépôt ou d’organisation, comme des jetons d’API ;
- des jetons d’authentification temporaires fournis par la plateforme ;
- des clés de publication vers des registres de paquets ou des services cloud.
Un attaquant qui parvient à ajouter ou modifier un workflow peut donc faire exécuter du code arbitraire dans cet environnement. Il peut également exfiltrer ces secrets. En revanche, une porte dérobée cachée dans le code applicatif est plus facile à repérer. Un fichier de workflow, lui, reste discret. Il se trouve en effet dans un répertoire que peu de relecteurs examinent attentivement.
Le maillon faible : le compte du mainteneur
Cette campagne illustre un schéma désormais classique des attaques sur la chaîne d’approvisionnement logicielle. Plutôt que d’exploiter une faille technique dans GitHub, l’attaquant s’appuie sur la confiance accordée à des personnes. Ainsi, un mainteneur disposant de droits d’écriture sur de nombreux dépôts devient un point d’entrée unique. Il ouvre la voie vers des dizaines, voire des centaines de projets.
L’effet multiplicateur est considérable. En effet, chaque dépôt touché peut détenir ses propres secrets. De plus, chaque secret volé peut ouvrir l’accès à d’autres systèmes, notamment les registres de paquets, les infrastructures cloud et les outils d’intégration continue. La compromission initiale de deux comptes peut donc se propager bien au-delà des dépôts directement modifiés.
GitHub Actions malveillants : quels risques pour les utilisateurs et les entreprises ?
Les projets concernés ne sont pas les seuls exposés. En effet, certaines organisations dépendent de ces dépôts. D’autres en consomment les paquets ou synchronisent leur contenu dans leurs propres pipelines. Toutes doivent donc se poser la question de leur exposition. Par ailleurs, les secrets exfiltrés pourraient servir à publier des versions altérées de logiciels. Ils pourraient aussi donner accès à des environnements de production. Enfin, ils pourraient permettre de poursuivre la campagne vers d’autres cibles.
Recommandations
Les détails sur cette campagne restent limités. Pourtant, plusieurs mesures s’imposent dès maintenant aux équipes qui utilisent GitHub :
- Auditer les workflows : examiner le répertoire
.github/workflowsde vos dépôts. Recherchez tout fichier ajouté ou modifié récemment, en particulier autour de l’horaire signalé de 13 h 20 UTC pour les dépôts liés aux comptes concernés. - Vérifier l’historique des commits et les journaux d’audit. Le but est de repérer des poussées inhabituelles depuis des comptes de mainteneurs.
- Renouveler les secrets : si un doute existe sur un dépôt, révoquer et régénérer les jetons, clés d’API et identifiants cloud accessibles par ses workflows.
- Renforcer les comptes : activer l’authentification multifacteur, de préférence avec des clés matérielles ou des passkeys. Il faut également révoquer les jetons d’accès personnels inutiles.
- Appliquer le moindre privilège : limiter les permissions du jeton fourni aux workflows. De plus, restreindre l’accès aux secrets aux seuls environnements qui en ont besoin.
- Protéger les branches : exiger des revues de code et des règles de protection pour les modifications touchant aux fichiers de workflow.
Ce qu’il faut retenir
Deux comptes de mainteneurs compromis ont suffi pour installer un workflow voleur d’identifiants dans plus de 340 dépôts. Parmi eux, 27 dépôts ont été touchés depuis le seul compte de l’auteur de pyxel. La campagne étant toujours en cours, la prudence commande d’agir vite. Il faut d’abord auditer sans délai les fichiers de workflow. Ensuite, il convient de faire tourner les secrets potentiellement exposés. Enfin, il faut durcir la sécurité des comptes disposant de droits d’écriture étendus.
Source : Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories