if ( !emtpy($headline_subheadline ) ) : ?>
GitGuardian a trouvé 474 clés privées de l’application GitHub encore valides parmi des milliers d’informations d’identification exposées, certaines comportant des autorisations de prise de contrôle de compte.
endif; ?>
GitHub permet aux organisations d’installer des applications GitHub qui automatisent et étendent certaines fonctionnalités de la plate-forme et ont accès aux référentiels et autorisations sélectionnés. Mais les clés privées que ces applications utilisent pour s’authentifier peuvent rester valides pendant des années à moins d’être révoquées manuellement.
En cas de fuite, ces clés peuvent potentiellement donner aux attaquants un contrôle administratif sur le compte GitHub d’une organisation, explique GitGuardian, qui a trouvé 474 clés privées de l’application GitHub encore valides parmi 4 802 clés exposées publiquement qu’il a collectées depuis 2019.
En testant la validité des clés, il a également pu déterminer les droits d’accès qu’elles fournissaient, constatant que « 72 % des applications compromises pouvaient lire le contenu du référentiel privé, et 207 pouvaient y écrire, transformant une clé divulguée en un rachat d’organisation », a déclaré Gaetan Ferry, chercheur chez GitGuardian, dans un article de blog.
Parmi les applications GitHub affectées par les clés divulguées figurait « Access Tokens for GitHub Actions », une application utilisée pour gérer l’accès aux flux de travail GitHub Actions. Sa clé privée a été exposée en janvier 2024 après avoir été accidentellement stockée dans un référentiel, affectant potentiellement 300 organisations où l’application était installée, dont Civica et Sierra Nevada Corp.
BuildBuddy, Crusher.dev et une application privée associée aux Centers for Disease Control and Prevention des États-Unis faisaient partie des autres applications GitHub pour lesquelles GitGuardian a trouvé des clés exposées.
Agnidipta Sarkar, évangéliste en chef chez ColorTokens, fournisseur de logiciels de sécurité, a déclaré que l’abus initial est « trivialement simple » et qu’un attaquant peut y parvenir avec une clé privée valide et l’ID d’application correspondant. Pour un impact maximal, a-t-il déclaré, les attaquants pourraient enchaîner les abus en « injectant du code malveillant dans le référentiel et lorsque le code est construit ou déployé, il peut compromettre les utilisateurs en aval ou les environnements de production ».
Un attaquant pourrait également être en mesure de modifier les configurations du programme d’exécution CI/CD pour exécuter du code arbitraire sur l’infrastructure réseau interne de l’organisation, a ajouté Sarkar.
GitGuardian a déclaré avoir informé tous les propriétaires d’applications concernés des clés exposées et a noté que son propre service d’analyse secrète utilise une application GitHub pour surveiller les référentiels à la recherche d’informations d’identification divulguées.
Les clés qui ont fui avaient un accès varié
Lorsqu’une organisation installe une application GitHub, elle décide à quels référentiels l’application peut accéder et ce qu’elle peut y faire. GitGuardian a découvert que 40 applications concernées pouvaient administrer des coureurs auto-hébergés, 98 pouvaient contrôler les flux de travail et 44 disposaient de privilèges d’administration d’organisation.
Pour les applications dotées de privilèges d’administration d’organisation, « un attaquant pourrait s’ajouter en tant que propriétaire, verrouiller les administrateurs légitimes et détourner complètement l’organisation GitHub », a déclaré Sarkar.
L’une des applications exposées comptait 303 installations, certaines n’en avaient aucune et 59 % d’entre elles n’avaient qu’une seule installation, ce qui indique un usage privé.
Commentant ces applications internes à installation unique, Ferry a déclaré : « Il s’agit d’automatisations internes, de robots CI et d’outils ponctuels qui peuvent facilement être oubliés, même s’ils ne sont plus utilisés. » De telles applications peuvent continuer à fonctionner et les clés peuvent continuer à fonctionner indéfiniment sans que personne ne s’en aperçoive.
GitGuardian a également trouvé 156 cas où la clé privée divulguée apparaissait dans un référentiel non lié, rendant les informations d’identification plus difficiles à associer à l’application GitHub qui en était propriétaire.
« Le rayon d’explosion ne s’arrête pas au propriétaire de l’application », a déclaré Ferry. « Cela s’étend à chaque organisation qui a installé l’application et, via les dépendances de la chaîne d’approvisionnement, à chaque utilisateur en aval du code touché par l’application. »
La rotation des clés est le seul moyen
Même si GitHub prévient dans sa documentation officielle que les clés privées n’expirent pas d’elles-mêmes et doivent être révoquées ou supprimées manuellement, les organisations peuvent ne pas le faire en raison d’hypothèses de sécurité incorrectes sur leur fonctionnement.
Les clés privées sont générées dans la configuration de l’application et sont utilisées pour signer un jeton Web JSON (JWT) de courte durée, que GitHub accepte et émet un jeton d’accès à l’installation. Le jeton d’installation contient les autorisations accordées à l’application lorsqu’une organisation l’a installée.
Le JWT expire en quelques minutes et les jetons d’installation ne sont valables qu’une heure, ce qui rend leur fenêtre d’abus très courte et donne l’impression que la perte de contrôle d’une clé présente un risque limité.
Cependant, toute personne détenant la clé privée peut générer d’innombrables JWT et s’authentifier en tant qu’application GitHub, ce qui permet à GitHub de générer de nouveaux jetons d’installation aussi longtemps que la clé privée reste valide.
« Il s’agit peut-être d’un compromis de conception intentionnel, pas d’un oubli », a déclaré Sarkar, commentant la mise en œuvre de jetons de courte durée aux côtés d’une clé permanente. « C’est ainsi que fonctionne traditionnellement l’authentification de machine à machine et cela évite les temps d’arrêt inattendus. » La conception « pour toujours » donne la priorité à la simplicité et à la continuité opérationnelles ; le fardeau de la sécurité lié à la rotation incombe entièrement aux propriétaires d’applications, a-t-il ajouté.
GitGuardian recommande de faire tourner ou de révoquer régulièrement les clés privées, car elles peuvent survivre à la fois aux personnes qui les ont créées et à la raison pour laquelle elles l’ont fait, a déclaré Ferry. « Une clé commise par erreur en 2020 peut encore s’authentifier aujourd’hui, longtemps après que l’erreur soit oubliée », estime-t-il.
Sarkar a déclaré que la révocation manuelle est cependant extrêmement rare et presque toujours réactive. « La plupart des manuels de gestion des services informatiques mentionnent sa nécessité, mais la démontrent rarement, sauf si un incident de sécurité, un audit ou un changement spécifique l’exige », explique-t-il.
InfoMonde
