La semaine dernière, GitHub a lancé la révocation d'identifiants en libre-service pour Enterprise. Cette fonctionnalité permet aux propriétaires d'organisations de désactiver les identifiants compromis à l'échelle de toute l'organisation en une seule action, au lieu d'avoir à rechercher des jetons individuels lors d'un incident actif.
Cette correction était attendue depuis longtemps, car les derniers mois ont montré ce qui se passe lorsque la révocation est lente ou incomplète. La compromission de Trivy en mars a connu un second épisode, car le premier nettoyage avait laissé au moins un identifiant actif, et cette cascade a atteint Checkmarx quelques jours plus tard. En juin, les propres dépôts durabletask de Microsoft ont été touchés via un compte qui n'avait jamais été entièrement nettoyé après une attaque antérieure.
Microsoft a été très actif récemment en matière de correctifs de sécurité. Ils nous ont offert des délais de publication après les changements de compte quelques jours seulement avant cela, et plus tôt en juin, ils ont également mis à jour npm pour arrêter les scripts post-installation automatiques. Nous surveillerons ce qu'ils déploient d'autre et comment cela impacte les attaques sur les logiciels open source.
Ce que GitHub a déployé
Les propriétaires d'entreprise disposant de la permission « Gérer les identifiants d'entreprise » peuvent désormais révoquer ou supprimer en masse les identifiants de tous les utilisateurs de l'organisation, ou cibler un compte spécifique. Cela couvre les autorisations SSO pour les Personal Access Tokens (PATs), les clés SSH et les jetons OAuth. Une option de suppression totale est disponible pour les organisations Enterprise Managed Users (EMU), et les API REST au niveau de l'organisation gèrent une révocation plus granulaire par organisation. Chaque action crée une entrée de journal d'audit et envoie des notifications par e-mail aux utilisateurs concernés.
Les membres individuels disposent d'une nouvelle vue Paramètres > Identifiants affichant tous les identifiants liés à leur compte, qu'ils soient autorisés par SSO ou personnels. À partir de là, une seule action supprime l'accès de tous ces identifiants aux ressources d'entreprise protégées par SSO en une seule étape, éliminant le processus fastidieux de parcourir une liste de jetons entrée par entrée. Les membres des organisations EMU bénéficient également d'une option distincte pour supprimer définitivement tous leurs jetons et clés SSH.
Avant cette fonctionnalité de révocation d'urgence, il fallait utiliser plusieurs outils différents pour désactiver les identifiants d'un compte. Les PATs à grain fin pouvaient être révoqués depuis l'écran des jetons de l'organisation. Les jetons classiques ne pouvaient être désactivés que par la révocation d'autorisation SSO par jeton, et uniquement si le SAML SSO était activé. L'API de révocation d'identifiants pouvait tuer un jeton, mais seulement si vous aviez déjà la chaîne du jeton en main, ce qui fonctionne dans le cas d'un secret divulgué, mais pas dans celui d'un compte compromis (cela ne fait qu'effleurer les complexités, mais nous nous arrêterons là). En bref, cela rendait la coordination des changements d'identifiants assez désordonnée.
NB : Les jetons GitHub Actions ne sont pas concernés ici, car ils sont générés par tâche et expirent à la fin de celle-ci, il n'y a donc rien à révoquer. La manière de limiter les dégâts lors d'un incident est de désactiver les Actions sur le dépôt.
Pourquoi maintenant ?
De récentes attaques de malwares ont touché Microsoft de près.
Le 19 mai, des attaquants ont utilisé des identifiants précédemment volés pour pousser trois versions malveillantes de Microsoft durabletask package vers PyPI, dans le cadre de la campagne du ver Miasma. Microsoft a retiré les packages en quelques heures. Cependant, le 5 juin, le même compte a poussé un commit malveillant vers le dépôt GitHub `Azure/durabletask`, réintroduisant le ver. GitHub a réagi en désactivant 73 dépôts au sein de quatre organisations GitHub de Microsoft. Cela incluait les outils Azure Functions que de nombreuses équipes utilisent pour leurs déploiements, interrompant ainsi les pipelines CI/CD au-delà de Microsoft. Les chercheurs listent plusieurs explications possibles pour cette récidive, mais la principale est que les identifiants de mai n'ont jamais été entièrement révoqués. Une entreprise de surveillance a ensuite retrouvé les identifiants GitHub du compte dans des journaux d'infostealers datant d'avril. Quel que soit le mécanisme exact, le même compte a été utilisé dans les deux compromissions.
Mais ce n'est pas nouveau, et le problème est déjà apparu plusieurs fois cette année. Fin février 2026, un bot IA malveillant a exploité un pull_request_target workflow GitHub Actions mal configuré dans le dépôt de Trivy, ce qui a permis à l'attaquant de voler un PAT (Personal Access Token) avec des droits d'écriture sur plus de 33 workflows au sein de l'organisation GitHub d'Aqua Security. Aqua Security a découvert la brèche et a révoqué les identifiants. Mais hélas, la révocation n'était pas complète, et tous les identifiants n'ont pas été révoqués simultanément.
Le 19 mars, les attaquants ont utilisé des identifiants qui avaient survécu à la révocation incomplète pour forcer le push de 75 des 76 tags de version dans aquasecurity/trivy-action vers des commits malveillants. La charge utile s'est exécutée avant le véritable scan Trivy dans chaque pipeline, de sorte que chaque workflow semblait se terminer normalement. Les pipelines CI/CD exécutant Trivy collectaient des identifiants depuis leurs propres runners, tels que des clés SSH, des identifiants cloud, des jetons Kubernetes et des PAT GitHub.
Quatre jours plus tard, des identifiants volés depuis ces pipelines ont été utilisés pour empoisonner les GitHub Actions de Checkmarx avec une charge utile de vol identique. Checkmarx a confirmé que l'activité de l'acteur de la menace a persisté dans leur environnement jusqu'au 22 avril, avec leurs données exfiltrées publiées sur le dark web le 25 avril.
Toute cette chaîne d'attaques, de Trivy à Checkmarx, remonte à une révocation incomplète. Si Aqua Security avait pu couper instantanément tous les identifiants du compte de service compromis après la brèche de février, l'attaque se serait arrêtée là.
Qu'est-ce que la révocation atomique ?
La révocation atomique consiste à échanger un identifiant en une seule opération tout-ou-rien, de sorte qu'il n'y ait aucun moment où les anciens et les nouveaux identifiants fonctionnent simultanément. L'objectif est d'éviter toute interruption de service dans le système. C'est intéressant en théorie. Dans un système distribué, ce n'est tout simplement pas ainsi que cela fonctionne. Il y a beaucoup trop de coordination impliquée. À l'échelle d'une organisation comme GitHub, la révocation atomique n'a pas de sens.
Ainsi, une révocation réelle emprunte l'une des deux voies, toutes deux imparfaites. La révocation de routine maintient les deux identifiants valides pendant une certaine période afin de ne rien casser, ce qui est acceptable quand tout va bien mais laisse l'ancien identifiant actif. La réponse aux incidents fait l'inverse : elle coupe instantanément l'ancien identifiant et accepte que des problèmes surviennent jusqu'à ce qu'un nouveau soit émis.
Un bouton "break-glass" (accès d'urgence) permet de faire la seule chose qui soit réellement atomique : tuer tous les identifiants concernés en une seule fois. Certes, cela interrompt la CI/CD. Mais expulser un attaquant de votre infrastructure est bien plus important, et cela vaut quelques heures ou jours de builds cassées.
Jusqu'à présent, couper tous les identifiants en une seule fois était difficile à exécuter. Cette nouvelle coupure en une seule action la rend exécutable sous pression, et bien que la révocation atomique complète reste assez insaisissable, cela nous rapproche du monde idéal.
Que faire
Dans votre organisation GitHub, assurez-vous que la permission "Manage enterprise credentials" est attribuée à quelqu'un qui peut agir immédiatement, et faites-le avant qu'un incident ne survienne. Examinez les Paramètres > Identifiants dès maintenant pour comprendre ce qui est concerné.
De plus, pendant que vous mettez à jour vos paramètres de sécurité, épinglez vos GitHub Actions à des SHAs de commit complets plutôt qu'à des tags de version. Les tags peuvent être forcés pour pointer vers un code entièrement différent, ce qui est la technique principale derrière la compromission de Trivy. Un SHA de commit épinglé ne peut pas être déplacé.
Aikido Security surveille vos applications à la recherche de packages compromis en temps réel. Lorsque quelque chose dans votre pipeline est empoisonné, vous recevez une alerte avant que le collecteur d'identifiants ne s'exécute. Ceci est alimenté par Aikido Intel, qui analyse les nouvelles versions de packages dès qu'elles sont disponibles.
Merci pour toutes ces mises à jour, Microsoft. Continuez à nous les fournir, s'il vous plaît. 🙏
