La campagne Gheist vole des secrets de dépôts GitHub privés via les journaux Actions

Une nouvelle campagne d'attaque automatisée nommée Gheist exploite des jetons GitHub volés pour extraire des données sensibles de dépôts privés. Depuis la mi-septembre, les chercheurs en sécurité de Wiz ont observé des attaquants injectant des workflows malveillants qui impriment directement les secrets du dépôt dans les journaux GitHub Actions. Ces attaques ciblent spécifiquement les dépôts privés et les instances GitHub Enterprise Server, où les protections automatiques existantes sont moins efficaces.

Ce qui s'est passé

La campagne Gheist fonctionne en utilisant des identifiants compromis pour créer de nouvelles branches dans les dépôts ciblés. Chaque branche suit un modèle de nommage spécifique, commençant par ci-sync- suivi de six caractères aléatoires. Les attaquants committent un seul fichier de workflow sur ces branches, conçu pour s'exécuter immédiatement lors du push. Ce workflow accède aux variables d'environnement et aux secrets du dépôt, les encode au format base32 avant de les imprimer sur la sortie standard. Comme les données sont encodées, elles contournent les fonctionnalités de masquage automatique des secrets de GitHub, permettant aux valeurs complètes d'apparaître dans les journaux de build.

Une fois le workflow terminé, l'outil de l'attaquant télécharge le fichier journal via l'API GitHub, puis supprime l'exécution du workflow et la branche elle-même. Cette suppression rapide rend la détection difficile, car les preuves disparaissent rapidement. Wiz rapporte que bien que GitHub ait mis en place une protection qui suspend les exécutions de workflows suspectes dans les dépôts publics, cette protection ne s'étend actuellement pas aux dépôts privés ni aux installations auto-hébergées de GitHub Enterprise Server. Par conséquent, chaque tentative sur un dépôt public analysée par Wiz a été bloquée, mais les environnements privés et d'entreprise sont restés vulnérables à une exfiltration réussie.

L'ampleur de la campagne est significative. Wiz a identifié plus de 13 500 branches injectées sur plus de 850 comptes compromis. Ces comptes vont des développeurs individuels aux grandes organisations d'entreprise. Dans certains cas d'entreprise, les attaquants ont fait tourner plusieurs jetons d'utilisateur et d'automatisation en quelques minutes, clonant du code privé et injectant des workflows dans plusieurs dépôts. Les jetons volés provenaient souvent de logiciels espions (infostealers) ou de compromissions antérieures de la chaîne d'approvisionnement, comme l'incident de mars impliquant le scanner de vulnérabilités Trivy.

Détails clés

• La campagne utilise la chaîne d'agent utilisateur gheist pour toutes les requêtes API.
• Les branches malveillantes sont nommées ci-sync- suivi de six caractères alphanumériques minuscules.
• Le fichier de workflow commité est toujours .github/workflows/sync-check.yml avec le message ci: sync config.
• Les secrets sont exfiltrés en les encodant en base32 pour contourner le masquage des journaux de GitHub.
• La mise en attente automatique de GitHub pour les exécutions suspectes ne s'applique actuellement qu'aux dépôts publics sur github.com.
• Wiz a récupéré plus de 13 500 branches injectées provenant de plus de 850 comptes compromis depuis le 15 septembre.

Contexte

GitHub Actions permet aux développeurs d'automatiser des workflows logiciels, tels que la construction et les tests de code. Ces workflows nécessitent souvent l'accès à des informations sensibles comme les clés API, les mots de passe de bases de données et les identifiants cloud, qui sont stockés sous forme de secrets de dépôt. Par défaut, tout utilisateur disposant d'un accès en écriture à un dépôt peut lire ces secrets. Lorsqu'un workflow s'exécute, GitHub tente de masquer les valeurs de secrets connues dans les journaux pour prévenir une exposition accidentelle. Cependant, ce masquage repose sur une correspondance exacte des chaînes de caractères. Si un secret est modifié, par exemple en l'encodant en base32 ou en le divisant en parties, GitHub peut échouer à le reconnaître et à le masquer, laissant la valeur brute visible dans les journaux.

La distinction entre les protections des dépôts publics et privés est cruciale ici. GitHub a récemment introduit une fonctionnalité qui met en attente les exécutions de workflows provenant de sources non vérifiées pour approbation manuelle dans les dépôts publics. Cela agit comme une barrière solide contre l'abus automatisé dans les projets open source. Cependant, cette fonctionnalité n'est pas encore disponible pour les dépôts privés ou GitHub Enterprise Server, que de nombreuses entreprises utilisent pour leurs logiciels propriétaires internes. Cette lacune laisse les environnements auto-hébergés et privés dépendants d'autres mesures de sécurité, telles qu'une gestion stricte des jetons et la journalisation d'audit, qui peuvent être plus difficiles à surveiller en temps réel.

Pourquoi cela compte

Pour les équipes qui exécutent leur propre logiciel ou gèrent des bases de code privées, cet incident met en évidence un maillon fragile dans la chaîne de sécurité CI/CD. L'hypothèse selon laquelle les journaux sont sûrs parce que les secrets sont masqués n'est plus valide. Les attaquants utilisent activement des techniques d'encodage pour contourner ces protections. Si votre organisation utilise GitHub Actions pour le déploiement, en particulier avec des runners auto-hébergés ou des dépôts privés, vos secrets sont à risque si un jeton est compromis. Le fait que les attaquants suppriment les exécutions immédiatement signifie que la surveillance traditionnelle pourrait manquer l'événement entièrement, sauf si vous avez activé et examinez activement des journaux d'audit détaillés.

De plus, la campagne démontre l'effet domino du vol de jetons. Un seul jeton d'accès personnel ou identifiant d'automatisation volé peut mener à la compromission de toute l'infrastructure cloud d'une organisation. Dans les cas analysés par Wiz, les attaquants ont utilisé l'accès initial pour assumer des rôles AWS via OIDC, obtenant potentiellement un contrôle plus large sur les ressources cloud. Pour les responsables IT et les ingénieurs DevOps, cela signifie que sécuriser le pipeline CI/CD ne concerne pas seulement la qualité du code, mais aussi la protection des clés de votre environnement de production. L'absence de blocage automatique dans les dépôts privés place la charge de la détection entièrement sur l'équipe de sécurité interne.

Ce que vous pouvez faire

• Recherchez dans vos dépôts les branches correspondant au modèle ci-sync- suivi de six caractères et supprimez-les si trouvées.
• Faites pivoter tous les secrets de dépôt, d'organisation et d'environnement immédiatement si vous suspectez une compromission de jeton.
• Examinez les journaux d'audit GitHub pour les exécutions de workflows sur les branches ci-sync-* qui ont été supprimées dans la minute suivant leur achèvement.
• Vérifiez les journaux des fournisseurs cloud, tels qu'AWS CloudTrail, pour les hypothèses de rôle liées aux sujets des branches ci-sync-.
• Révoquez tout jeton associé aux comptes compromis et scannez les appareils des propriétaires pour détecter des logiciels espions (infostealers).
• Exigez une approbation manuelle du reviewer pour les déploiements vers des environnements contenant des secrets de production.