Vue lecture

CamoLeak - Quand un simple commentaire GitHub transforme Copilot en espion

Y’a plein de problème avec les IA, mais y’en a un encore un peu trop sous-estimé par les vibe codeurs que vous êtes… Ce problème, c’est qu’on leur fait confiance comme à un collègue, on leur montre notre code, nos repos privés, nos petits secrets bien planqués dans les variables d’environnement…

Par exemple, quand vous passez en revue une pull request sur GitHub, vous faites quoi ? Vous lisez le code ligne par ligne, vous cherchez les bugs, les failles de sécu, les optimisations possibles. Mais les commentaires vous les lisez ? Au mieux on les survole, c’est vrai, car c’est de la comm’ entre devs, et pas du code exécutable.

Sauf pour bien sûr pour Copilot Chat pour qui un commentaire c’est un texte comme un autre. Et selon Omer Mayraz , chercheur en sécurité chez Legit Security, c’est exactement ce qui en fait une zone de confiance aveugle parfaite pour une attaque.

Ce qu’a découvert Omer Mayraz c’est donc une vulnérabilité critique dans GitHub Copilot Chat avec un score CVSS de 9.6 sur 10. Cela consiste à planquer des instructions malveillantes dans des commentaires markdown invisibles comme ça, ces commentaires ne s’affichent pas dans l’interface web de GitHub, mais Copilot Chat les voit parfaitement et les traite comme des prompts légitimes.

Du coup, l’attaquant peut forcer Copilot à chercher des secrets dans vos repos privés, à extraire du code source confidentiel, voire à dénicher des descriptions de vulnérabilités zero-day non publiées. Tout ça sans que vous ne voyiez rien venir évidemment !

Voici une démo complète de l’attaque en vidéo :

La première étape c’est donc l’injection de prompt via un commentaire caché. Rien de révolutionnaire, mais efficace. Ensuite, deuxième étape : le bypass de la Content Security Policy de GitHub. Normalement, Copilot Chat ne peut charger que des ressources depuis des domaines appartenant à GitHub. Il est donc impossible d’envoyer des données vers un serveur externe.

Mais c’était sans compter sur le fait que GitHub dispose d’un proxy appelé Camo, conçu à l’origine pour sécuriser l’affichage d’images externes en les servant via HTTPS et en évitant le tracking. C’est donc ce proxy de sécurité qui devient l’outil d’exfiltration. Avec ce proxy, toutes les URLs d’images externes sont automatiquement transformées en URLs Camo du type https://camo.githubusercontent.com/[hash unique] et Mayraz a simplement utilisé l’API GitHub pour pré-générer un dictionnaire complet de ces URLs Camo, chacune pointant vers un emplacement unique sur son serveur.

Troisième étape, l’exfiltration des données. Au lieu de faire passer les secrets directement dans les URLs (trop visible), Mayraz a eu l’idée d’utiliser l’ordre des requêtes. Chaque lettre de l’alphabet correspond à une URL Camo unique. En faisant charger ces URLs dans un ordre précis, on peut ainsi transmettre des données texte comme avec un alphabet ASCII artisanal. C’est plutôt créatif comme approche, je trouve.

C’est exactement le même principe que les attaques ultrasoniques contre Alexa ou Siri. Si vous ne vous en souvenez pas, des chercheurs avaient démontré qu’on pouvait envoyer des commandes vocales à des fréquences inaudibles pour l’oreille humaine, mais parfaitement comprises par les assistants vocaux.

Bah ici, c’est pareil… On a des prompts invisibles pour les humains mais que l’IA voit et exécute sans broncher. Comme pour les enceintes, on parle à la machine sans que l’humain ne s’en aperçoive et la différence, c’est qu’au lieu de jouer sur les fréquences sonores, on joue sur le markdown et les commentaires cachés.

Du coup, chaque pull request externe est un potentiel cheval de Troie. Un contributeur externe soumet par exemple une PR apparemment légitime, avec un commentaire invisible qui ordonne à Copilot de chercher “AWS_KEY” dans vos repos privés. Vous de votre côté, vous ouvrez la PR dans votre éditeur, Copilot Chat s’active bien sûr automatiquement, et hop, vos clés API partent chez l’attaquant.

Quand on sait que GitHub a créé Camo justement pour améliorer la sécurité, ça fout un peu les boules. Bref, grâce à son proof-of-concept, Mayraz a réussi à exfiltrer des clés AWS, des tokens de sécurité, et même la description complète d’une vulnérabilité zero-day stockée dans une issue privée d’une organisation et tout ça sans aucune interaction suspecte visible par la victime.

Heureusement, notre joyeux chercheur a prévenu GitHub qui a réagi assez vite. Le 14 août l’entreprise a complètement désactivé le rendu d’images dans Copilot Chat, comme ça plus d’images, plus de problème. C’est radical, c’est sûr mais c’est efficace !

Quoiqu’il en soit, ces histoires de prompt injection c’est un problème fondamental propre aux LLM qui sont encore actuellement incapable de distinguer de manière fiable les instructions légitimes des instructions malveillantes. Ça reste donc un problème de confiance…

Dans ce cas prévis, on fait confiance à GitHub pour héberger notre code du coup, on fait confiance à Copilot pour nous aider à développer, tout comme on fait confiance aux contributeurs externes pour soumettre des PR de bonne foi. Et nous voilà avec une jolie chaîne de confiance prête à être exploitée…

Bref, CamoLeak c’est que le début de cette nouvelle vague de vuln liées aux assistants IA qui se retrouvent intégrés dans nos outils de développement… Donc ouvrez l’oeil car on ne sait jamais ce qui sa cache vraiment dans une pull request.

Source

  •  

Une faille Spotlight vieille de 10 ans permet toujours de voler vos données sur Mac

Si vous êtes sous Mac, je pense que comme moi, vous passez votre temps à chercher des fichiers ou lancer des applications avec Spotlight… Si vous ne connaissez pas cet outil, c’est un truc super pratique d’Apple qui indexe tout votre disque dur pour vous faire gagner du temps. Command+Espace, trois lettres tapées, et hop, votre document apparaît. Pratique, non ?

Sauf que voilà, depuis presque 10 ans maintenant, ce même Spotlight peut servir de cheval de Troie pour siphonner vos données les plus privées. Et le pire, c’est qu’Apple le sait et n’arrive toujours pas à vraiment colmater la brèche.

Patrick Wardle, le chercheur en sécurité derrière plusieurs outils populaires comme LuLu , vient d’expliquer sur son blog Objective-See une technique ahurissante qui permet à un plugin Spotlight malveillant de contourner toutes les protections TCC de macOS. Pour info, TCC (Transparency, Consent and Control), c’est le système qui vous demande si telle application peut accéder à vos photos, vos contacts, votre micro… Bref, c’est censé être le garde du corps de votre vie privée sous Mac.

Alors comment ça marche ?

Hé bien au lieu d’essayer de forcer les portes blindées du système, le plugin malveillant utilise les notifications Darwin comme une sorte de morse numérique. Chaque byte du fichier à voler est encodé dans le nom d’une notification (de 0 à 255), et un processus externe n’a qu’à écouter ces notifications pour reconstruire le fichier original, octet par octet. C’est du génie dans sa simplicité !

Ce qui rend cette histoire encore plus dingue, c'est que cette vulnérabilité a été présentée pour la première fois par Wardle lui-même lors de sa conférence #OBTS v1.0 en 2018. Il avait déjà montré comment les notifications pouvaient permettre aux applications sandboxées d'espionner le système.

Plus récemment, Microsoft a “redécouvert” une variante de cette technique cette année et l’a baptisée “ Sploitlight ”. Ils ont même obtenu un joli CVE tout neuf (CVE-2025-31199) pour leur méthode qui consistait à logger les données dans les journaux système. Apple a corrigé cette variante dans macOS Sequoia 15.4… mais la méthode originale de Wardle fonctionne toujours, même sur macOS 26 (Tahoe) !

Et sinon, savez-vous ce que ces plugins peuvent voler exactement ?

Il y a notamment un fichier bien particulier sur votre Mac, caché dans les profondeurs du système, qui s’appelle knowledgeC.db. Cette base de données SQLite est littéralement le journal intime de votre Mac. Elle contient tout :

  • Quelles applications vous utilisez et pendant combien de temps
  • Vos habitudes de navigation web avec Safari (historique détaillé, fréquence des visites, interactions)
  • Quand vous branchez votre téléphone
  • Quand vous verrouillez votre écran
  • Vos trajets en voiture avec CarPlay
  • Vos routines quotidiennes et patterns comportementaux

C’est le genre de données qui raconte votre vie mieux que vous ne pourriez le faire vous-même. Et avec les nouvelles fonctionnalités d’Apple Intelligence dans macOS Tahoe, cette base de données alimente directement l’IA d’Apple pour personnaliser votre expérience.

Avec ce fichier, quelqu’un pourrait non seulement voir ce que vous faites maintenant sur votre Mac, mais aussi reconstituer vos habitudes des 30 derniers jours. À quelle heure vous commencez votre journée, quelles apps vous lancez en premier, combien de temps vous passez sur tel ou tel site… C’est le rêve de n’importe quel espion ou publicitaire, et c’est accessible via une simple vulnérabilité Spotlight.

Apple a bien sûr essayé de corriger le tir. Dans macOS 15.4, ils ont ajouté de nouveaux événements TCC au framework Endpoint Security pour mieux surveiller qui accède à quoi. Ils ont aussi corrigé la variante découverte par Microsoft (CVE-2025-31199).

Mais… la vulnérabilité de base présentée par Wardle fonctionne toujours sur macOS 26 (Tahoe), même en version Release Candidate avec SIP activé ! C’est comme ajouter une serrure supplémentaire sur la porte alors que tout le monde passe par la fenêtre depuis 10 ans.

Wardle a une idée toute simple pour régler définitivement le problème : Apple pourrait exiger une notarisation pour les plugins Spotlight, ou au minimum demander l’authentification et l’approbation explicite de l’utilisateur avant leur installation. Actuellement, n’importe quel plugin peut s’installer tranquillement dans ~/Library/Spotlight/ et commencer à espionner vos données, sans même nécessiter de privilèges administrateur.

Alors bien sûr, avant que vous ne couriez partout comme une poule sans tête, il faut relativiser :

  1. Cette attaque nécessite un accès local à votre système - on ne parle pas d’une vulnérabilité exploitable à distance
  2. Il faut qu’un malware ou un attaquant installe d’abord le plugin malveillant sur votre Mac
  3. La “bande passante” est limitée - transmettre octet par octet n’est pas très efficace pour de gros fichiers
  4. macOS affiche une notification quand un nouveau plugin Spotlight est installé (même si cette alerte peut être contournée)

Ça fait quand même quelques conditions… mais le fait que cette faille existe depuis près de 10 ans et fonctionne toujours sur la dernière version de macOS reste préoccupant.

Cette histoire nous rappelle que les outils les plus dangereux sont souvent ceux auxquels on fait le plus confiance… Wardle fournit même un proof-of-concept complet sur son site pour que la communauté puisse tester et comprendre le problème. Espérons qu’Apple prendra enfin cette vulnérabilité au sérieux et implémentera les mesures de sécurité suggérées.

En attendant, restez vigilants sur les applications que vous installez et gardez un œil sur les notifications système concernant l’installation de nouveaux plugins Spotlight !

  •