Les attaques utilisent des identifiants volés pour insérer un voleur secret dans GitHub Actions

Depuis mardi, les assaillants avec des pouvoirs volés de 4837 comptes GitHub ont introduit une voleur secret dans les flux continus d'intégration (CI) des dépôts auxquels ces comptes pourraient écrire, selon l'analyse technique publiée par la firme Aikido Security. Le code malveillant a été conçu pour exfilter n'importe quel secret ou justificatif dans le cadre des exécutions de GitHub Actions et pour pivoter dans les comptes cloud en utilisant des jetons OIDC et d'autres justificatifs qu'il a récupérés du coureur.

Les faits confirmés par Aikido et d'autres firmes qui ont publié des analyses complémentaires sont clairs sur plusieurs points: l'attaquant a ouvert des tests initiaux en utilisant les «docs: notes d'audit de dépendance» de succursales appelées wfx-docs dans au moins 61,764 dépôts publics visibles pour Aikido; dans 1 806 de ces dépôts, le voleur est venu à être exécuté et probablement des données exfiltrées; et au total 4 837 comptes ont été utilisés pour ouvrir les preuves. SafeDep, qui a effectué un balayage indépendant, a compté 8 093 dépôts qui ont reçu des engagements malveillants dans la fenêtre qu'ils ont analysée, indiquant que la portée réelle peut être plus grande parce que les deux comptes ne considèrent que les succursales par défaut et les dépôts publics visibles pour chaque chercheur.

Techniquement, l'attaque a suivi un modèle répétitif : ouvrir une PR de wfx-docs pour vérifier si le compte attaqué avait un permis d'écriture ; si la vérification était positive, un pas (le flux de travail) ou un crochet post-installation en npm lui a été ajouté qui a exécuté un script, dont la somme est SHA-256, 89695abb392d5cfd4972672961e644b46baa98aa1ed7173c2a2816c762735cf. Ce script / binaire tente de collecter des clés et des jetons à partir de plusieurs sources locales du coureur - variables et secret d'Actions, GITHUB _ TOKEN, jetons d'exécution, métadonnées d'instance dans des coureurs auto-organisés, fichiers de configuration AWS / Azure / GCP, clés SSH, dispositifs de workflow et même secrets résiduels dans la mémoire de processus - et ensuite exfilter HTTP POST vers des serveurs observés (par exemple 194.150.166 [.] 244: 8080, 18.143.168 [en 1580], selon un canal 153.80.

Une fois que le voleur a obtenu des identifiants OIDC ou jetons valides, il pourrait les échanger contre des sessions AWS / GCP / Azure et, dans le cas de AWS, créer des clés d'accès à long terme et modifier la politique de confiance pour fournir un accès aux comptes externes. Dans Azure, la création d'identificateurs fédérés avec des préfixes tels que wfx-ci- a été observée qui permettent une authentification fédérée persistante à partir de flux de travail. Plusieurs de ces opérations sont conçues pour résister aux rotations clés.

Les indicateurs techniques fournis par Aikido - noms de branches (wfx-docs, core / [a-z0-9] {8}, ci-check- [0-9] {4}), titre de PR spécifique, messages de commit fréquents (par exemple "ci: rafraîchir le cache de compilation", "chore: ajouter ci helper", "chore: ajouter le workflow d'audit de dépendance") et l'impression SHA-256 de la charge utile - permettent de détecter les impressions de campagne. Aikido souligne également que tout compte utilisé pour ouvrir un de ces PR devrait être considéré comme compromis même si le voleur n'a pas été exécuté, parce que la possession de lettres de créances a été démontrée par la capacité de créer des succursales et des PR d'eux.

Impact et portée pratiques: En plus des dépôts individuels, l'attaquant a atteint des pipelines et des paquets de publication automatisés. Aikido identifie une version malveillante dans Packagist (digitalelvis / neuronai-studio v3.14.3) et deux versions d'un module Go qui contient le voleur dans son workflow (github.com / onuragtas / docker-env v1.0.278 et v1.0280). Dans certains cas, le code source ou les binaires n'ont pas été modifiés; le risque provient de la présence de la charge utile dans les fichiers de workflow ou des crochets de npm postinstall qui auraient été exécutés sur les machines de développement. Ceux qui ont installé des paquets avec ce post-install ou exécuté npm installer dans les dépôts affectés doivent prendre l'engagement de la machine et agir en conséquence.

Ce que l'on sait avec incertitude : les analyses n'ont pas permis d'identifier publiquement la façon dont les 4 837 comptes ont été initialement obtenus, ni l'attribution définitive de l'acteur. Aikido indique un chevauchement avec les comptes affectés par la vague connue sous le nom de GhostAction en octobre, mais n'attribue pas automatiquement les deux événements au même opérateur parce que les infrastructures et les méthodes montrent des différences et parce que les pouvoirs volés peuvent être partagés entre plusieurs attaquants.

Les conséquences réelles que les responsables doivent assumer incluent la perte de secrets et l'escalade possible vers des environnements nuageux entiers (création clé, modification des politiques, incorporation de fédération). Dans les dépôts où le voleur a été exécuté, tout ce que le flux de travail pourrait lire doit être considéré comme compromis y compris les actions secrètes, les variables, les jetons OIDC, et les rôles / références dans AWS / Azure / GCP.

Mesures spécifiques et ordre de priorité: Tout d'abord, traitez tout compte qui a ouvert un test comme engagé. Vérifiez immédiatement les jetons d'accès personnels, les subventions OAuth, les clés SSH et les sessions. Activer l'authentification de deux facteurs (2FA) dans les comptes avec des permissions écrites. Dans les dépôts affectés, tourner et remplacer tous les secrets et les variables que le workflow pourrait lire et envisager de régénérer toute clé API accessible à partir de l'exécution.

Pour rechercher des portes arrière dans le cloud, consultez les événements et objets suivants (formulaires de détection suggérés) : dans Azure AD, recherchez des identifiants fédérés avec wfx-ci- * préfixe ; dans AWS CloudTrail, cherchez AssumeRoleWithWebIdentity ou des sessions dont le nom contient wfx- * suivi de CreateAccessKey ou UpdateAssumeRole Policy ; dans GCP trace GénérezAccessToken et SignJwt à partir de leur pool d'identité de charge de travail. Inspectez également le journal Vault pour la connexion JWT à partir de l'émetteur GitHub OIDC. Ces recherches correspondent aux signaux que Aikido et SafeDep ont mis en évidence.

Si votre dépôt a reçu le commit malveillant mais que le workflow n'est pas venu à être exécuté, il révoque toujours les lettres d'identité de l'auteur et pourrit les secrets: Aikido précise que la simple capacité à pousser les commits confirme le contrôle du compte. Si vous exécutez une installation npm dans une copie contenant le crochet malveillant, traitez la machine comme compromise : faites une réinstallation de zéro, retirez les identifiants stockés localement et faites pivoter l'API et les jetons utilisés de cet environnement.

Pour réduire la surface à l'avenir, appliquer les pratiques de durcissement pour GitHub Actions : accorder le moins de privilèges possible aux jetons, limiter les permissions de GITHUB _ TOKEN et permettre l'authentification OIDC avec audit ; utiliser des coureurs auto-organisés avec isolement et sans métadonnées accessibles si nécessaire ; et mettre en place des règles pour bloquer les engagements ou les PR des branches ou messages suspects. GitHub tient à jour la documentation sur le durcissement et l'OIDC qui peut servir de guide pratique : GitHub - Durcissement de sécurité avec OpenID Connect et GitHub - Durcissement de sécurité pour GitHub Actions.

De plus, auditer les activités STS et OIDC dans les fournisseurs de cloud; par exemple, l'API AWS pour AssumeRoleWithWebIdentity et son utilisation sont documentés ici: AWS STS - AssumerRoleAvecWebIdentity. Ces recherches aident à détecter les tentatives d'échange de jetons et de créer des clés dont le voleur profite.

Résumé: La campagne a montré un modèle automatisé et efficace: l'utilisation des identifiants volés pour insérer un voleur dans les flux de travail et les crochets qui exfiltrent les secrets et grimpent vers les environnements nuageux. Si votre organisation utilise GitHub Actions, tout dépôt dans lequel un compte a ouvert le PR d'essai devrait être considéré comme à risque jusqu'à la révocation des pouvoirs, la rotation des secrets et l'audit du cloud et des coureurs. L'absence d'attribution claire et la possibilité que l'acteur persiste par la fédération impliquent que la réponse doit être large et rapide.