Un identifiant gouvernemental supprimé d’une branche GitHub est resté récupérable publiquement pendant 18 mois — et fonctionnait toujours.
Cette exposition figurait parmi les conclusions mises en avant dans un rapport de WIRED du 10 novembre consacré à l’examen, par Chris Nesbitt-Smith, chercheur chez ControlPlane, du code du secteur public britannique. Il a signalé plus de 100 vulnérabilités graves après avoir analysé 349 bases de code réparties entre 33 organisations, des faiblesses ayant été relevées dans environ deux tiers des bases examinées.
Pour les équipes de sécurité, les divulgations publiées fournissent des enseignements précis sur la révocation des secrets exposés, la limitation des autorisations des applications et la vérification des personnes autorisées à modifier un enregistrement. Les conclusions décrivent l’échantillon étudié par le chercheur, et non un taux de vulnérabilité applicable à l’ensemble du gouvernement. Les problèmes mis en évidence ont depuis été corrigés.
Un fichier supprimé a laissé un identifiant actif
Dans sa révélation concernant le Planning Inspectorate, ControlPlane indique qu’un notebook Azure Synapse exporté contenait un identifiant complet d’application Microsoft Entra ID. L’intégration devait récupérer un fichier RH depuis SharePoint, mais ses autorisations s’étendaient à tous les sites SharePoint du locataire ainsi qu’aux comptes OneDrive des employés.
La suppression du fichier de la branche n’a pas invalidé l’identifiant. Selon les chercheurs, un commit orphelin est resté accessible via l’infrastructure de contenu brut de GitHub.
ControlPlane indique avoir vérifié l’accès au moyen de métadonnées et d’un contrôle d’autorisation d’écriture conçu pour échouer sans modifier les données. L’agence a révoqué le secret environ 20 minutes après avoir reçu le signalement, le 26 août.
Le Planning Inspectorate a déclaré à WIRED que sa surveillance avait déjà détecté l’activité du chercheur et qu’il avait vérifié qu’aucune fuite de données ne s’était produite. Il convient donc de distinguer un accès potentiel d’un vol confirmé.
Cette affaire réunit trois défaillances : la publication d’un secret, l’octroi à une intégration de droits plus étendus que nécessaire et le maintien de ces droits après le nettoyage du dépôt. Des risques similaires sont apparus dans une étude sur les entreprises d’IA qui divulguent des secrets sur GitHub, notamment des identifiants dissimulés dans des forks supprimés et des dépôts de développeurs.
D’autres divulgations révèlent des défaillances différentes du contrôle d’accès
Les cas publiés ne se limitent pas aux identifiants présents dans les dépôts. Les rapports de ControlPlane décrivent des faiblesses dans du code exécuté dans le navigateur, des formulaires de commande et l’association de comptes :
| Service | Constat de ControlPlane | Résolution signalée |
| Portail de données ouvertes du gouvernement écossais | Un jeton d’administrateur à longue durée de vie intégré au code JavaScript public pouvait exposer les informations des comptes administrateurs et permettre de modifier la configuration. | Le propriétaire a définitivement désactivé le service après avoir déterminé qu’il n’était plus nécessaire. |
| Service Get Help Buying for Schools du Department for Education | Toute personne disposant d’un identifiant de requête valide pouvait modifier les détails d’une demande, notamment l’adresse e-mail de contact, et envoyer la demande sans se connecter. | L’accès aux enregistrements et les actions associées étaient liés à la session active. |
| Service de candidature des enseignants du Department for Education | Le code d’association de comptes pouvait écraser une association de connexion existante sans rejeter une identité en conflit. | Un contrôle a été ajouté afin de rejeter les associations en conflit. |
Ces conclusions et leurs résolutions sont documentées dans les divulgations individuelles de ControlPlane.
La révélation concernant le portail écossais montre pourquoi une variable d’environnement définie lors de la compilation ne suffit pas à préserver la confidentialité d’un secret lorsque sa valeur est compilée dans du JavaScript envoyé aux navigateurs. Un identifiant administrateur transmis de cette manière devient accessible aux visiteurs.
Cette exposition s’apparente au problème plus général des secrets codés en dur dans les applications Android téléchargeables : les éléments distribués aux utilisateurs peuvent eux aussi être inspectés par des attaquants.
Le constat concernant les achats scolaires relevait d’une erreur différente. Un identifiant de requête long et aléatoire servait de fait d’autorisation pour modifier l’enregistrement. Selon ControlPlane, le ministère a corrigé le problème le 10 juillet.
Le rapport sur l’association des comptes des enseignants comporte une limite importante. Le test a associé une nouvelle connexion au propre compte des chercheurs ; il n’a pas démontré l’existence d’une méthode distincte de prise de contrôle de compte ni remplacé la connexion d’un autre candidat. La divulgation décrit un risque identifié dans le code et une correction ultérieure.
Ce que les équipes de sécurité doivent vérifier dès maintenant
La réponse immédiate à un identifiant exposé doit être apportée auprès du service qui l’a délivré. Les recommandations de remédiation de GitHub placent la révocation ou la rotation en première étape, avant toute décision de réécrire l’historique du dépôt.
Les équipes de sécurité et d’ingénierie doivent s’appuyer sur ces divulgations pour vérifier quatre domaines :
- Validité des identifiants : confirmer que chaque mot de passe, jeton ou secret d’application précédemment exposé a été révoqué ou renouvelé. Une alerte de dépôt clôturée ou un fichier supprimé ne prouve pas que l’accès a pris fin.
- Autorisations des applications : comparer les accès de chaque intégration avec sa tâche réelle. Un workflow qui lit un seul fichier RH doit faire l’objet d’un examen approfondi s’il peut écrire sur des sites sans rapport et dans le stockage des employés.
- Artefacts de compilation publics : inspecter le JavaScript de production, les notebooks exportés et les paquets téléchargeables à la recherche de secrets intégrés. Inclure les artefacts de publication dans les contrôles du code source.
- Propriété des enregistrements : vérifier si la modification d’un identifiant de requête permet à une session de lire ou de modifier l’enregistrement d’une autre session. Examiner explicitement les workflows invités et les conflits d’association de comptes.
Donnez la priorité aux identifiants qui restent valides et peuvent atteindre des systèmes sensibles, puis recherchez leur utilisation dans les journaux d’audit d’identité et de service disponibles. Consignez toute lacune dans la couverture historique des journaux afin que l’évaluation de l’incident reflète ce qui peut réellement être établi.
La faille de Google DevSite impliquant un secret d’authentification exposé montre comment un secret divulgué peut se combiner à une autre faiblesse pour créer une voie d’attaque plus dommageable. La remédiation doit donc couvrir à la fois l’identifiant et le comportement de l’application qui lui accordait sa confiance.
Lors du prochain examen, demandez aux équipes de démontrer qu’un ancien identifiant exposé échoue, qu’une intégration ne peut pas accéder à des ressources sans rapport et qu’un enregistrement rejette les demandes provenant d’une session non autorisée. Ces vérifications attestent que l’accès sous-jacent a bien été modifié.
Pour en savoir plus : les secrets exposés et les contrôles d’accès faibles ont également figuré dans une opération visant des services publics. Découvrez comment un hacker a utilisé 12 agents IA pour cibler les services d’urgence de Taïwan et ce que les défenseurs peuvent tirer de ces conclusions.