Aikido : 4 837 comptes GitHub détournés pour voler des secrets

Aikido : 4 837 comptes GitHub détournés pour voler des secrets

Ajoutez CyberWorldOpsà vos sources préférées sur Google
Aikido : 4 837 comptes GitHub détournés pour voler des secrets
Malware

Image d’illustration générée par IA

Des identifiants volés de 4 837 comptes GitHub ont permis à un attaquant de déployer un logiciel malveillant ciblant les secrets des dépôts et l'accès au cloud, selon les conclusions d'Aikido Security rapportées par The Hacker News, publiées le 12 novembre. La campagne a débuté le mardi 10 novembre, et le logiciel malveillant s'est exécuté dans au moins 1 806 dépôts, où Aikido estime que des identifiants ont probablement été volés.

Les propriétaires de dépôts, les administrateurs d'organisation et les développeurs ayant installé le code affecté ne font pas face aux mêmes risques. Aikido considère comme compromis tout compte utilisé pour ouvrir les pull requests de test de l'attaquant, que le logiciel malveillant ait ensuite été exécuté ou non. Lorsqu'une exécution a eu lieu, tous les secrets et rôles cloud accessibles aux workflows automatisés doivent être considérés comme compromis.

Les sondes d'accès en écriture ont atteint 61 764 dépôts

L'attaquant a vérifié les autorisations de chaque compte sur ses dépôts en soumettant une pull request (une proposition de modification du code) intitulée docs: dependency audit notes, depuis une branche wfx-docs. Aikido a repéré ces sondes dans 61 764 dépôts. Les autorisations de collaborateur ou d'organisation représentaient 10 431 pull requests de test, ce qui étend la campagne au-delà des dépôts appartenant aux comptes volés. Au moment de la vérification, 92 % de ces requêtes étaient encore ouvertes.

La plupart des dépôts sondés n'ont reçu aucune charge utile ultérieure, ou disposaient de paramètres ou d'autorisations de compte qui empêchaient l'exécution. La visibilité d'Aikido se limitait aux dépôts publics, même si les paramètres propres aux dépôts privés présents dans le logiciel malveillant laissent penser qu'il pourrait aussi opérer en privé.

SafeDep, une entreprise spécialisée dans la sécurité de la chaîne d'approvisionnement logicielle, a identifié séparément des commits malveillants dans 8 093 dépôts entre le 10 novembre à 12 h 46 (UTC) et le 12 novembre à 4 h 36 (UTC). Cette mesure traduit la livraison, et non l'exécution. Sa recherche n'a porté que sur les branches par défaut des dépôts publics, ce qui a conduit les chercheurs à estimer que le total réel était plus élevé.

Les workflows d'intégration continue (CI) existants, c'est-à-dire des tâches automatisées qui compilent et vérifient le code, ont reçu la charge utile dans 7 309 dépôts. 771 autres dépôts l'ont reçue via un hook npm postinstall, un script déclenché par npm install qui peut aussi s'exécuter sur l'ordinateur d'un développeur.

L'activité s'est poursuivie au-delà de la recherche d'Aikido, qui s'est achevée mercredi. The Hacker News a vérifié trois pull requests supplémentaires ouvertes entre 5 h 04 et 5 h 38 (UTC) le 12 novembre : chacune utilisait le même titre et une branche wfx-docs, bien que la livraison ultérieure d'un logiciel malveillant reste incertaine.

Ce que le logiciel malveillant peut voler et conserver

Aikido décrit un voleur conçu pour fouiller le runner, la machine qui exécute un workflow, à la recherche d'identifiants. Ses cibles comprennent les secrets et variables GitHub Actions, GITHUB_TOKEN, les jetons d'exécution d'Actions, les clés de services d'IA et les secrets conservés dans la mémoire des processus. Il lit aussi les fichiers d'identifiants utilisés par AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH et d'autres outils.

La collecte s'étend au contenu des dépôts, aux 100 derniers commits et aux artefacts de workflow récents, c'est-à-dire aux sorties de tâches enregistrées. Sur les runners auto-hébergés, le logiciel cible en plus les identifiants cloud exposés via les métadonnées d'instance, l'état des conteneurs Docker et les unités systemd, qui définissent les services système.

SafeDep a identifié deux voies d'envoi des données volées : des requêtes HTTP POST vers des serveurs de l'attaquant et des messages vers une conversation Telegram. Environ un cinquième des 200 commits de charge utile échantillonnés reposaient exclusivement sur Telegram.

L'accès au cloud peut persister au-delà du remplacement des secrets d'origine. Le logiciel peut échanger des jetons GitHub OpenID Connect (OIDC), c'est-à-dire des assertions d'identité que les workflows utilisent pour demander un accès au cloud, contre des sessions AWS, GCP et Azure. Ses capacités sur AWS incluent la création de clés d'accès de longue durée pour des utilisateurs Identity and Access Management (IAM) et la modification de la politique de confiance d'un rôle afin d'admettre n'importe quel compte AWS.

Pour les applications Azure AD, il peut créer des identifiants fédérés dont le nom commence par wfx-ci-. Ceux-ci établissent une relation de connexion de confiance, permettant aux workflows du dépôt compromis de s'authentifier sans secret stocké, même après rotation des jetons.

Aikido a également relevé un lien avec la campagne GhostAction d'octobre, qui avait utilisé des comptes GitHub volés pour introduire des workflows de vol de secrets. Les comptes touchés à l'époque avaient environ 1 000 fois plus de chances que les autres comptes actifs d'apparaître dans l'activité de novembre. Dans plus de 100 dépôts, la dernière charge utile a été ajoutée aux fichiers de workflow d'octobre sans supprimer leur étape de vol de données existante. Aikido s'est abstenu d'attribuer ces attaques au même acteur, car l'infrastructure, les outils et les méthodes diffèrent, et des identifiants volés peuvent circuler entre plusieurs attaquants.

L'exposition des paquets dépend de l'utilisation du code

Les déclencheurs de publication automatisée ont transmis le logiciel malveillant à au moins un paquet Packagist et à un module Go. Au moins 50 utilisateurs compromis semblent publier via npm, Go, Packagist, PyPI ou crates, bien qu'Aikido estime que l'objectif apparent de l'attaquant était d'obtenir les secrets de CI.

La version malveillante sur Packagist est digitalelvis/neuronai-studio version 3.14.3. Sa fiche indiquait une date de publication du 11 novembre ; au début du 12 novembre, elle restait disponible sous un avertissement signalant que ses versions avaient été marquées comme malveillantes. Aikido conseille de considérer comme compromis les ordinateurs ayant installé ou ouvert ce paquet. L'exécution dépend de la commande : un simple composer install ne lance pas le voleur, alors que npm install dans le répertoire vendor du paquet le fait. Les utilisateurs devraient bloquer v3.14.3 et figer la version à v3.14.2 ou antérieure.

Pour github.com/onuragtas/docker-env, les versions v1.0.278 et v1.0.280 ne contiennent la charge utile que dans un workflow GitHub Actions. Ni le code Go ni les binaires de publication n'ont changé, et les builds Go n'exécutent pas les fichiers de workflow : les utilisateurs du module ont donc peut-être échappé à l'exposition. Aikido recommande néanmoins de retirer les deux versions.

Les chercheurs ont également repéré un workflow malveillant dans la pseudo-version v0.0.0-20261111095532-8d5aad0cb0da de github.com/vkuznet/gocurl. Ce workflow ne s'est jamais exécuté ; les utilisateurs devraient bloquer la pseudo-version.

Les commits attribués à wdio-bot ont introduit le voleur dans 28 dépôts WebdriverIO. Les publications de paquets n'ont pas été touchées, mais le jeton du bot doit être considéré comme volé.

Repérer les modifications, puis révoquer les accès

Les propriétaires de dépôts devraient examiner l'activité à partir du 10 novembre dans chaque dépôt sur lequel ils disposent d'un accès en écriture. En général, l'attaquant annulait les modifications malveillantes en quelques minutes, effaçait les journaux d'exécution et supprimait généralement aussi l'exécution du workflow. Un fichier actuel propre ne permet donc pas de savoir si des identifiants ont été exposés.

Recherchez les branches nommées wfx-docs, les branches éphémères correspondant à chore/[a-z0-9]{8} et celles correspondant à ci-check-[0-9]{4}. En plus du titre de pull request docs: dependency audit notes, ces messages de commit permettent d'identifier les modifications pertinentes :

  • ci: refresh build cache : environ 1 500 lignes insérées dans un workflow existant.
  • chore: add ci helper : un script .ci-xxxxxx.sh associé à un hook postinstall dans package.json, déclenché par tout npm install.
  • chore: add dependency audit workflow : un nouveau fichier .github/workflows/build-audit-xxxxxx.yml sur une branche chore/.
  • chore: initial commit : un commit précédant l'ajout d'un fichier de workflow dans un dépôt vide.
  • ci: restore et ci: cleanup.

L'empreinte SHA-256 du script voleur est 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf. Les indicateurs réseau sont 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil et 153.75.82[.]159:8080.

L'absence d'artefacts wfx-loot, d'entrées de cache wfx- ou de résumés d'étapes WFX-BEGIN n'exclut pas un vol. Les chercheurs considèrent comme un indice d'exécution plus fiable l'écart dans la numérotation des exécutions sur le commit de l'attaquant.

Les administrateurs cloud doivent aussi rechercher les mécanismes de persistance identifiés par les chercheurs :

  • Entra ID : identifiants fédérés inconnus nommés wfx-ci-*.
  • AWS CloudTrail : sessions AssumeRoleWithWebIdentity ou AssumeRole nommées wfx-*, suivies d'appels CreateAccessKey ou UpdateAssumeRolePolicy.
  • GCP : appels GenerateAccessToken et SignJwt provenant du pool d'identités de charge de travail GitHub, qui fournit les identités des workflows pour l'accès au cloud.
  • Vault : connexions par JSON Web Token (JWT) utilisant l'émetteur OIDC de GitHub.

SafeDep conseille aux propriétaires des dépôts touchés de révoquer les jetons de l'auteur du commit, les autorisations d'application OAuth, les clés SSH et les sessions, d'activer l'authentification à deux facteurs et de faire tourner chaque secret et variable lisible par le dépôt. Les développeurs ayant exécuté npm install sur un commit affecté doivent considérer leur ordinateur comme compromis et renouveler ses clés.

À lire aussi

Sources

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →