Une bibliothèque Python avec les principes et objectifs suivants :
Permettre la reproduction aussi simple que possible des recherches précédentes sur le dilemme du prisonnier itératif.
Créer l'outil de facto pour les futures recherches sur le dilemme du prisonnier itératif.
Fournir un moyen aussi simple que possible pour que tout le monde puisse définir et contribuer à de nouvelles stratégies originales pour le dilemme du prisonnier itératif.
-Mettre l'accent sur la lisibilité ainsi que sur une communauté ouverte et accueillante qui s'adapte aux développeurs et aux chercheurs de différents niveaux de compétence.
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.
Vous venez de claquer plusieurs milliers d’euros dans une solution antivirus dernier cri pour votre boîte car le commercial vous a convaincu avec du machine learning, de l’IA comportementale, du threat hunting prédictif et j’en passe…
Cool story ! Mais si je vous disais qu’un petit exécutable open source gratuit peut potentiellement passer à travers ? Ce programme s’appelle
al-khaser
et je vous assure qu’il va vous faire déchanter, car ce truc, c’est le détecteur de mensonges des solutions de cybersécurité.
Al-khaser est outil qui ne fait rien de méchant en soi… C’est ce qu’on appelle un PoC, un “proof of concept” avec de bonnes intentions car il rassemble dans un seul programme toutes les techniques que les vrais malwares utilisent pour se planquer tels que la détection de machines virtuelles, le contournement des débogueurs, l’échappement aux sandbox, et j’en passe.
Comme ça, si votre antivirus ne détecte pas al-khaser, il y a de bonnes chances qu’il rate aussi les vraies menaces qui utilisent les mêmes techniques.
Faut dire que les éditeurs d’antivirus et d’EDR adorent nous vendre leurs nouvelles fonctionnalités IA de fou alors que certaines de leurs solutions ne détectent même pas des techniques pourtant connues depuis longtemps.
Al-khaser met donc tout ça en lumière de façon assez brutale en enchaînant des dizaines de vérifications. Par exemple, il va regarder si votre processeur a vraiment le bon nombre de cœurs ou si c’est une simulation. Il va checker l’adresse MAC de votre carte réseau pour voir si elle correspond à un hyperviseur VMware ou VirtualBox. Il va mesurer le temps d’exécution de certaines opérations pour détecter si le système est accéléré artificiellement, comme dans une sandbox d’analyse. Il va même tester des API Windows classiques comme IsDebuggerPresent ou CheckRemoteDebuggerPresent pour voir si quelqu’un espionne son exécution.
Maintenant si vous voulez tester les protections anti-debug de votre système, vous tapez :
al-khaser.exe –check DEBUG –sleep 30
Oui si vous voulez voir si votre virtualisation VMware ou QEMU est bien masquée :
al-khaser.exe –check VMWARE –check QEMU
Bien sûr, ces techniques ne sortent pas de nulle part car elles sont documentées depuis des années notamment
dans ce référentiel
dont je vous
déjà parlé
.
Les équipes de pentest et les red teams adorent al-khaser car ça leur permet de montrer aux décideurs que leur gros investissement en cybersécurité n’est peut-être pas aussi solide qu’ils le pensaient. Vous lancez l’outil un vendredi après-midi dans un environnement de test, et vous voyez instantanément ce que votre EDR détecte ou pas.
Voilà, une fois encore, rassurez-vous, al-khaser ne fait rien de malveillant… Il ne vole pas de données, ne chiffre pas vos fichiers, ne lance pas de ransomware mais se contente juste de lever la main et de dire “hé ho, je suis là, regardez moi, je fais plein de des trucs louches !!”.
Bien sûr, ne lancez pas al-khaser sur n’importe quelle machine car c’est un outil de test qui doit rester dans un environnement contrôlé. Si vous le lancez sur le réseau de prod sans prévenir votre équipe sécu, vous allez déclencher des alertes partout et recevoir des appels pas très sympathiques. Et surtout, juridiquement, vous devez avoir l’autorisation du propriétaire de l’infrastructure, sinon, vous risquez de gros ennuis.
Ce projet est open source, écrit essentiellement en C++, et disponible sur GitHub. Y’a plus qu’à vous monter une VM isolée, récupérer al-khaser, et voir ce que ça donne.
En octobre 2016, un développeur suisse connu sous le pseudo swisskyrepo a commencé à compiler ses notes de pentester dans un dépôt GitHub. Rien de révolutionnaire au départ, juste un mec qui en avait marre de chercher la même injection SQL pour la 50ème fois dans ses notes. Mais ce qui est cool c’est qu’au fur et à mesure des années, il a structuré ça proprement avec une section par type de vulnérabilité, des README clairs, des fichiers Intruder pour Burp Suite, des exemples concrets…etc.
Ce qui était donc au départ un simple carnet de notes personnel est devenu THE référence mondiale en cybersécurité offensive avec des centaines de contributeurs qui ajoutent quotidiennement de nouvelles techniques. C’est devenu la pierre de Rosette (pas la charcuterie, renseignez-vous !! lol) de la sécurité offensive, celle qu’on cite dans tous les cours de certification OSCP, celle qu’on consulte pendant les CTF, celle qu’on recommande aux débutants…
Avant PayloadsAllTheThings, le savoir en cybersécurité offensive était soit verrouillé dans des formations hors de prix à 5 000 boules, soit éparpillé dans des recoins obscurs du web, soit jalousement gardé par des pentesters qui pètent plus haut que leur cul… Des pêt-testeurs quoi…
SwisskyRepo a d’ailleurs fait un choix radical qui est tout mettre en open source, sous licence MIT, accessible à tous. Et le contenu, c’est du lourd !
On y trouve tout ce dont un pentester peut avoir besoin : SQL Injection avec toutes les variantes possibles (MySQL, PostgreSQL, Oracle, MSSQL…), XSS avec les bypasses de filtres, SSRF avec les techniques d’exfiltration, Command Injection, OAuth Misconfiguration, GraphQL Injection, File Inclusion, Authentication Bypasses, API Key Leaks…etc… La liste est hallucinante.
Chaque section est structurée comme un cookbook technique avec le contexte de la vulnérabilité, les payloads classés par type, les bypasses pour contourner les protections, des exemples concrets, et les références vers les CVE ou les articles de recherche.
Par exemple, si vous voulez exploiter un serveur Redis mal configuré, il y a une section pour ça. Si vous voulez comprendre comment contourner un WAF, pareil ! Et si vous cherchez à pivoter dans un réseau interne après avoir compromis une machine, tout est documenté en anglais sur ce site.
Mais swisskyrepo ne s’est pas arrêté là. Son projet a muté en écosystème puisqu’il a aussi créé
InternalAllTheThings
, un wiki dédié au pentesting interne et aux attaques Active Directory (Certificate Services, Enumeration, Group Policies, Kerberos attacks, Hash manipulation, Roasting techniques…).
Et également
HardwareAllTheThings
, le même genre de wiki mais sur la sécurité hardware et IoT : JTAG, SWD, UART pour les interfaces de debug, firmware dumping et reverse engineering, Arduino, Raspberry Pi, Flipper Zero pour les gadgets, Bluetooth, CAN, WiFi, RFID/NFC pour les protocoles, SDR et GSM pour la radio, fault injection pour les attaques par canal auxiliaire…
Bref, tout ce qu’il faut savoir pour hacker des objets connectés, des cartes à puce ou des systèmes embarqués.
Du coup, avec cette famille complète de “AllTheThings”, on couvre toute la surface d’attaque moderne, le web, l’infra interne et le hardware. Un pentest complet peut donc se faire avec ces trois ressources comme base de connaissance. Chouette non ?
Bien, sûr c’est à utiliser dans un cadre légal, sinon, vous irez en prison ! C’est pas un forum de script kiddies qui échangent des zero-days volés, c’est une vraie bibliothèque technique pour les professionnels et les étudiants en cybersécurité.
Grâce à ça, un étudiant motivé peut devenir compétent en sécurité offensive en quelques mois juste avec des ressources gratuites : PayloadsAllTheThings pour les techniques, TryHackMe ou HackTheBox pour la pratique, les blogs de chercheurs pour les analyses approfondies, les conférences enregistrées (DEF CON, Black Hat) pour rester à jour.
Le savoir se libère, n’en déplaise aux relous ! Moi je trouve que c’est cool, car ça vulgarise les connaissances, ça les mets à la portée de tous et c’est tant mieux.
Donc un grand merci à SwisskyRepo d’avoir lancé ce projet !
Les IA de type GPT ont beau avoir des instructions du genre “tu ne dois jamais révéler ton prompt système”, il suffit de leur demander gentimment de réencoder leurs instructions avec un décalage de César ou de répéter tout le texte dans un format particulier pour qu’elles crachent tout. Et par tout, je veux dire vraiment tout. Le prompt officiel d’OpenAI, d’Anthropic, de Gemini…etc, les instructions personnalisées du créateur, et même les petits Easter eggs cachés dedans.
Dans cette vidéo, je vous montre plusieurs exemples concrets. Un GPT de génération de logos, une calculatrice mathématique qui cache un Easter egg , un optimiseur SEO…etc. Et pour chacun, j’utilise des prompts d’extraction que j’ai trouvés dans
ce repo GitHub
qui rassemble tous les prompts système leakés de ChatGPT, Claude, Cursor, Perplexity et compagnie. C’est une vraie caverne d’Ali Baba pour ceux qui s’intéressent à ce genre de trucs.
Ce qui est intéressant, c’est que ça ne fonctionne pas que sur les GPTs personnalisés. Vous pouvez aussi extraire les prompts système de Perplexity, de Grok, de plein d’outils qui utilisent des LLM sous le capot. Donc si vous avez toujours voulu savoir comment tel ou tel service construit ses réponses, c’est l’occasion.
Maintenant, je sais ce que vous allez me dire…
C’est pas très éthique de voler le travail des gens comme ça et vous avez raison. Mais d’un autre côté, si ces boites permettent que ce soit aussi facile d’extraire ces infos, c’est peut-être qu’il faut arrêter de considérer les prompts système comme des secrets industriels. Et puis eux ne se privent pas pour voler aussi les contenus des autres, donc bon…
Je vous montre aussi dans ma vidéo comment certains créateurs essaient de se protéger en mettant des instructions anti-extraction, mais ça ne marche pas terrible.
Bref, j’espère que vous y apprendrez quelques trucs. Et je voudrais aussi dire un grand merci
aux Patreon sans qui cette vidéo, ce blog et moi-même n’existeraient pas ! Merci pour le soutien !
Vous savez ce moment où vous regardez votre historique Git et vous vous demandez qui est le débile qui a écrit ce code dégueulasse ?
Ah bah ouais, c’était vous il y a 3 mois ^^. Eh bien
GitType
a trouvé la meilleure des thérapies qui est de vous faire retaper tout ça, lettre par lettre, comme une punition de primaire version développeur, totalement gamifiée avec des points, un chrono, et la possibilité de mesurer à quel point vos doigts sont devenus flasques depuis que Copilot fait tout le boulot à votre place.
Le tagline du projet, c’est “Show your AI who’s boss: just you, your keyboard, and your coding sins”. Et c’est pas une blague, c’est un manifeste car pendant que Copilot, ChatGPT, Claude Code et compagnie écrivent du code à notre place, GitType vous fait faire exactement l’inverse… il vous force à retaper du code pour redevenir bon !
Et contrairement aux tests de frappes classiques comme
Ttyper
ou
tt
qui vous font taper du texte générique, GitType utilise du VRAI code source. Votre code, celui de vos repos préférés, ou des repos trending de GitHub. Comme ça, vous ne vous entraînez pas sur du “the quick brown fox jumps over the lazy dog” à la con, mais sur vos propres merdes spaghettico-syntaxiques en Rust, TypeScript, Python ou Go.
Le jeu vous propose plusieurs modes. Y’a le mode Normal pour vous échauffer tranquillement, le Time Attack quand vous voulez vous mettre la pression, et des niveaux de difficulté de Easy à Zen pour ceux qui veulent méditer en tapant du code. Le tout avec un tracking en temps réel de votre WPM (words per minute) et de votre précision. Comme ça, plus vous progressez, plus vous montez dans le ranking avec des titres de développeur qui évoluent.
GitType supporte plus de 15 langages de programmation et propose plus de 15 thèmes visuels en mode Dark ou Light, avec possibilité de personnaliser le vôtre. L’installation est simple…
Ou via Brew, ou avec un téléchargement direct de binaires. Ça prend 30 secondes chrono. Autre truc sympa aussi, vous pouvez cloner n’importe quel repo GitHub directement depuis le jeu pour vous entraîner dessus.
Comme ça, vous pourrez réaliser votre fantasme le plus humide, à savoir retaper le code de Linus Torvalds !
Cet outil va comme ça l’air de rien vous réapprendre à taper du code vous même, parce que faut bien le reconnaitre, depuis que tout le monde s’est mis au vibe coding, c’est difficile de dire à nos doigts et nos cerveaux de s’y remettre. Avec GitType, vos doigts retrouvent leurs réflexes, vous mémorisez mieux la syntaxe, vous devenez plus rapide au clavier, votre haleine redevient fraiche et vous chopez enfin des matchs sur Tinder, c’est SÛR !!
Ce projet est dispo en
open-source sous licence MIT
et franchement, vu comment nos IA nous assistent de partout, c’est pas plus mal de garder un peu de muscle mémoire au cas où…
Utilisateurs de npm, préparez-vous à des changements sur l’authentification et la publication.
GitHub vient de faire passer le message. Il entend réduire, « dans un avenir proche », la gamme d’options disponibles. Ne resteront plus que :
La publication locale avec MFA obligatoire
Les tokens granulaires avec durée de vie limitée à 7 jours
Le trusted publishing
Dans ce cadre, les tokens “classiques” (legacy) seront supprimés. Il en ira de même pour le MFA à base de codes TOTP : il faudra utiliser des méthodes FIDO. Quant aux tokens granulaires, ils expireront plus vite s’ils incluent des permissions de publication.
GitHub compte aussi paramétrer la publication de sorte que les tokens ne seront pas autorisés par défaut. Objectif : encourager l’usage de la publication locale avec MFA… ou du trusted publishing. Cette fonctionnalité implémente un standard défini par l’OpenSSF. Elle utilise l’authentification OIDC pour créer une relation de confiance entre npm et les fournisseurs CI/CD (pour le moment, GitHub Actions et les pipelines GitLab, les exécuteurs autohébergés n’étant pas pris en charge). PyPi fut le premier gestionnaire de paquets à l’adopter, en 2023. RubyGems, crates.io et NuGet, entre autres, ont suivi.
npm récemment compromis par un ver
Sur npm, le trusted publishing est intégré depuis juillet 2025. Il était initialement question d’en laisser se développer l’usage sans incitation particulière. Mais le contexte actuel ne le permet pas, affirme GitHub.
Ce contexte, c’est celui d’une recrudescence des attaques sur les registres de paquets logiciels. Illustration avec celle dite Shai-Hulud (du nom d’un ver des sables dans Dune). Elle a ciblé l’écosystème npm.
À l’origine, il y a possiblement une campagne de phishing ayant ciblé les développeurs, invités à “mettre à jour” leurs options de connexion MFA.
Les comptes ainsi compromis ont servi à publier un package contenant un malware. Celui-ci détectait des authentifiants dans l’environnement compromis (tokens npm et GitHub, clés d’API AWS/Azure/GCP) et les exfiltrait… tout en les rendant publics sur le compte GitHub des victimes.
Les tokens npm ainsi dérobés ont permis d’enclencher un processus de propagation automatisée du malware, ainsi apparenté à un ver. Plus de 500 packagesauraient été compromis.
À l’heure actuelle, il reste possible, sur npm, de ne pas exiger le MFA pour la publication des paquets et la modification de leurs paramètres. Pour qui l’active, reste la possibilité d’autoriser les tokens, granulaires ou legacy. Les tokens legacy (aussi dits jetons d’automatisation) permettent de télécharger des paquets et d’en publier. Ils héritent des permissions dont bénéficie l’utilisateur qui les crée. Les tokens granulaires ont une date d’expiration et peuvent être associés à des organisations. On peut aussi les limiter à certains paquets et à des plages d’adresses IP.
Astronomy Engine : calcul multilingue des positions du soleil, de la lune et des planètes. Prévoit les phases lunaires, les éclipses, les transits, les oppositions, les conjonctions, les équinoxes, les solstices, les heures de lever et de coucher, ainsi que d'autres événements. Fournit des transformations de coordonnées vectorielles et angulaires entre les orientations équatoriales, écliptiques, horizontales et galactiques.
Connexion
