Problème 6115

En août 2024, nous avons découvert une publication LinkedIn [https://www.linkedin.com/posts/zak-horton_github-ai-privacy-activity-7225764812117487616-YcGP] affirmant qu'OpenAI s'entraînait sur des données provenant de dépôts GitHub privés et les exposait. Face à la gravité de cette affirmation, notre équipe de recherche a immédiatement mené l'enquête.

Une recherche rapide a révélé que le dépôt en question avait été public, ses pages étant toujours indexées par Bing. Cependant, lorsque nous avons tenté d'accéder à ces pages directement sur GitHub, une erreur 404 s'est produite, confirmant que le dépôt était désormais privé.

Cela a soulevé une question importante : comment ChatGPT a-t-il pu renvoyer des réponses basées sur le contenu d'un référentiel qui n'était plus accessible au public ?

Pages indexées du référentiel dans Bing

‍

‍

Page indexée inexistante‍

Pour en savoir plus, nous avons interrogé ChatGPT à plusieurs reprises pour obtenir des données relatives à ce référentiel. À chaque fois, le service a précisé qu'il n'avait pas d'accès direct aux données réelles et qu'il générait du contenu hypothétique basé sur le nom du référentiel. Nous avons appris que ChatGPT utilise Bing comme moteur de recherche lors de sa publication publique. Ce mécanisme explique comment il est possible de récupérer des informations d'un référentiel autrefois public, puis rendu privé : les données avaient été indexées pendant sa phase publique et étaient conservées dans le cache de Bing.

Mais deux questions subsistaient : qu'est-il advenu du contenu du dépôt une fois celui-ci rendu privé ? Et quelles autres conversations pourraient suivre le même comportement ?

Découvrir notre propre dépôt exposé

Nous avons décidé d'approfondir la question et de déterminer si l'un de nos dépôts organisationnels avait pu être exposé. Une recherche Bing des dépôts de l'organisation Lasso a révélé que l'un de nos propres dépôts était indexé. Cependant, comme le dépôt était devenu privé, y accéder sur GitHub renvoyait une erreur 404.

Une analyse interne a confirmé qu'il avait été rendu public par erreur pendant une brève période avant d'être à nouveau rendu privé.

‍

Notre dépôt privé est inaccessible sans autorisation‍

Intrigués par les conséquences potentielles, nous avons testé ChatGPT pour voir s'il pouvait extraire des données des pages indexées.

Bien qu'il ait parfois reconnu l'existence du dépôt (grâce à l'indexation de Bing), il n'a fourni aucune donnée concrète.

*ChatGPT a confirmé l'existence d'un dépôt appelé « lassollm » sur le GitHub lasso-security. organisation.*‍

ChatGPT renvoie le dépôt lassollm comme inaccessible.

‍

Une possibilité inquiétante nous est alors venue à l'esprit : si Bing l'avait indexé, les données auraient pu être mises en cache quelque part, et qui serait mieux placé que Microsoft Copilot pour y accéder ? Après tout, tout reste dans la famille.

Nos soupçons ont été confirmés lorsque Copilot a renvoyé des données réelles datant de l'époque où le dépôt était public, récupérant apparemment un instantané en cache de « données zombies » – des données que l'utilisateur pense privées ou supprimées, mais qui restent accessibles. ‍

Notre dépôt privé est accessible à toute personne disposant d'un accès à Copilot. ‍

Cette découverte a mis en évidence un problème de sécurité majeur :

• « Données zombies » : Toute information ayant été rendue publique, même pendant une courte période, pourrait rester accessible et distribuée par Microsoft Copilot.
• Risques liés au code privé : Cette vulnérabilité est particulièrement dangereuse pour les dépôts publiés par erreur comme publics avant d'être sécurisés, en raison de la nature sensible des données qui y sont stockées. ‍

Flux Wayback Copilot

‍

Le mécanisme de mise en cache de Bing

‍

En examinant de plus près le système d'indexation de Bing, nous avons découvert cc.bingj.com, un domaine appartenant à Microsoft qui stocke les versions en cache des pages indexées. Bing affiche une petite flèche à côté des résultats de recherche, permettant aux utilisateurs de consulter les versions en cache des pages même si elles ne sont plus accessibles. ‍

La page Azure/responsible-ai-hub d'origine n'existe pas

‍

‍Le bouton vers le lien mis en cache dans Bing

‍

‍

‍

‍

Contenu de la page en cache d'Azure/responsible-ai-hub ‍

Augmentation de la capacité

‍

Après avoir réalisé que toutes les données sur GitHub, même publiques pour un court instant, peuvent être indexées et potentiellement exposées par des outils comme Copilot, nous avons été frappés par la facilité d'accès à ces informations. Déterminés à comprendre l'ampleur du problème, nous avons entrepris d'automatiser le processus d'identification des « dépôts zombies » (dépôts autrefois publics et désormais privés) et de valider nos résultats.

‍

Collecte de données et flux de recherche ‍

‍

Étape 1 : Collecte des dépôts publics

‍

Nous avons utilisé le jeu de données « githubarchive » de Google BigQuery, qui enregistre toutes les activités des dépôts publics. Nous avons extrait la liste des dépôts publics à tout moment en 2024 et appartenant à une organisation GitHub :

‍

‍

Étape 2 : Identification des dépôts manquants

‍

Nous avons ensuite vérifié l'état de chaque dépôt en essayant d'y accéder sur GitHub.

• Si la requête renvoyait « 200 OK », le dépôt était toujours public.
• Si elle renvoyait « 404 », le dépôt avait été supprimé ou défini comme privé.

‍

Étape 3 : Extraction des données en cache de Bing

‍

Pour chaque dépôt devenu public, nous avons effectué une recherche dans Bing à l'aide de :

‍

‍

et extrait toutes les pages en cache trouvées.

‍

Étape 4 : Analyse du contenu

À l'aide d'outils internes, nous avons analysé les données extraites à la recherche de secrets, de jetons, de clés d'accès et de packages non accessibles au public (risquant de créer une confusion de dépendances).

‍

‍

Résultats de l'étude

• 20 580 dépôts GitHub ont été extraits au cours de l'étude grâce au mécanisme de mise en cache de Bing.
• 16 290 organisations ont été affectées par Wayback Copilot, dont Microsoft, Google, Intel, Huawei, PayPal, IBM, Tencent et bien d'autres.
• Plus de 100 packages internes Python et Node.js potentiellement vulnérables à la confusion des dépendances ont été découverts.
• Plus de 300 jetons, clés et secrets privés de GitHub, Hugging Face, GCP, OpenAI, etc. ont été découverts. Dévoilé

‍

‍

‍

‍

Utilisation malveillante du mécanisme Wayback Copilot

‍

‍

Signaler Correction

‍

Nous avons informé Microsoft de nos conclusions, soulignant que les dépôts GitHub supprimés ou privés étaient toujours accessibles via le cache de Bing et Copilot, et que cette fonctionnalité présentait un risque de sécurité en exposant les données organisationnelles. Nous avons également alerté toutes les organisations concernées et leur avons conseillé de procéder à la rotation ou à la révocation de toute clé compromise.

Microsoft a classé le problème comme étant de faible gravité, invoquant un « faible impact » et affirmant que ce comportement de mise en cache était acceptable. Néanmoins, Microsoft a réagi rapidement et, en deux semaines, la fonctionnalité de mise en cache des liens de Bing a été supprimée et l'accès au domaine « cc.bingj.com » a été désactivé pour tous les utilisateurs.

‍

Retour au point de départ

Bien que la fonctionnalité de mise en cache des liens de Bing ait été désactivée, les pages en cache ont continué d'apparaître dans les résultats de recherche. Cela indiquait que le correctif n'était que temporaire : si l'accès public était bloqué, les données sous-jacentes n'avaient pas été entièrement supprimées.

Lorsque nous avons réexaminé notre enquête sur Microsoft Copilot, nos soupçons se sont confirmés : Copilot avait toujours accès aux données mises en cache, qui n'étaient plus accessibles aux utilisateurs humains. En bref, la correction n'était que partielle : les utilisateurs humains ne pouvaient pas récupérer les données mises en cache, mais Copilot pouvait toujours y accéder.

‍

Utilisation malveillante de Wayback Copilot

‍

Le 14 janvier 2025 (après la correction Microsoft), nous avons eu une nouvelle occasion de tester Wayback Copilot. Dans un article sur Techcrunch, nous avons appris que « Microsoft a engagé des poursuites judiciaires contre un groupe qui, selon l'entreprise, aurait intentionnellement développé et utilisé des outils pour contourner les protections de sécurité de ses produits d'IA cloud ». Il a été mentionné que le dépôt de l'outil avait été supprimé de GitHub. Intrigués par le contenu de ces dépôts, nous avons décidé d'en discuter avec notre ami. Bien que les dépôts aient été supprimés (la fameuse erreur 404 de GitHub), nous avons pu récupérer le contenu du paquet malveillant.

‍

Liste des fichiers indexés des dépôts supprimés Dépôt

‍

‍

‍

‍

utils.py* page du dépôt n'est pas disponible Accessible*

‍

‍

Récupération* utils.py** du code du dépôt de3u à l'aide de Wayback Copilot*

‍

‍

‍

Points clés de notre recherche

Dans le paysage numérique actuel, les données demeurent une ressource précieuse, et l'essor des LLM et de l'IA générative a intensifié la course aux ensembles de données uniques. Cette pression pousse les organisations à adopter des stratégies d'acquisition de données plus risquées, allant jusqu'à recourir à des dark patterns, pour améliorer la qualité de la formation et la précision des réponses. Voici nos principales conclusions :

‍

1.  Considérer que toutes les données sont compromises une fois exposées

Les organisations modernes doivent partir du principe que toute donnée quittant leur réseau, même publique momentanément, est susceptible d'être ingérée par les moteurs LLM ou les principaux moteurs de recherche à des fins d'apprentissage ultérieur. Il est plus crucial que jamais de protéger et de nettoyer les flux de données sortants. Contrôlez chaque bit de données quittant votre périmètre.

‍‍

2. Les moteurs LLM : nouveaux vecteurs de menaces

‍La veille sur les menaces traditionnelle se concentrait sur l'analyse du web, des forums ou du dark web à la recherche de données divulguées. Aujourd'hui, les LLM et les copilotes d'IA introduisent un nouveau risque : une simple demande peut exposer des données sensibles à un large public. Cela représente un changement significatif dans la manière dont les violations de données peuvent se produire. ‍

3. Pièges liés aux autorisations et systèmes trop complaisants

‍Nos résultats révèlent deux défis bien connus des LLM et des systèmes de génération augmentée de données (RAG) : la gestion des autorisations et la volonté intrinsèque des systèmes d'aider. Combinés à certains choix de conception (Microsoft dans notre cas), ces problèmes peuvent entraîner un partage excessif d'informations sensibles. Lors du déploiement ou du développement de vos propres systèmes, assurez-vous que les utilisateurs n'accèdent qu'aux données qu'ils sont autorisés à consulter et que vous gardez une vue d'ensemble de ce qui est indexé et récupéré.

‍

4. Retour aux fondamentaux : Hygiène fondamentale des données

Malgré l'évolution du paysage, les fondamentaux de la cybersécurité restent inchangés. Vérifiez toujours la confidentialité de vos dépôts, évitez de publier des secrets ou des jetons sur des plateformes comme GitHub et atténuez les risques tels que la confusion des dépendances en utilisant des dépôts de paquets officiels (par exemple, PyPi, NPM) pour les paquets privés. En résumé, protégez vos informations privées et votre code en les conservant dans les limites de votre organisation. ‍

Si vous souhaitez savoir si votre organisation a été impactée, veuillez contacter research@lasso.security.