Attaque massive sur GitHub CI : vol de secrets dans des milliers de dépôts

Depuis mardi, une cyberattaque coordonnée a exploité des identifiants volés provenant de 4 837 comptes GitHub pour infiltrer les chaînes d'approvisionnement logicielles. Les attaquants ont implanté du code malveillant conçu pour voler des secrets et des identifiants cloud issus des workflows d'intégration continue (CI) dans au moins 1 806 dépôts. Cette campagne met en évidence les risques graves associés aux identités développeurs compromises et aux pipelines de build automatisés.

Ce qui s'est passé

L'attaque a commencé par l'ouverture de pull requests de test intitulées "docs: dependency audit notes" depuis des branches nommées "wfx-docs". Ces tests ont été déployés sur 61 764 dépôts pour vérifier l'accès en écriture. Dans les dépôts où l'accès était accordé, l'attaquant a injecté un voleur de secrets dans la configuration CI. Selon Aikido Security, ce voleur était conçu pour collecter les secrets, les identifiants cloud et les jetons d'exécution accessibles à l'environnement du workflow. Les chercheurs de SafeDep ont identifié 8 093 dépôts ayant reçu des commits malveillants entre 12h46 UTC mardi et 04h36 UTC le jour suivant, notant que le nombre réel est probablement plus élevé car leur analyse ne couvrait que les branches par défaut publiques.

Une fois le voleur exécuté, il exfiltrait généralement les données via HTTP POST vers des adresses IP spécifiques ou via des chats Telegram. L'attaquant rétablissait souvent les modifications dans les minutes qui suivaient et supprimait les logs d'exécution du workflow pour dissimuler les preuves. Cependant, dans de nombreux cas, les dégâts étaient déjà faits. Le voleur ciblait un large éventail d'identifiants, notamment les secrets GitHub Actions, les jetons OIDC et les clés pour AWS, Azure, GCP et Kubernetes. Dans certains cas, le malware était introduit via des hooks postinstall npm, ce qui signifie que tout développeur ayant exécuté "npm install" sur le commit affecté risquait de compromettre sa machine locale.

Détails clés

• Échelle : 4 837 comptes GitHub ont été compromis, avec des pull requests de test envoyées à 61 764 dépôts.
• Impact : Le voleur a fonctionné dans au moins 1 806 dépôts, avec des commits malveillants trouvés dans plus de 8 093 dépôts.
• Méthode : Les attaques ont commencé par des pull requests intitulées "docs: dependency audit notes" provenant de branches "wfx-docs".
• Persistance : Le malware crée des backdoors dans AWS et Azure qui survivent à la rotation des identifiants, comme la réécriture des politiques de confiance.
• Indicateurs : Recherchez des branches telles que "wfx-docs", "chore/[a-z0-9]{8}" ou des messages de commit tels que "ci: refresh build cache".
• Paquets affectés : Des versions malveillantes ont été trouvées dans le paquet Packagist digitalelvis/neuronai-studio v3.14.3 et plusieurs modules Go.

Contexte

Les systèmes d'intégration continue (CI) comme GitHub Actions automatisent le processus de compilation, de test et de déploiement du code. Pour fonctionner, ces workflows nécessitent souvent l'accès à des identifiants sensibles, tels que des clés de fournisseur cloud ou des mots de passe de base de données. Ces secrets sont stockés dans les paramètres du dépôt et injectés dans l'environnement du runner lors de l'exécution. Si un attaquant obtient un accès en écriture à un dépôt, il peut modifier les fichiers de workflow pour inclure des étapes malveillantes qui impriment ou envoient ces secrets vers un serveur externe.

Cette attaque exploite spécifiquement les jetons OpenID Connect (OIDC), qui permettent aux runners CI de s'authentifier auprès des fournisseurs cloud sans stocker de secrets à longue durée de vie. En volant ces jetons à courte durée de vie, l'attaquant peut demander de nouvelles sessions auprès des fournisseurs cloud. Plus dangereux encore, le voleur inclut une logique pour créer des backdoors persistants, tels que l'ajout d'identifiants de fédération en Azure ou la création de clés d'accès à longue durée de vie en AWS. Cela garantit que l'attaquant maintient son accès même après la rotation des jetons initialement compromis.

Pourquoi c'est important

Pour les équipes qui exécutent leurs propres logiciels ou gèrent des infrastructures auto-hébergées, cet incident souligne l'importance critique de sécuriser les pipelines CI/CD. De nombreuses organisations partent du principe que, parce que leur code est privé ou que leurs runners sont auto-hébergés, elles sont immunisées contre de telles attaques. Cependant, le voleur a été conçu pour cibler les dépôts privés et les runners auto-hébergés, extrayant les identifiants des métadonnées d'instance et des états des conteneurs Docker. Si votre pipeline CI dispose de permissions étendues, un seul commit compromis peut mener à la prise de contrôle complète d'un compte cloud.

Les mécanismes de persistance utilisés par l'attaquant rendent la remédiation difficile. La simple rotation des secrets est insuffisante si l'attaquant a modifié les politiques d'identité cloud. Les équipes doivent auditer leurs configurations cloud pour détecter les identifiants de fédération non autorisés ou les changements de politique de confiance. De plus, l'utilisation de hooks postinstall npm signifie que la menace s'étend au-delà de l'environnement CI aux postes de travail des développeurs. Tout membre de l'équipe ayant récupéré le code malveillant a pu installer involontairement un malware, nécessitant un effort de réponse à l'incident plus large.

Ce que vous pouvez faire

• Auditer les dépôts : Recherchez des branches nommées "wfx-docs", "chore/[a-z0-9]{8}" ou des pull requests avec le titre "docs: dependency audit notes".
• Faire tourner les identifiants : Faites immédiatement tourner tous les secrets, variables et jetons dans les dépôts affectés. Révoquez les autorisations des applications OAuth et les clés SSH pour les comptes compromis.
• Vérifier les logs cloud : Recherchez des activités inhabituelles dans AWS CloudTrail, Azure Entra ID et les logs GCP, spécifiquement pour "AssumeRoleWithWebIdentity" ou des identifiants de fédération préfixés par "wfx-ci-".
• Inspecter les machines locales : Si vous avez exécuté "npm install" sur un commit potentiellement affecté, traitez votre machine comme compromise et faites tourner les clés locales.
• Bloquer les paquets malveillants : Épinglez digitalelvis/neuronai-studio à la version v3.14.2 ou antérieure et supprimez les versions affectées de github.com/onuragtas/docker-env et github.com/vkuznet/gocurl.
• Activer l'authentification à deux facteurs (2FA) : Assurez-vous que l'authentification à deux facteurs est activée pour tous les comptes GitHub afin de prévenir les attaques par bourrage d'identifiants.