Depuis le 10 novembre, des attaquants exploitent près de 5 000 comptes GitHub compromis pour introduire du code malveillant dans les chaînes de développement logiciel. Selon une enquête publiée ce 12 novembre par Aikido Security, plus de 61 000 dépôts ont été sondés et au moins 1 806 ont exécuté un programme destiné à voler des identifiants et des accès cloud. Les pirates effacent ensuite leurs modifications et les journaux d’exécution pour dissimuler leur passage.
Des comptes légitimes utilisés pour infiltrer les dépôts
L’attaque débute par une demande de modification apparemment anodine, intitulée « docs: dependency audit notes », envoyée depuis un compte GitHub disposant déjà de droits sur le projet. Les pirates vérifient ainsi leurs possibilités d’écriture avant d’introduire du code malveillant dans les dépôts accessibles.
D’après l’enquête d’Aikido Security publiée le 12 novembre, 4 837 comptes compromis ont été utilisés pour sonder 61 764 dépôts depuis le 10 novembre. Plus de 10 000 demandes concernaient des projets n’appartenant pas aux titulaires des comptes, mais auxquels ceux-ci étaient autorisés à contribuer. Les droits accordés à un développeur pouvaient ainsi donner aux attaquants accès aux ressources d’une autre organisation.
Plutôt que d’exploiter une vulnérabilité de GitHub, les pirates utilisent des identifiants volés pour modifier les fichiers de GitHub Actions, qui automatisent les tests, la compilation et le déploiement des logiciels. Ils peuvent également introduire un script exécuté lors de l’installation des dépendances ou créer temporairement un nouveau workflow.
Des secrets dérobés, puis des traces effacées
Le programme malveillant cherche à récupérer les secrets accessibles aux processus automatisés : jetons GitHub, clés API, identifiants cloud et informations stockées dans les variables d’environnement. Ces données servent notamment à connecter les applications à des services extérieurs et à automatiser leur déploiement. Les attaquants tentent ainsi de récupérer des accès dépassant largement le dépôt visé, notamment des identifiants AWS, Azure et Google Cloud, avant de transmettre les informations collectées à des serveurs extérieurs.
Une fois le programme exécuté, les modifications sont annulées, parfois en moins d’une minute, et les journaux d’exécution supprimés. Le dépôt retrouve alors son apparence habituelle, sans que cela garantisse la sécurité des secrets auxquels les attaquants ont pu accéder. Selon Aikido, des numéros manquants dans l’historique des exécutions GitHub Actions peuvent constituer l’un des rares indices de leur passage.
Les chercheurs ont confirmé l’exécution du programme dans au moins 1 806 dépôts. L’examen d’un échantillon de 1 500 dépôts sondés laisse toutefois penser que ce nombre pourrait atteindre environ 6 500. Il s’agit d’une estimation, la suppression des journaux rendant difficile un décompte exhaustif.
Une compromission qui peut dépasser le projet initial
Du code malveillant a également atteint au moins deux composants logiciels distribués publiquement, l’un dans l’écosystème PHP via Packagist, l’autre dans celui de Go. Leur publication semble avoir été provoquée par le déclenchement automatique des processus de distribution après la modification des dépôts, plutôt que par une attaque visant spécifiquement ces paquets. Les pirates peuvent ainsi tirer parti des mécanismes de publication automatisée pour diffuser du code compromis au-delà des projets directement ciblés, avec des conséquences possibles pour les utilisateurs des logiciels concernés.
Aikido relève par ailleurs un important chevauchement avec les comptes visés lors de précédentes campagnes GhostAction, notamment en octobre. Malgré des similitudes dans les méthodes employées, les chercheurs ne disposent pas d’éléments suffisants pour attribuer cette nouvelle vague aux mêmes opérateurs. La réutilisation de comptes compromis laisse néanmoins penser que certains accès volés restent actifs plusieurs semaines après leur découverte.
Pour les organisations concernées, la suppression des fichiers suspects ne suffit pas. Aikido recommande d’examiner les demandes de modification inhabituelles, de rechercher les exécutions manquantes dans les historiques et de renouveler les secrets auxquels les workflows compromis ont pu accéder. Les modifications visibles dans le code ne permettent pas, à elles seules, de déterminer quels identifiants ont été dérobés.
