Une alliance internationale de 18 pays, menée par la France et les Pays-Bas, a démantelé First VPN, le réseau d’anonymisation fétiche des cybercriminels. En saisissant l'intégralité de sa base de données, la police a d'ores et déjà identifié des milliers de pirates à travers le monde, mettant fin à des années d'impunité.
Flipper Devices, les gens derrière le fameux Flipper Zero , viennent de dévoiler leur prochain joujou, le Flipper One . Et leur annonce démarre par cette phrase de Pavel Zhovner, le co-fondateur : « on est franchement terrifiés, et on a besoin de vous ».
Apparemment, ce nouveau projet l'angoisse et faut être honnête, y'a de quoi. Car le Flipper One, ce n'est pas un Flipper Zero en plus gros. C'est carrément un mini-PC Linux ARM de poche, pensé comme un couteau suisse pour le réseau. Et là où le Zero causait uniquement aux protocoles de proximité (NFC, RFID, sub-GHz, infrarouge), le One joue dans la cour du dessus, en s'adressant également au monde IP, donc tout ce qui est Wi-Fi, Ethernet, 5G et même satellite. Ahaha, j'adore !
Et côté tripes, s'ils tiennent leurs promesses, ça va envoyer du lourd ! En effet, on va y retrouver un Rockchip RK3576 8 cœurs cadencé avec GPU Mali et un NPU pour faire tourner des modèles d'IA en local, 8 Go de RAM, deux ports Gigabit Ethernet indépendants, du Wi-Fi 6E qui gère le monitor mode, un modem 5G en module M.2, et une sortie HDMI 2.1 en 4K.
En gros, vous avez un routeur, un analyseur de signaux et un thin client réunis dans un truc qui tient dans la poche.
Puis y'a surtout ce truc de "double cerveau" avec à côté du gros CPU, un microcontrôleur RP2350 (celui du Raspberry Pi Pico 2) en plus qui pilote l'écran, les boutons et l'alimentation. Comme ça, même quand le Linux est éteint, l'appareil reste vivant et vous pouvez toujours gérer le boot et l'affichage sans réveiller le monstre.
Mais le vrai sujet de cette annonce, ce n'est pas la fiche technique. C'est l'ouverture du bestiau car le Flipper One vise un noyau Linux pur, celui de kernel.org, sans patch vendeur, ni blob binaire ou autres drivers proprio. C'est un truc de puriste qui va faire plaisir à tous les barbus !
Parce que oui, chez Flipper Devices, ils en ont marre des fabricants ARM qui balancent leurs « board support packages » crades que personne ne comprend, comme le fait Raspberry Pi au passage. Alors pour y arriver, ils bossent à fond avec Collabora afin de pousser le support du RK3576 directement dans le kernel officiel.
Et c'est là qu'arrive le « we need your help » car plutôt que de bidouiller dans leur coin, ils ouvrent d'un coup tout le processus de développement dès le premier jour. Leurs trackers de tâches, leurs débats d'architecture, leurs docs à moitié finies, bref tout le bazar que les boîtes planquent d'habitude, bah eux, ils le mettent à dispo ! Et c'est pour cela qu'ils cherchent des gens pour le support du kernel, pour tester le Wi-Fi en audit et injection, pour trancher le choix du bureau (KDE Plasma ou un gestionnaire en tiling plus léger ?), et même pour entraîner un petit modèle d'IA maison.
Et au-dessus de tout ça, ils préparent leur Flipper OS, une couche sur du Debian qui introduit une notion de « profils » qui n'est ni plus ni moins qu'un instantané complet du système avec ses paquets préconfigurés. Vous bootez dessus, vous le clonez, vous le cassez, et hop vous revenez à une copie propre sans tout reflasher.
Ils bossent aussi sur FlipCTL, un framework pour habiller les utilitaires Linux en menus sur petit écran, avec comme objectif de le rendre installable d'un simple apt install ailleurs que sur leur produit.
Après, j'espère que ça va bien se passer pour eux car malgré leur succès, Flipper Devices traîne un passif chargé. Le Flipper Zero s'est écoulé à plus d'un million d'exemplaires, mais il a été viré d'Amazon en 2023, étiqueté « appareil de skimming », puis carrément banni au Canada début 2024 sous prétexte qu'il servait à voler des voitures.
C'était d'ailleurs des accusations bidons vu que le bestiau dans sa forme de base est incapable de mener les attaques par relais qu'on utilise en général pour voler des voitures. Heureusement pour eux, la justice canadienne a fini par reculer, mais bon, leur réputation grand public est faite malheureusement.
L'autre point qui va vous calmer, c'est que vous ne pourrez pas encore l'acheter... Le moyen le plus rapide sera de lâcher 350 $ dans leur prochaine campagne Kickstarter prévue cette année. Et encore, le projet pourrait ne jamais sortir...
Voilà, du coup, si l'idée d'un Linux de poche sans compromis vous parle, le mieux pour aider, c'est peut-être d'aller mettre les mains dans le cambouis sur leur portail dev.
Perso, un cyberdeck ouvert jusqu'au noyau, moi ça me plait bien. Le Flipper Zero, ça m'a jamais convaincu mais ce Flipper One, déjà pour moi, il est beaucoup plus convaincant... On verra s'ils tiennent la distance maintenant. Et si vous voulez creuser le genre, jetez un œil à ce cyberdeck fait maison , au WiFi Pineapple côté audit sans fil, et à Intercept pour l'analyse radio.
À suivre de très près !
Bon, alors là, Google a fait encore trèèèès fort.
Mercredi matin, la firme de Mountain View a carrément publié sur son propre bug tracker Chromium le code d'exploitation d'une faille... qui n'est toujours pas corrigée ! Et pas une petite vulnérabilité oubliée dans un coin, hein, mais une vraie faille de la mort qui tue que la chercheuse indépendante Lyra Rebane leur avait remontée gentiment et en privé . Ça fait 29 mois (2 ans et demi, les matheux ^^) et elle attend toujours un patch !
Le truc vise la Browser Fetch API, un mécanisme qui permet à un site de télécharger de gros fichiers en arrière-plan, genre une longue vidéo. Sauf qu'en la détournant, le code ouvre un service worker qui reste actif en permanence. Du coup, un site malveillant que vous visitez peut glisser un bout de JavaScript qui transforme votre navigateur en relais, tout cela à votre insu.
Parfait donc pour devenir un proxy anonyme pour des inconnus, un nœud de botnet pour des attaques DDoS, ou se faire surveiller quand on surfe sur le net... Et le plus vicelard, c'est que la connexion se rouvre ou reste ouverte même après avoir redémarré le navigateur, voire la machine entière.
Côté victimes, on parle de Chrome, de Microsoft Edge et de quasiment tous les navigateurs basés sur Chromium. Et que vous soyez sur Windows, macOS ou Linux, le bug s'en moque royalement. Rebane a confirmé que Brave, Opera, Vivaldi et Arc sont vulnérables eux aussi.
Bien sûr, Firefox et Safari, eux, passent clairement au travers, parce qu'ils ne supportent pas ce fameux téléchargement en arrière-plan. Bref, encore une fois, ne pas suivre le troupeau de mouton team-Chromium, ça paye !! Si vous cherchiez une raison de plus de larguer Google , la voilà servie sur un plateau.
Perso, ce qui me sidère, c'est que la faille a été classée S1, le deuxième niveau de gravité le plus élevé chez Google et il ne s'est toujours rien passé 29 mois après. C'est ouf quand même... Le post sur le tracker Chromium a bien été supprimé mais on le trouve toujours sur quelques archives / miroirs...
Après l'impact de cette faille, reste quand même limité car elle ne franchit aucune frontière... par exemple, elle ne donne pas accès à vos mails ni au reste de votre ordinateur, mais juste à ce qu'un navigateur sait déjà faire (ce qui est déjà énorme !!). Mais elle pourrait permettre à des cybercriminels de se constituer une flotte de milliers, voire de millions de navigateurs détournés, et le jour où une autre faille tombe, vous avez déjà l'armée prête à dégainer !! La bombe est là, il manque juste la mèche en fait !
Et pour se protéger ?
Bah franchement, pas grand-chose à faire côté utilisateur tant qu'il n'y a pas de patch. Si vous voulez mon avis bancal, le seul signal visible que vous pouvez guetter, c'est un menu de téléchargement qui s'ouvre tout seul sans raison, donc méfiez-vous donc si ça arrive. Maintenant si le sujet vous angoisse vraiment, basculer sur un navigateur pour les adultes ^^, genre Firefox ou Safari règlera la question d'un coup !
Faut pas oublier que Google passe son temps à pointer du doigt les éditeurs trop lents à patcher, alors j'comprends vraiment pas comment ils ont pu merder à ce point.
Alors celle-là, elle est incroyable les copains !
Le piratage du jour vient d'être confirmé par la plateforme qui héberge une bonne moitié du code de la tech mondiale ! En effet, Github a subi un accès non autorisé à ses propres dépôts internes, à cause d'une extension VS Code piégée installée sur l'ordi d'un employé !
L'annonce officielle est tombée sur le compte X de l'entreprise à l'instant et c'est comme ça que je suis tombé dessus.
GitHub dit avoir détecté et maîtrisé la compromission hier. L'extension VS Code malveillante a été retirée, le poste de travail isolé, et la rotation des secrets critiques est en cours. Côté impact, le message officiel c'est que "À l'heure actuelle, nous ne disposons d'aucune indication laissant supposer que les informations des clients stockées en dehors des référentiels internes de GitHub aient été compromises".
Du coup, nos repos perso, nos orgs, nos enterprises...etc, rien n'est normalement touché à ce stade, en tout cas selon ce que GitHub voit pour l'instant.
Le thread officiel de GitHub sur l'incident
Sauf que sur le darkweb, un acteur baptisé TeamPCP, repéré par le compte de threat intel Dark Web Informer, prétend détenir et vendre environ 4000 dépôts privés volés à GitHub. L'entreprise n'a pas publié de chiffre officiel mais a reconnu que la revendication était cohérente avec son enquête en cours, le rapport complet arrivera une fois bouclé.
Bref, à prendre au sérieux mais avec des pincettes le temps que ça se vérifie !
C'est vrai qu'en ce moment, on est dans une vague d'attaques supply chain qui ciblent les extensions VS Code , qui sont devenues un vrai vecteur d'attaque reconnu. Et tout le monde peut se faire piéger (même les ingés GitHub !).
Donc pour vous qui me lisez, la règle de base reste la même : Installez une extension VS Code uniquement si vous faites confiance à l'éditeur. En pratique, faut regarder le tag publisher verified, l'âge du compte, le nombre d'installs et la date de la dernière release, et surtout méfiez-vous des forks fraîchement republiés sous des noms qui ressemblent à un outil connu.
Pour suivre ça maintenant, le thread officiel et ses mises à jour sont sur le compte X de GitHub .
Cet article a été réalisé en collaboration avec École Polytechnique Executive Education
La cybersécurité est désormais au cœur de la survie des organisations. Afin d'avoir toutes les cartes en main, l'Institut Polytechnique de Paris, associé à des leaders de l'industrie, propose une formation diplômante d'excellence (Bac+5) à destination des cadres de haut niveau.
Cet article a été réalisé en collaboration avec École Polytechnique Executive Education
Il s’agit d’un contenu créé par des rédacteurs indépendants au sein de l’entité Humanoid xp. L’équipe éditoriale de Numerama n’a pas participé à sa création. Nous nous engageons auprès de nos lecteurs pour que ces contenus soient intéressants, qualitatifs et correspondent à leurs intérêts.
Meng Chen, doctorant à l'université Zhejiang, vient de prouver avec son équipe qu'on pouvait complétement détourner un assistant vocal IA avec un simple son que vous prendriez probablement pour un simple parasite. Avec sa bidouille, il a ainsi réussi à pousser les agents vocaux commerciaux de Microsoft et de Mistral à exécuter des actions que personne ne leur avait demandées.
Gloups !
L'attaque s'appelle AudioHijack, et ça consiste à planquer des ordres dans un fichier audio, une vidéo, un clip musical, une note vocale. Comme ça, le modèle qui l'écoutera vous obéira à VOUS, plutôt qu'à l'utilisateur. C'est comme une injection de prompt sauf que celle-ci s'entend à peine.
"Une demi-heure pour entraîner le signal, et comme il ignore le contexte, vous attaquez quand vous voulez, peu importe ce que dit l'utilisateur", résume Chen dans son interview . Reste qu'il faut un accès complet au modèle pour fabriquer le signal, ce que Microsoft et Mistral ne donnent pas. Alors il suffit à l'attaquant de l'entraîner sur un modèle ouvert qu'il contrôle, puis de rejouer le même signal contre le modèle fermé et en général, ça se passe bien parce qu'ils partagent souvent les mêmes briques audio.
Voilà et ça une fois que c'est fait, il suffit de "polluer" une source, et d'attendre qu'un poisson morde à l'hameçon...
Et le menu des possibilités est plutôt copieux vous allez voir. Le modèle peut par exemple prétendre qu'il ne sait pas traiter l'audio, refuser vos demandes, sortir de fausses infos, glisser un lien piégé, changer de personnalité, ou pire, déclencher des outils tout seul. Genre envoyer un mail avec vos données, ou télécharger un fichier depuis un serveur de l'attaquant s'il en a la possibilité technique (coucou MCP). Ainsi, sur les treize modèles testés, la réussite moyenne grimpe entre 79 et 96% selon le méfait.
Mais pour fabriquer ce signal vérolé, l'attaquant doit sentir dans quelle direction "pousser" le son pour rapprocher le modèle de son but, un peu comme suivre une pente vers le bas.
Sauf que ces modèles transforment l'audio en le découpant par exemple. Et la pente peut du coup devenir un escalier, puis du plat, voire une arête cassante... c'est clairement impossible à suivre ! Mais l'équipe de Chen a réussi à reconstituer cette pente à grand coups d'échantillonnage, puis a maquillé le bruit en réverbération.
Et comme notre oreille est trop limitée pour flairer l'anomalie, ça passe tranquille... Je vous avais déjà parlé de l'injection de prompt avec une simple doc empoisonnée qui pilote une IA , mais là, ça pourrait même surgir de la bande son d'une simple vidéo Youtube...
Et pour se protéger de ça, y'a pas grand chose à faire à part faire relire le prompt final... Le plus sûr, c'est donc plutôt de ne pas brancher votre assistant vocal sur vos mails, vos fichiers ou vos paiements, et de regarder plus en détails ce qui se passe s'il refuse soudainement une tâche ou vous sort un lien après avoir écouté un audio douteux...
De leur côté, les modèles fermés d'OpenAI ou d'Anthropic sont plus durs à viser, faute d'accès à l'architecture mais comme ils s'appuient aussi sur des briques audio open source, l'équipe de Meng pense que l'attaque pourrait se faire aussi.
Méfiance donc...
En marge de la publication de Linux 7.1-rc4, Linus Torvalds, créateur du noyau Linux, s'est penché sur un sujet qui cristallise les craintes de la communauté open source face à l'essor de l'IA : l'inondation de signalements de bugs.
Je me baladais sur les réseaux sociaux (ouais, c'est pas bien, je sais) quand je suis tombé sur un post X en reco avec un tuto Youtube où un mec explique comment gagner un petit peu d'ethers chaque jour. Évidemment, je flaire l'arnaque parce que dans la vie y'a que 3 façons de devenir riche : 1/ Monter sa boite 2/ Être né dans une famille déjà fortunée 3/ Ou se faire adopter par un vieux riche sans enfant afin de faire une magnifique captation d'héritage.
Mais ce que je voulais surtout c'est comprendre comment cette arnaque fonctionnait. Alors j'ai épluché un peut tout ça et j'en profite pour vous expliquer.
La vidéo, je vous la résume parce que franchement elle ne mérite pas un clic. Un type qui se fait appeler Josh Alex, sourire ultra-bright, vous vend l'idée qu'un "outil IA" peut sortir 1700 à 2000 dollars par jour en mode pilote automatique.
Le pitch, c'est qu'il a demandé à ChatGPT de lui pondre le code d'un bot de "sniping" sur Ethereum (c'est de l'arbitrage... en gros, passer devant les autres au bon moment pour gratter quelques dollars sur le mouvement du cours de la cryptomonnaie). Vous copiez ce code dans Remix (un vrai éditeur de smart contracts, parfaitement légitime, et c'est tout le problème), vous compilez en Solidity, vous déployez avec MetaMask, et hop, vous "financez le contrat" avec vos propres ethers.
Et plus vous mettez, plus vous gagnez, qu'il nous explique... Faut savoir que dans ce type d'arnaques, on réclame souvent un demi-ether minimum, genre 1500 - 2000 balles selon le cours du moment, soi-disant pour couvrir les frais de gas. Vous lancez ensuite le bot, vous attendez 3 heures, et magie magie : +30% de profit affiché. Vous cliquez alors sur Withdraw pour retirer les sous et l'argent vous revient avec le bénéf. Ensuite, la vidéo se termine sur deux phrases qui puent l'arnaque, je trouve : "je vais bientôt supprimer cette vidéo, c'est une chaîne privée" et "contactez-moi sur Telegram".
Et voilà...
Mais alors du coup, qu'est-ce qui se passe réellement ?
Hé bien cette combine porte un nom, elle est documentée, et elle a fait très mal. Les chercheurs de SentinelLABS ont disséqué toute une famille de ces "drainers Ethereum" qui se font passer pour des bots d'arbitrage (les vrais bots MEV existent et sont légitime, justement ce qui rend l'arnaque crédible).
Par exemple, une autre vidéo de la même série, intitulée "How to Create Passive Income MEV Bot on Ethereum" (pas exactement celle que j'ai vue, mais le même mécanisme au détail près), a aspiré près de 245 ethers à des victimes. Au cours de l'époque, ça représentait environ 900 000 dollars. Pas mal hein, pour un "tuto gratuit" sur YouTube ! D'autres campagnes du même genre ont siphonné 7 ETH par-ci, 4 ETH par-là et ces vidéos sont souvent générée par IA, avec la voix robotique à 2 balles, les expressions faciales saccadées, les lèvres désynchronisées et j'en passe...
Maintenant, le cœur de cette arnaque c'est que le code que vous collez dans Remix contient en fait une adresse de portefeuille cachée / obfusquée, qui est celle de l'escroc. Elle n'est pas écrite en clair, sinon n'importe qui la verrait mais est reconstituée lors de l'exécution du code, soit en faisant un XOR entre deux constantes anodines (souvent nommées un truc rassurant genre DexRouter et factory), soit en recollant des morceaux de texte, soit en tronquant un énorme nombre. En clair, l'adresse du voleur est coupée en deux bouts d'apparence inoffensive, planqués à deux endroits différents du code, et recollée seulement au moment où le contrat tourne.
Alors quand le mec dans la vidéo vous dit "regardez les lignes 13 et 14, ce sont vos adresses pour recevoir les tokens WETH", c'est de la diversion pure. Il vous donne tout simplement un os à ronger pour que vous vous sentiez rassuré, pendant que la vraie adresse est planquée ailleurs dans le code.
Et là, le piège se referme car au moment où vous financez le contrat et cliquez sur Start, vos ethers partent directement dans le portefeuille de l'escroc. Pire, SentinelLABS a également relevé un mécanisme de secours qui permet à l'attaquant de vider le contrat même si vous ne cliquez jamais sur Start.
Le "+30% de profit" que vous voyez à l'écran ? Bah c'est du flan... de la poudre de perlimpinpin comme dirait l'autre.... Au mieux c'est un faux solde renvoyé par le contrat, au pire c'est carrément du montage vidéo. D'ailleurs, un contrat déployé tout seul ne peut même pas "sniper" la mempool donc techniquement, ça tient pas car ce genre de chose demande un bot externe qui surveille les transactions en attente. Le contrat seul ne fait rien d'autre que transférer votre argent en fait... C'est juste un siphon avec une jolie interface, rien de plus !
Ce qui rend ce truc redoutable, c'est la psychologie derrière. Remix est un outil réputé, donc votre cerveau associe "outil sérieux" à "code sérieux". Et comme vous déployez le contrat vous-même, il vous semble être le vôtre.
On vous donne aussi cette mini-tâche de "vérification" bidon pour endormir votre méfiance et surtout on vous répète "pas besoin de savoir coder", ce qui veut dire en réalité "surtout ne lisez pas ce que vous collez".
C'est ce genre de phrase-là qui devrait déclencher l'alerte rouge dans votre cerveau ! Sans oublier que le tout est saupoudré de hype IA pour faire moderne... Bref, c'est du grand n'importe quoi, mais ça marche à fond la caisse. Si vous voulez voir comment des malwares se cachent carrément dans la blockchain elle-même, j'avais aussi décortiqué ce que fait la Corée du Nord avec la blockchain . Le mécanisme est différent, mais c'est le même esprit à savoir détourner une techno légitime pour piéger les gens.
Voilà, alors retenez les règles de base, parce qu'elles valent pour cette arnaque comme pour les mille autres qui sortiront demain. Argent facile et passif : si c'est automatique, sans effort et garanti, c'est une arnaque dans la totalité des cas. Et surtout, la vraie question à se poser est toujours la même : Si ce bot rapportait vraiment 2000 dollars par jour, pourquoi un inconnu vous le filerait gratuitement au lieu de s'enrichir tranquillement dans son coin ? Personne n'offre une machine à billets sans contrepartie !
Puis y'a l'urgence : "je supprime la vidéo bientôt", "offre gratuite aujourd'hui", "dépêchez-vous". Ce compte à rebours vise à court-circuiter votre sens critique pour vous empêcher de réfléchir ou de vérifier. C'est un peu ce que font aussi les escrocs au téléphone quand ils vous disent que votre compte bancaire va être bloqué dans 10 min et que vous allez tout perdre...
Et puis filer de l'argent avant de toucher le moindre gain c'est louche aussi ! Sans oublier le fait qu'on vous pousse vers Telegram ou des DM privés, histoire de laisser le moins de traces et de recours possible.
Quand au fameux "Pas besoin de coder", sur un truc qui touche à votre argent, c'est le drapeau rouge ultime !!! Ne déployez jamais, jamais, jamais du code financier sans le comprendre parfaitement ou le faire auditer par quelqu'un de confiance.
Et si vous vous êtes déjà fait avoir ?
À vrai dire, une fois la transaction confirmée sur la blockchain, récupérer l'argent est en pratique quasi impossible, sauf gel rapide côté plateforme ou intervention judiciaire. Mais bon, c'est pas une raison non plus pour rester les bras croisés.
Par exemple, si vous avez signé des autorisations (avec Metamask par exemple) que vous ne compreniez pas, considérez le portefeuille comme grillé et transférez rapidement ce qu'il vous reste vers un portefeuille tout neuf. Vérifiez et révoquez les approbations de tokens accordées au contrat (avec un outil de type revoke.cash), en sachant évidemment que ça ne récupèrera pas les ethers déjà partis. Ça coupe juste une éventuelle ponction qui arriverait plus tard.
Et surtout, gardez les preuves comme les hash de transaction et les adresses, signalez la chaîne YouTube et le compte Telegram, puis déposez un signalement sur cybermalveillance.gouv.fr ou Pharos. Et prévenez les gens autour de vous... c'est exactement le même réflexe à avoir que face à l'arnaque au QR code piégé , une fois le mécanisme compris, on devient beaucoup plus dur à berner.
Bref, ce genre d'escroquerie ne meurt jamais vraiment... elle change juste de costume. Hier l'arbitrage secret, aujourd'hui c'est l'IA qui va vous rendre riche... Le plus important c'est de garder votre cerveau allumé... ça c'est gratuit et ça rapporte vraiment.
Le gouvernement veut-il sacrifier les VPN sur l'autel de la vérification de l'âge ? Face aux menaces sur le télétravail et la sécurité, le député Philippe Latombe somme la ministre de clarifier sa position.
Vous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?
Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.
Allez, petite démonstration récente... Sur le repo no-as-a-service , il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".
Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...
Git, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.
Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.
Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.
Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :
Connexion# 1. Visualiser un commit cible pour récupérer name + email
git log --format='%an <%ae>' | head -3
# 2. Reconfigurer Git avec une fausse identité
git config --global --replace-all user.name "Linus Torvalds"
git config --global --replace-all user.email "[email protected]"
# 3. Vérifier la config
git config --global --list | grep user
# 4. Faire un commit normal
echo "Hello from Linus" >> README.md
git add README.md
git commit -m "Important kernel fix"
# 5. Pousser sur votre repo
git push origin main
Allez voir le commit sur GitHub. Vous verrez l'avatar de Linus, son nom cliquable qui mène vers son profil, et surtout aucun avertissement. Pas de mot de passe demandé ni de token compromis... non, non, non, c'est juste une config locale modifiée.
Et si quelqu'un fait un fork de votre repo, ou si un mainteneur peu attentif valide un PR sur cette base, l'illusion est complète.
Pour ça, le badge Verified reste l'indicateur le plus utile. À côté du SHA d'un commit, GitHub affiche surtout une étiquette verte "Verified" si le commit est cryptographiquement signé avec une clé GPG ou SSH enregistrée sur le compte de l'auteur. Sinon, y'a rien du tout (par défaut). Attention quand même, l'absence de badge ne veut pas dire qu'un commit est malveillant mais juste qu'on ne peut pas garantir qui l'a écrit.
Par exemple, si vous regardez le commit e6b4218 sur no-as-a-service, vous remarquerez l'absence totale de badge. C'est le signal mais il faut encore savoir le chercher car par défaut, GitHub n'affiche AUCUN avertissement pour les commits non signés. C'est surtout ça le problème...
Alors pour vous protéger de ça, ça commence chez vous. Plus simple que GPG, la signature SSH utilise une clé que vous avez probablement déjà. Générez une clé Ed25519 si ce n'est pas fait :
ssh-keygen -t ed25519 -C "[email protected]"
Configurez Git pour signer automatiquement avec cette clé :
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true
Dernière étape, ajoutez votre clé publique sur GitHub dans Settings → SSH and GPG keys (1), mais cette fois en sélectionnant le type Signing Key (pas Authentication Key, c'est différent) (2). Vos prochains commits afficheront le badge "Verified" en vert.
Si vous préférez GPG, le principe est identique avec gpg.format gpg et une clé GPG. Pour le détail GPG complet, j'avais déjà couvert le sujet dans
le tuto sur Thunderbird et GPG
.
Là, on passe à l'offensive. Vigilant Mode (3) force GitHub à afficher un statut sur tous vos commits. Les signés deviennent "Verified", les non signés deviennent "Unverified" en gros et bien visible. Plus de zone grise comme ça.
Direction même endroit dans Settings → SSH and GPG keys → Vigilant mode → Flag unsigned commits as unverified. Cochez la case. À partir de là, n'importe quel commit que GitHub vous attribue (via votre email vérifié) sans signature sera affiché comme "Unverified", ce qui rend le spoofing beaucoup plus difficile à dissimuler. Petite limite par contre, ça ne protège que votre propre identité et pas celle des contributeurs qui n'ont pas activé le mode.
GitHub considère ce comportement comme un non-bug. Sur leur page bug bounty, l'usurpation par email Git est explicitement listée comme ineligible. Leur argument c'est que ça ne donne pas accès aux repos ni de privilèges supplémentaires, donc ce n'est pas une faille au sens strict.
Sauf que dans la vraie vie, l'identité affichée influence les décisions. Par exemple, un mainteneur qui voit un PR signé d'un contributeur connu va l'examiner avec moins de paranoïa, un journaliste qui couvre un scandale va citer "le commit de tel développeur" sans vérifier la signature, et combiné à d'autres vecteurs, ça peut devenir redoutable ! Je pense surtout aux attaques supply chain récentes type Shai-Hulud où une fois le code piégé, l'attribution Git aide à le faire passer pour légitime.
Bref, dire "ce n'est pas un bug" parce qu'il faut un autre vecteur derrière, c'est un peu facile, je trouve. Voilà, donc ne comptez pas sur Github pour vous défendre et signez vos commits, activez Vigilant Mode, et apprenez à vos collègues et amis dev à vérifier le badge "Verified" avant de merger quoi que ce soit en venant d'un inconnu... même si c'est ce bon cher Linus qui propose de réécrire le kernel en Rust avec systemd intégré ^^.
On connaît tous les grands noms des protocoles VPN : WireGuard, OpenVPN, IKEv2 (Surfshark VPN utilise les 3). Ce sont des bêtes solides, mais elles ont au départ été pondues pour des usages pro, avec des armées de serveurs en entreprise et des configs à rallonge. Puis on les a adaptés pour nous, les users lambda qui veulent juste binge-watcher une série sur Netflix ou checker ses mails sur le Wi-Fi crade du troquet du coin, sans se prendre la tête sur les détails techniques. Ça roule, mais c'est pas l'idéal.
Surfshark a dit stop au bricolage. Ils ont tout repris à zéro et lancé Dausos. Pas une énième couche de sauce marketing sur de l'existant, non : une architecture repensée de fond en comble. La promesse ? Vitesse, confidentialité et efficacité des ressources, sans un seul compromis. Et dans un écosystème où les VPN se battent sur le prix et les fonctionnalités cosmétiques, cette approche mérite qu'on s'y penche sérieusement. Je vais vous décortiquer tout ça, point par point, pour que vous pigiez bien ce que ça change concrètement.
Dausos, c'est le tout premier protocole VPN 100% maison chez Surfshark, taillé sur mesure pour les particuliers. Le nom ? Inspiré de la mytho balte, où "Dausos" évoque l'élévation et la protection divine, sympa comme clin d'œil pour un truc qui vous met à l'abri en ligne. L'idée centrale est de créer un tunnel qui colle pile à vos besoins, sans les contraintes des protocoles pros recyclés.
La grosse différence avec les classiques, c'est la gestion du trafic. La plupart des VPN font passer les datas de plein d'utilisateurs via des tunnels partagés sur un même serveur. C'est pratique pour l'opérateur (moins de ressources nécessaires), mais ça crée une surcharge permanente, des interférences potentielles entre sessions et un risque accru si un user foireux impacte les autres. Résultat : des perfs en dent de scie à certains moments et une sécurité des données pas toujours optimale.
Dausos inverse le principe. Chaque connexion (la vôtre) se voit coller un tunnel dédié et 100% isolé sur le serveur. Votre trafic ne croise jamais celui du voisin, même sur un même serveur bondé. Ça réduit les surfaces d'attaque (moins d'expositions aux fuites croisées), optimise les perfs en virant la contention ressource et renforce la confidentialité globale. C'est comme si vous aviez votre propre bande sur l'autoroute VPN, sans camion qui vous colle au cul.
Le protocole brille par ses choix d'implémentation pointus. Pas de demi-mesure ici. D'abord, le chiffrement : exit AES-GCM, la vieille garde fiable, mais datée. Place à AEGIS-256X2, un algo moderne taillé pour les CPUs récents (nouveaux Intel/AMD, Apple Silicon...). Plus rapide en chiffrement/déchiffrement, il bouffe moins de cycles processeur pour un niveau de sécu équivalent. Concrètement ? Votre débit reste au max, même sous charge.
Ensuite, la résilience post-quantique intégrée (voir aussi mon article sur Surfshark et le post-quantique ). Ici ce n'est pas une rustine ajoutée après coup, l'architecture est née quantique-ready. Avec les ordis quantiques qui pointent le bout de leur nez (merci Google et consorts), ça protège vos données sensibles pour les 10-20 ans à venir. Ça pense à l'avance, quoi.
Troisième atout : l'adaptation dynamique. Dausos scanne votre réseau et votre hardware en live et ajuste les paramètres (MTU, compression, etc.) pour coller à la réalité. Fibre optique ? Full perf. Passage en 4G foireuse ou métro ? Stabilisation automatique sans drop. Pas d'interruption visible, juste du smooth.
Et pour la crédibilité l'outil a passé avec succès un audit indépendant par Cure53. Ces gars sont des pointures en sécu (ils ont bossé sur Signal, Proton, etc.) et le rapport est public, dispo pour tous. Pas de blabla, de la preuve béton.
Surfshark balance des chiffres : jusqu'à +30% de vitesse vs protocoles standards. Comme d'hab c'est à nuancer, hein, ça dépend de votre setup, du réseau et du serveur choisi, etc. Sur une fibre stable, c'est perceptible, mais pas fou. Par contre, en mobilité ou réseaux chiants (vacances, events), l'adaptation dynamique fait des miracles. Moins de lag, une connexion plus stable, que demande le peuple ?
tunnel vpn classique
L'isolation trafic ? C'est moins flashy, mais crucial. ça réduit les risques de fuites croisées et d'attaques par corrélation (un attaquant qui matche patterns entre différents utilisateurs). Côté mobile, l'efficacité en termes de ressources sauve un peu plus de batteries. L'optimisation CPU/GPU c'est une autonomie augmentée de 10-20% en VPN constant. Un détail, mais un détail qui change tout en déplacement.
Pour l'instant, Dausos est en bêta exclusive sur macOS via App Store. Pas de date ferme pour iOS/Android/Windows/Linux, mais un rollout progressif est annoncé (logique pour éviter le chaos).
Étapes simples :
Si vous avez la version DMG (non-App Store), désinstallez-la d'abord pour éviter les conflits, Bêta oblige des instabilités sont possibles. Si ça vous arrive, revenez vers WireGuard/OpenVPN en attendant, et signalez le bug au support.
Ce que j'apprécie toujours autant, après des années à l'utiliser, c'est cette cohérence et ce côté proactif à toute épreuve. Surfshark ne fait pas semblant : opter pour des tunnels dédiés par utilisateur, ça coûte un bras en infra serveur (plus de ressources allouées, moins d'optimisation low-cost), mais ça livre du premium pur jus.
L'AEGIS-256X2, c'est du costaud. Ils sortent des rails AES-256-GCM usés jusqu'à la corde, avec un algo qui colle aux CPUs modernes et validé par la crème de la communauté crypto. Vision long-terme aussi avec le post-quantique natif, rare chez les VPN grand public, qui attendent souvent que le problème explose pour patcher à la va-vite.
La limite bêta macOS seulement ? Ouais, frustrant pour les autres plateformes (vous n'avez qu'à avoir du goût), mais malin comme tout. Mieux vaut roder le bestiau sur un terrain contrôlé avant de lâcher les hordes sur iOS, Android ou Windows. Ça évite les bad buzz et les forums en feu.
Est-ce que Dausos seul justifie de plaquer votre VPN actuel pour Surfshark ? Nope, pas encore. Mais pour les geeks qui kiffent l'innovation transparente, sans bullshit marketing, c'est un argument massue. Une vrai killer feature dans un océan de copies carbone.
Bref, à tester ou pas ? Si vous êtes sur macOS, foncez, c'est gratos et rapide à setup. Sur autre chose ? Gardez l'œil ouvert sur les annonces, ce protocole pourrait bien devenir la référence pour les VPN perso d'ici 2-3 ans. La sécurité et les perfs, c'est pas un one-shot, c'est du boulot continu. Dausos en est l'exemple parfait. C'est grâce à ce type d'évolution discrète et solide que Surfshark a su s'imposer et creuser l'écart sur la durée.
Si vous voulez tester Surfshark, sachez qu'un engagement de 24 mois + 3 mois offerts revient à 57,67€ TTC (soit moins de 2,15€/mois). La garantie satisfait ou remboursé de 30 jours vous laisse le temps de vérifier que l'outil correspond à vos besoins. Et l'abonnement protège tous vos appareils, sans limite.
*Transparence : il s'agit d'un lien affilié. Vous payez le même prix, mais une commission me revient si vous passez par là. C'est ce qui me permet de publier ce type de contenu sans recourir aux bannières publicitaires ou aux articles sponsorisés non identifiés. *
Y'a des génies du crime, et puis y'a Peter Stokes, alias Bouquet, 19 ans, presque toutes ses dents, double nationalité américano-estonienne, et surtout membre de Scattered Spider, le collectif qui a déjà plumé MGM et Caesars.
Le mec a tellement bien réussi son coup qu'il est parti se payer des vacances à Tokyo, sauf que pour fêter ça, en bon teubé, il a posté sur Snapchat des selfies de sa grosse tête avec un tout nouveau bijou : un collier en diamants HACK THE PLANET. Comme dans le film de 1995 mais en plus bling bling !
Hé bien grâce à ça, le FBI a fini par le coffrer lors de son escale d'Helsinki.
Bouquet (oui, j'ai pas précisé mais c'est son pseudo) opérait donc dans le groupe Scattered Spider, ce collectif d'ados anglophones qui ne s'embête pas avec des failles zero-day parce que de toute façon, ils ne sauraient pas les utiliser.
À la place, ils ont leur propre méthode super technique vous allez voir... ils appellent le support IT de la cible et embobinent un pauvre mec pour qu'il reset le 2FA d'un admin.
Et voilà comment notre cher Bouquet a pu sortir 100 Go de données d'un revendeur de produits de luxe (la plainte désigne sobrement la "Company F", mais ça pue Harrods d'après la presse anglaise) en seulement quelques heures, réclamé 8 millions de rançon, et causé plus de 2 millions de dégâts.
Du coup, plainte fédérale à Chicago, 6 chefs (wire fraud, conspiracy, computer intrusion comme ils disent là-bas avec l'accent cowboy), + extradition vers les USA en cours. C'est le bouquet final pour lui ! (Oui, jeu de mots, roh roh roh).
Tyler Buchanan, 24 ans, autre membre du club, a de son côté déjà plaidé coupable d'avoir empoché 8 millions en crypto via du SMS phishing. Faut dire qu'en 2024, le groupe envoyait fièrement des messages genre "Fuck off, FBI" aux agents fédéraux qui enquêtaient sur eux.
Très rebelles nos kikoulool ! Enfin, comme vous le savez, qui fait le malin tombe dans le ravin, et qui fait le mariole avec un collier finit avec des bracelets ^^. (J'ai pas trouvé mieux, déso... lol)
Bref, Bouquet vient à lui seul d'écrire le chapitre 1 du manuel "Comment ne PAS être un cybercriminel à succès" et dont la règle n°1 est : "Si t'es recherché par le FBI, ne montre pas ton butin sur Snapchat"
Depuis quelques jours, plusieurs médias français ressortent cette merveilleuse histoire de la carte bancaire à empreinte digitale comme s'il s'agissait d'une révolution imminente ! Par exemple l'Indépendant titre carrément "le code à quatre chiffres c'est bientôt fini". Toudoum !!
Sauf que la techno, conçue par Thales et IDEMIA , est commercialisée en Europe depuis 2021 quand même. Et plus drôle encore, c'est que BNP Paribas a fermé la commercialisation de sa première version le 8 décembre 2025, soit bien avant que la presse en fasse un sujet d'actualité "frais".
La carte F.CODE d'IDEMIA, l'un des deux principaux fabricants de cartes biométriques en Europe avec Thales (crédit : IDEMIA).
Donc bon, on va remettre les pendules à l'heure ensemble, parce que le sujet mérite mieux qu'un communiqué de presse recopié à la chaîne par dix rédactions. Je vous propose donc de remettre un peu tout ça à plat parce que je lis quand même pas mal de conneries.
Tout d'abord, il faut savoir que le principe technique derrière ces CB est solide, faut le reconnaître. Vous posez le pouce sur un petit capteur de quelques millimètres intégré à la carte, le module Secure Element (l'équivalent du coffre-fort embarqué) compare l'empreinte au gabarit stocké dans la puce, et si ça matche, le paiement passe en moins d'une seconde !
Le mot-clé c'est d'ailleurs "match-on-card". Cela veut dire que la comparaison se fait localement, et donc que l'empreinte ne sort jamais de la carte, ni vers le commerçant, ni vers la banque, ni vers un serveur quelque part. C'est donc exactement le même délire que Touch ID ou Face ID chez Apple, et c'est ce qui distingue ce système d'une base biométrique centralisée façon ANT, dont on a vu cette année à quel point ça pouvait mal finir (looool).
Côté sécurité, y'a beaucoup de vrais points positifs. Le code PIN à quatre chiffres, c'est dix mille combinaisons. Avec un peu de skimming sur un terminal compromis et une caméra cachée au-dessus du clavier, vous pouvez tout récupérer encore plus facilement. Sans parler des PIN type 1234, 0000 ou date de naissance qui représentent une part énorme des codes en circulation selon les analyses de DataGenetics (1234 représente à lui seul environ 10,7% des PIN observés sur 3,4 millions de codes analysés).
La biométrie vient donc tuer ce vecteur d'attaque d'un coup. Ainsi, si quelqu'un vole votre carte, il ne peut rien en faire, en théorie, sans votre doigt. Faudra avoir un bon sécateur ^^. Et niveau conformité, ça rentre pile-poil dans le cadre PSD2 et l'authentification forte du client puisque la biométrie remplace le facteur "savoir" (le PIN) par un facteur "inhérence" (votre corps), ce qui valide les deux facteurs requis avec la possession de la carte. Une fois encore c'est comme avec l'iPhone et FaceID / TouchID quand on se connecte quelque part.
Sauf que voilà, c'est là que les médias arrêtent de creuser. Et y'a beaucoup de choses à creuser, croyez-moi ! Perso je trouve ça assez "gênant" (comme disent les zados... "Annnnh la génance !!") qu'on nous présente un sujet sécurité aussi important comme si on nous vendait des yaourts.
Parce que d'abord, le code PIN ne disparaît pas, sauf si vous avez la chance d'avoir une banque qui vous laisse le désactiver explicitement (et bonne chance pour trouver l'option dans les CGV). Hé oui, quasi toutes les implémentations que j'ai pu voir passer, gardent un bon gros fallback PIN pour les cas où le capteur foire (doigt mouillé, sale (sacré lulu), blessure, capteur défaillant) ou pour les retraits au DAB.
Or, vous le savez parce que vous avez Bac+18 en bon sens, la sécurité globale d'un système est celle de son maillon le plus faible. Donc si le code PIN reste en backup, vous n'avez pas supprimé le maillon faible mais vous l'avez juste rendu optionnel. Et donc un voleur qui sait ça, sera capable de forcer le fallback en simulant un échec biométrique et utiliser le code PIN pour peu qu'il le connaisse. Comme avant quoi...
Donc cette promesse "fin du code à 4 chiffres" est donc un bon gros raccourci marketing, et pas du tout une réalité technique.
Ensuite, autre souci, c'est que la biométrie n'est pas révocable. Donc si demain un labo ou un expert sécu arrive à extraire un gabarit d'empreinte d'un Secure Element compromis (ça s'est déjà vu sur des puces certifiées EAL5+ par attaques side-channel), vous ne pourrez pas changer votre doigt parce que j'sais pas si vous avez remarqué mais il est bien solidement attaché au sac de viande que vous appelez "Mon summer body" ^^.
Le risque est heureusement limité dans ce cas-ci parce que le gabarit reste sur la carte, mais structurellement, la donnée biométrique EST un mot de passe que vous ne pouvez jamais changer. C'est une contrepartie importante que personne ne mentionne dans les articles grand public.
Sur les attaques physiques par exemple, le Chaos Computer Club qu'on connaît tous, a démontré dès 2013 le bypass de Touch ID avec un moulage en latex fabriqué à partir d'une empreinte laissée sur un verre. Les capteurs intégrés dans une carte bancaire sont plus petits, moins denses en pixels, et n'ont pas la même puissance de calcul pour faire tourner des modèles anti-spoof avancés que ce qui est embarqué dans un iPhone.
Ils sont donc plausiblement PLUS contournables, donc j'imagine qu'un moulage en silicone ou en résine pourra facilement en venir à bout. À ma connaissance, y'a aucun chiffre public sérieux qui n'a été publié par les fabricants sur le taux de succès de ces attaques sur leurs cartes. Comme c'est pratique ;)
Le sujet de la mise sous pression par des affreux bandits, mérite aussi une mention. Parce qu'avec un code PIN, si on vous menace devant un DAB, vous pouvez théoriquement saisir un faux code (certaines cartes ont même une notion de " code sous contrainte " qui bloque la carte directement). Alors qu'avec un doigt, on vous chope la main et force et voilà...
La jurisprudence américaine est d'ailleurs intéressante là-dessus puisqu'un juge peut vous obliger à poser le doigt sur un TouchID, mais pas à donner votre code PIN par respect du 5e amendement. En France le débat est un peu différent mais analogue. C'est un petit détail légal mais personne ne l'aborde non plus pour tout ce qui est sécurité biométrique en général.
L'enrôlement à domicile via smartphone, vendu comme "sécurisé" mais dont le protocole détaillé reste opaque (crédit : IDEMIA).
Autre angle mort, l'enrôlement. En effet, aucun des articles que j'ai lus ne décrit exactement comment l'empreinte arrive dans la puce la première fois. Est-ce que ça se fait en agence, avec un lecteur dédié ? Via une app smartphone qui pousse le gabarit par NFC ?
On en sait rien, mais si c'est la seconde option, le pipeline app + carte est une surface d'attaque qui mérite un audit indépendant, et la promesse de "l'empreinte ne quitte jamais la carte" devient à géométrie variable. Côté Thales et IDEMIA, le marketing parle d'enrôlement à domicile sécurisé, mais les détails du protocole sont peu documentés, tout du moins ce que j'ai pu trouver en libre accès.
Et pour finir sur le côté pratique, la biométrie est une option payante. Bah ouais, 24 balles par an chez BNP et Crédit Agricole, sur des cartes Visa Premier ou Mastercard Gold qui coûtent déjà entre 130 et 180€ annuels, pourquoi se faire chier ? Société Générale a annoncé vouloir descendre en gamme là-dessus, mais pour l'instant, la sécurité forte est réservée à ceux qui peuvent payer. Sécurité à deux vitesses, donc, comme d'hab et moi je trouve que c'est un peu paradoxal pour un truc présenté comme la nouvelle norme.
Bref, mon verdict sur tout ça c'est que le design technique est bon, le match-on-card protège VRAIMENT des fuites massives, et ça c'est un excellent progrès face au PIN à 4 chiffres pour tout ce qui est usage courant. Mais le narratif "fin du code secret" reste faux puisque le PIN perdure en fallback, et surtout, la biométrie pose des problèmes structurels bien connus (non-révocable, vulnérable aux moulages, coercition, enrôlement opaque).
Donc voilà, si demain votre banque vous propose le passage au biométrique, demandez-lui comment se passe l'enrôlement, si le fallback PIN est désactivable, et combien ça coûte. Et peut-être que là, ça pourra être intéressant.
Si vous tournez sur Ubuntu, Debian, Fedora ou RockyLinux, sachez que votre démon PackageKit a passé presque 12 ans à laisser une porte ouverte vers votre compte root. La Deutsche Telekom Red Team vient en effet de publier Pack2theRoot (CVE-2026-41651), une faille notée 8.8/10 qui permet à n'importe quel utilisateur local de devenir root sans mot de passe.
Pour corriger le soucis, mettez à jour vers PackageKit 1.3.5 ou le backport de votre distro. Pour vérifier votre version, c'est dpkg -l | grep -i packagekit sous Debian/Ubuntu, ou rpm -qa | grep -i packagekit côté Fedora et Rocky. Si vous êtes en 1.3.4 ou en dessous, considérez la machine comme exploitable.
Le bug est une race condition classique. En fait PackageKit vérifie vos droits, valide la transaction, mais utilise des données qui ont eu le temps de changer entre les deux. Un appel pkcon install bien chronométré et n'importe quel paquet s'installe en root, sans prompt
Polkit
. La liste des distros confirmées vulnérables couvre Ubuntu 18.04 à 26.04, Debian Trixie, RockyLinux 10.1, Fedora 43 et tout RHEL avec Cockpit.
Le détail marrant encore une fois c'est la méthode de découverte. La Telekom Red Team a tout simplement dirigé Claude Opus d' Anthropic vers la base de code de PackageKit, et c'est cette session d'audit assistée par IA qui a sorti la vuln. Les LLM commencent donc à trouver des bugs subtils que les audits humains ont laissé passer pendant plus d'une décennie. Tant mieux, ça va faire grimper le niveau de sécurité de nombreux projets !
Cette faille ancienne me rappelle BitPixie et son contournement de BitLocker resté en sommeil durant 20 ans. Le pattern est toujours le même, à savoir un composant système installé partout, qui cache un bug tout bête depuis siiii longtemps que plus personne ne l'audite avec un œil neuf.
Bref, merci Claude ^^
