13 000 captures d'écran internes se sont retrouvées sur GitHub public, et aucun attaquant ne les y a mises

Des chercheurs en sécurité ont découvert plus de 13 000 captures d'écran internes provenant de plus de 300 organisations, exposées dans des dépôts GitHub publics. Les captures n'ont pas été volées. Elles ont été publiées par les agents de codage que les organisations utilisaient, dans le cadre d'un travail ordinaire.

La découverte, rapportée par la société de sécurité Glow, est l'une des fuites les plus instructives depuis un moment, car les hypothèses habituelles ne s'appliquent pas. Il n'y a eu ni violation, ni identifiant compromis, ni initié malveillant. Un outil automatisé a fait ce qu'on lui avait dit, et ce qu'on lui avait dit incluait de committer des fichiers qui n'auraient jamais dû quitter l'entreprise.

Comment une capture d'écran finit dans un dépôt public

Les agents de codage prennent des captures d'écran pour des raisons sensées. Lorsqu'on demande à un agent de vérifier qu'une modification d'interface utilisateur a fonctionné, il ouvre un navigateur, charge la page, capture une image et la compare au résultat attendu. Cette image est une preuve. De nombreux agents l'enregistrent dans le répertoire de travail afin que l'étape puisse être examinée plus tard.

À partir de là, le chemin vers un dépôt public est court. Si le répertoire de travail de l'agent est le dossier du projet, et que le dossier du projet est un dépôt git, alors une capture d'écran écrite sur le disque n'est qu'à un `git add` d'être committée. Si l'agent committe et pousse dans le cadre de son flux de travail normal, et que rien ne filtre les nouveaux fichiers, la capture d'écran part vers le remote vers lequel le dépôt pointe.

Répétez maintenant cela sur des milliers d'exécutions, dans des centaines d'organisations, pendant des mois. Personne n'a décidé de publier des captures d'écran internes. Le comportement par défaut de l'outillage l'a fait, et aucune étape de la chaîne ne vérifiait.

Pourquoi ce n'est pas une petite erreur

Une capture d'écran interne est souvent plus révélatrice qu'on ne l'imagine. Elle peut montrer un tableau de bord avec des noms de clients, un panneau d'administration avec des tarifs, un environnement de staging, un outil de suivi de bugs, ou une fenêtre de chat dans un coin de l'écran. Elle peut montrer l'état d'un produit qui n'a pas encore été lancé. Au total, 13 000 images provenant de 300 organisations constituent une carte de ce sur quoi ces entreprises travaillaient.

Les images persistent également. Un commit poussé vers un dépôt public reste dans l'historique même après la suppression du fichier de la version courante, à moins que l'historique ne soit réécrit. L'exposition n'est donc pas corrigée par un commit de nettoyage ultérieur, qui est l'étape vers laquelle la plupart des équipes se tourneraient en premier.

Pourquoi les agents aggravent la situation

Un développeur humain qui prend une capture d'écran pour une pull request la regarde généralement avant de la joindre. L'image est juste là, et la personne décide si elle peut être partagée sans risque. Ce moment de jugement constitue le filtre, et il fonctionne la plupart du temps.

Un agent n'a pas un tel moment. Il optimise l'accomplissement de la tâche, et enregistrer un artefact fait partie de l'accomplissement de la tâche. Rien dans la boucle ne demande si l'artefact est sensible, car rien dans la boucle n'est équipé pour le savoir. L'agent ne fait pas preuve de négligence au sens humain. Il fait exactement ce que les instructions disaient.

C'est la même leçon qui apparaît dans plusieurs domaines de la conception d'agents. Des autorisations qui convenaient à une personne tapant des commandes ne conviennent pas à un système qui agit à la vitesse d'une machine et ne se fatigue jamais. Un humain qui committe une capture d'écran une fois par semaine, c'est un impair. Un agent qui le fait à chaque exécution sur toute une flotte, c'est le résultat d'une politique.

À quoi ressemble la solution

Les contrôles qui auraient empêché cela ne sont pas exotiques. Une entrée `.gitignore` pour les répertoires de captures d'écran est la plus simple, et elle ne fonctionne que si quelqu'un l'écrit avant que l'agent ne s'exécute. Un hook pre-commit qui recherche les fichiers image dans certains chemins intercepte ce que le fichier d'ignore laisse passer. Donner aux agents un répertoire de travail temporaire en dehors du dépôt pour les artefacts temporaires élimine le problème à la source.

Aucun de ces éléments ne dépend de la détection du caractère sensible d'une image. Ils dépendent de la décision, prise à l'avance, de l'endroit où la sortie de l'agent est autorisée à aller. C'est une décision de conception, et elle doit être prise par l'équipe qui exploite les agents, car l'agent ne peut pas la prendre.

Pourquoi les chiffres continuent d'augmenter

Le décompte de 13 000 images provenant de 300 organisations n'est pas un chiffre fixe. C'est un instantané des dépôts qui étaient publics au moment de l'analyse, et le nombre augmentera à mesure que davantage d'équipes adoptent des agents et que davantage de dépôts sont poussés. Les chercheurs ont analysé des dépôts publics, ce qui signifie que le total réel, y compris les dépôts privés où la même erreur s'est produite, est inconnaissable de l'extérieur.

Les organisations touchées ne sont pas toutes petites. La découverte en nomme plus de 300, ce qui couvre des startups et des entreprises plus grandes utilisant le même outillage d'agents. C'est la nature d'un problème de comportement par défaut : il ne respecte pas la taille de l'entreprise, car chaque entreprise utilisant l'outil hérite du même défaut.

Ce que le rapport ne dit pas

La découverte n'affirme pas que l'une des images exposées ait été utilisée de manière malveillante, et rien ne prouve que quiconque extérieur aux projets les ait passées au peigne fin. Le préjudice est potentiel plutôt que prouvé : le matériel était public, et n'importe qui aurait pu le consulter. Là où un préjudice a été démontré dans des cas similaires, comme des identifiants écrits dans un fichier public, le dommage est immédiat.

Elle ne nous dit pas non plus combien d'images étaient sensibles d'une manière significative. Certaines sont presque certainement des captures d'écran d'une page de test vide. Mais une fuite se juge à son pire élément, pas à la moyenne, et 13 000 images réparties sur 300 organisations signifient que le pire élément est probablement réellement révélateur.

Le schéma sous-jacent

La découverte de Glow fait partie d'un ensemble de rapports similaires. Des chercheurs ont montré que les agents de codage référencent des paquets logiciels qui n'existent pas, ce que des attaquants peuvent exploiter en enregistrant ces noms. D'autres ont constaté que des agents écrivaient des identifiants ou des jetons à des endroits où ils ne devraient pas. Le fil conducteur est que les agents produisent des artefacts comme effet secondaire de leur travail, et chaque artefact est une fuite potentielle.

La lecture rassurante est que cela est réparable et se résume largement à de l'hygiène. La lecture moins rassurante est que l'industrie déploie des agents plus vite qu'elle ne construit les garde-fous autour de leur sortie. Une entreprise qui audite ce que ses agents lisent n'audite souvent pas ce qu'ils écrivent.

Que faire cette semaine

Si une équipe exécute des agents de codage sur des dépôts, les vérifications immédiates valent la peine. Regardez si le répertoire de travail de l'agent se trouve à l'intérieur du dépôt, si des captures d'écran ou des journaux y atterrissent, et si l'étape de commit filtre quoi que ce soit. Vérifiez l'historique du dépôt ainsi que l'arborescence actuelle pour les fichiers image qui ne devraient pas être publics. Et donnez aux agents un chemin de travail temporaire en dehors de l'arborescence pour tout ce qui est temporaire.

Rien de tout cela ne nécessite de nouvel outillage. Cela nécessite de décider que la sortie de l'agent, comme l'entrée de l'agent, est quelque chose qu'une équipe contrôle volontairement plutôt que par accident.