❌

Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Faille WSUS CVE-2025-59287 - Comment Microsoft s'est fait pirater par le code qu'il avait banni

✇Korben
Korben

Je vais vous raconter la meilleure de la semaine… Microsoft vient quand même de passer 5 ans à gueuler sur tous les toits que BinaryFormatter est dangereux (ça servait à sérialiser/desérialiser des objets en binaire ave .NET) et qu’il faut arrêter de l’utiliser… et pourtant, on vient d’apprendre qu’ils continuent secrètement de l’utiliser dans WSUS (Windows Server Update Services), leur système censé sécuriser les mises à jour Windows.

Et bien sûr, ce qui devait arriver, arriva… Une magnifique faille critique dans WSUS vient d’être rendue publique, ce qui met en danger environ 500 000 serveurs WSUS actuellement accessibles via le net.

L’histoire commence en réalité en 2020. A cette date, Microsoft déclare officiellement que BinaryFormatter est dangereux, ce qui ne les empêche pas de se faire poutrer Exchange, Azure DevOps, SharePoint en 2021/2021 justement à cause de ça. Du coup, en 2023, ils annoncent le bannissement total de BinaryFormatter en interne. En 2024, ils effectuent même une mise au rebus complète de .NET 9.

Mais c’était sans compter sur cette jolie CVE-2025-59287 d’octobre 2025 qui exploite à son tour BinaryFormatter dans WSUS !

Un oubli ? Pas si sûr, car Microsoft l’utilisait toujours pour déchiffrer les cookies d’authentification de WSUS, rendant ainsi ce système de mises à jour censé protéger Windows vulnérable. La faille, c’est donc une désérialisation non sécurisée. Un attaquant non authentifié envoie une requête SOAP craftée au endpoint GetCookie de WSUS, avec un cookie AuthorizationCookie contenant un payload malveillant. Et de son côté le serveur déchiffre ce truc avec AES-128-CBC, puis passe le résultat directement à BinaryFormatter pour désérialisation.

Et là, bim bam boum, une magnifique exécution de code arbitraire avec privilèges SYSTEM !

Techniquement, la vulnérabilité touche donc les Windows Server 2012 à 2025 qui ont le rôle WSUS activé. Le score CVSS de cette faille est quand même de 9,8 sur 10 ce qui est fait une faille super critique.

L’exploitation de cette faille débute le 24 octobre soit juste après la publication du patch d’urgence de Microsoft sortie la veille c’est à dire le 23 octobre, pour corriger lui-même un autre patch publié juste avant le 8 octobre. Bref un vrai bordel et il faut croire que les attaquants ont attendu la sortie de ce patch d’urgence pour comprendre comment fonctionnait la faille ( l’exploit est ici ).

De son côté, Google Threat Intelligence traque l’acteur cybercriminel UNC6512 qui a ciblé plusieurs organisations et les chiffres font pas plaisir puisque ce sont environ 100 000 tentatives d’exploitation en 7 jours qui ont eu lieues, et 500 000 serveurs WSUS exposés sur le net sur les ports par défaut (8530 HTTP, 8531 HTTPS).

Microsoft a dû sentir la douille arriver puisqu’ils ont déprécié WSUS en septembre de l’année dernière au profit d’autres solutions comme Intune ou WUfb, soit un an avant la sortie de la CVE. Mais bien sûr, comme l’outil reste dans Windows Server 2025 avec ses 10 ans de support réglementaire, des centaines de milliers d’entreprises l’utilisent encore…

Le chaos était garanti ! Maintenant vous me connaissez, je n’aime pas vous laisser sans solution, alors pour les admins sys qui lisent ça, sachez qu’il existe un script PowerShell baptisé Find-WSUS qui permet de détecter tous les serveurs WSUS configurés dans vos GPO. C’est pratique pour faire l’inventaire et vérifier que tout est patché. Et notez aussi que le patch d’urgence c’est le KB5070883. Et si vous ne pouvez pas patcher immédiatement parce que la vie est injuste, désactivez quand même le rôle WSUS de vos Windows Server, ou bloquez les ports 8530/8531 directement dans votre firewall.

Le vrai problème en fait, c’est que WSUS n’est qu’un symptôme car une grosse partie du code en entreprise est constitué de dette technique. C’est à dire du code “mort” qui continue de tourner car personne n’ose y toucher. Brrr… ça fait peur c’et sûr ! Surtout que même Microsoft n’arrive pas à tuer sa propre création 5 ans après l’annonce de sa mort officielle, donc autant dire qu’on a tous un sérieux problème.

Bref, patchez au plus vite !

Source

CamoLeak - Quand un simple commentaire GitHub transforme Copilot en espion

✇Korben
Korben

Y’a plein de problèmes 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 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écis, 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

✇Korben
Korben

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 !

ChatGPT peut faire fuiter vos emails avec une simple invitation Google Calendar

✇Korben
Korben

Vous attaquez votre lundi matin, tranquillement avec votre petit café… vous ouvrez ChatGPT pour lui demander votre planning de la semaine et là, PAF (façon De Funès ^^), toute votre correspondance Gmail part directement chez un cybercriminel.

Ce serait fou non ? Et bien c’est exactement ce qu’un chercheur vient de démontrer et tout ça à cause d’une simple invitation Google Calendar.

Eito Miyamura, co-fondateur d’EdisonWatch , a lâché une bombe sur X le 12 septembre et sa démo est terrifiante. En gros, il simule un attaquant qui envoie une invitation Google Calendar vérolée, ensuite vous demandez innocemment à ChatGPT “Qu’est-ce que j’ai de prévu aujourd’hui ?”, et l’IA se transforme en espion qui fouille vos emails et les envoie au pirate. Vous n’avez même pas besoin de voir ou d’accepter l’invitation. Elle est là, dans votre calendrier, comme une bombe à retardement.

Et ça tombe mal niveau comm, car OpenAI vient tout juste d’intégrer le support complet du MCP (Model Context Protocol) dans ChatGPT. Cette technologie permet en effet à l’assistant de se connecter directement à Gmail, Google Calendar, SharePoint, Notion… Pratique pour la productivité, mais catastrophique pour la sécurité.

Cette attaque exploite ce qu’on appelle l’injection de prompt indirecte. Au lieu d’essayer de tromper ChatGPT directement, l’attaquant cache ses instructions malveillantes dans des données que l’IA est autorisée à lire. Dans ce cas précis, le texte d’un événement calendrier… Ensuite ChatGPT lit l’invitation, voit les instructions cachées, et les exécute docilement.

Selon les experts en sécurité qui se sont penchés sur le problème, le MCP n’a pas été conçu avec la sécurité en priorité. Les risques incluent donc les injections de prompt, les permissions d’outils vulnérables et les outils sosies qui peuvent remplacer silencieusement les outils de confiance.

Sympa, hein ?

D’ailleurs, ce n’est pas la première fois qu’on voit ce genre d’attaque puisqu’en août, des chercheurs avaient déjà démontré comment une invitation compromise pouvait manipuler Google Gemini pour contrôler des appareils domotiques et voler des informations. Le papier s’appelait joliment “Invitation Is All You Need”. Prophétique.

Vitalik Buterin lui-même a réagi à cette vulnérabilité. Il explique que compter aveuglément sur un seul système IA est trop fragile et facilement manipulable et je trouve que cette nouvelle exploitation de ChatGPT lui donne raison !

D’ailleurs, même avec les navigateurs IA, vous n’êtes pas tranquille. D’après cette autre découverte, vous pouvez littéralement vous faire vider votre compte bancaire en scrollant sur Reddit. En effet, des instructions malveillantes peuvent être cachées dans des commentaires sur des sites que l’attaquant ne contrôle même pas, ce qui peut entrainer votre navigateur IA à faire des choses que vous n’avez pas autorisé.

Bref, cette nouvelle vulnérabilité met en lumière un problème fondamental des LLM : ils ne savent pas faire la différence entre des instructions légitimes et des commandes malveillantes cachées dans du contenu. Car contrairement aux applications traditionnelles qui peuvent séparer les instructions développeur des inputs utilisateur, les LLM acceptent tout en langage naturel. Pour rester flexibles, ils doivent pouvoir répondre à des configurations infinies d’instructions et c’est cette flexibilité qui fait leur force… mais qui est également leur talon d’Achille.

Trail of Bits a même démontré une variante encore plus sournoise où des images spécialement forgées contiennent des prompts cachés. Invisibles en haute résolution, les instructions malveillantes apparaissent quand l’image est réduite par les algorithmes de prétraitement. L’IA lit alors le message et l’interprète comme une instruction légitime.

Ainsi, quand une IA suit des instructions malveillantes depuis du contenu web, les protections traditionnelles comme la same-origin policy ou CORS deviennent inutiles. L’IA opère avec tous vos privilèges sur toutes vos sessions authentifiées. Accès potentiel à vos comptes bancaires, systèmes d’entreprise, emails privés, stockage cloud… C’est vite le jackpot pour un attaquant.

Alors, comment se protéger ?

Hé bien Google recommande de changer les paramètres de Calendar pour que seules les invitations de contacts connus ou acceptées apparaissent. Cachez aussi les événements refusés et surtout, restez extrêmement prudent avec les intégrations tierces et les autorisations accordées…

Voilà, donc la prochaine fois que ChatGPT vous demandera l’autorisation d’accéder à votre Gmail, réfléchissez-y à deux fois car ça pourrait vous coûter bien plus cher qu’un peu de temps gagné.

Source

❌