if ( !emtpy($headline_subheadline ) ) : ?>
Les jetons GitHub volés ont alimenté une campagne qui a implanté des flux de travail GitHub Actions malveillants pour voler les informations d’identification du référentiel et du cloud.
endif; ?>
Un acteur malveillant surnommé Gheist transforme les comptes GitHub compromis en plateformes de collecte d’informations d’identification. En implantant des flux de travail GitHub Actions malveillants dans des référentiels privés, les attaquants peuvent exposer les secrets du référentiel et de l’environnement, puis les récupérer via les API GitHub avant de supprimer les preuves de l’activité.
Suivie depuis le 15 septembre par Wiz Research, la campagne a laissé plus de 13 500 branches malveillantes sur plus de 850 comptes compromis, couvrant des projets personnels et des référentiels d’entreprises privées.
L’arme de la campagne est GitHub Actions, le service d’automatisation de la plateforme, que les attaquants utilisent pour transformer les accès volés en identifiants récupérés. L’automatisation crée une branche, ajoute un workflow nommé « sync-check » qui tente d’imprimer des secrets dans les journaux d’exécution, récupère ces journaux via l’API GitHub et supprime le workflow exécuté quelques secondes plus tard.
« Étant donné que les secrets sont transmis via la propre API de GitHub, il n’y a aucun domaine d’attaquant ni connexion sortante à bloquer », ont déclaré les chercheurs de Wiz dans un article de blog.
GitHub a introduit un contrôle qui conserve les exécutions de flux de travail potentiellement malveillants dans des référentiels publics pour approbation des collaborateurs. Wiz a signalé que cette mesure avait réussi à empêcher l’exécution des exécutions Gheist du référentiel public. Cependant, la protection ne s’étend pas aux référentiels privés ou à GitHub Enterprise Server, où les chercheurs ont observé une exécution réussie et une activité ultérieure.
Codage Base32 utilisé pour contourner le masquage secret
Les acteurs du Gheist ont été vus en train de profiter de l’écart entre le mécanisme de masquage des secrets de GitHub Actions et la manière dont les flux de travail peuvent accéder aux valeurs sensibles.
GitHub masque les valeurs secrètes lorsqu’elles apparaissent textuellement dans les journaux. Cependant, un workflow créé par Gheist encode ces secrets en base32 avant de les imprimer, de sorte qu’ils ne correspondent plus aux valeurs d’origine. Par conséquent, ils apparaissent dans les logs sans être masqués. Dans les référentiels qui utilisent des environnements de déploiement, tels que la production, Gheist a créé plusieurs tâches de workflow pour cibler les secrets spécifiques à l’environnement.
Cela a potentiellement exposé non seulement les secrets stockés au niveau du référentiel, mais également les informations d’identification sensibles utilisées pour exécuter les systèmes de production.
Gheist a ensuite évolué pour cibler les coureurs GitHub Actions auto-hébergés. Son travail d’hôte de synchronisation ajouté tente de rechercher sur les hôtes d’exécution des jetons API, des clés privées, des fichiers d’environnement, des informations d’identification cloud et d’autres données sensibles. Il tente également d’accéder au socket Docker, aux métadonnées de l’instance cloud et aux jetons du compte de service Kubernetes.
Wiz a noté que la variante évoluée contient des bogues d’implémentation, il ne faut donc pas supposer une extraction réussie de chaque identifiant ciblé.
Un problème plus large de sécurité du cloud
Wiz a observé que les informations d’identification cloud de la même organisation étaient utilisées des heures après l’exécution des flux de travail malveillants pour énumérer AWS Secrets Manager. Les enregistrements CloudTrail montraient également des flux de travail sur des branches créées par des attaquants assumant des rôles AWS, fournissant ainsi des preuves d’exécution même lorsque les journaux GitHub n’étaient pas disponibles.
Wiz a retracé les sources d’informations d’identification probables jusqu’aux journaux et jetons des voleurs d’informations exposés lors de compromissions antérieures de la chaîne d’approvisionnement, y compris le compromis de March Trivy. Les chercheurs ont également identifié des chevauchements entre les comptes concernés et d’autres activités malveillantes, notamment des référentiels renommés pour distribuer des leurres de logiciels piratés et des tentatives d’abus des actions GitHub pour obtenir des ressources informatiques gratuites.
Il a été conseillé aux équipes de sécurité de rechercher les branches correspondant à « ci-sync- », suivies de six caractères aléatoires, des commits intitulés ci : sync config et des exécutions de flux de travail qui se terminent et sont supprimées peu de temps après. Ils doivent également enquêter sur les hypothèses de rôle cloud associées à ces branches, révoquer les jetons compromis et alterner chaque secret de référentiel, d’organisation et d’environnement accessible aux flux de travail concernés. La suppression d’une branche ou d’une exécution n’annule pas l’exposition des informations d’identification, ont prévenu les chercheurs.
