Un logiciel malveillant destiné à effacer définitivement les données de postes informatiques vient de faire surface dans le secteur énergétique vénézuélien.
La bête a été baptisée "Lotus" par les chercheurs de Kaspersky qui l'ont analysé en premier, il a été mise en route en décembre 2025 depuis un ordinateur vénézuélien, et sa cible principale semble être PDVSA, la compagnie pétrolière d'État.
Côté technique, Lotus ne fait pas dans la dentelle. Deux scripts batch préparatoires, OhSyncNow.bat et notesreg.bat, désactivent toutes les défenses, coupent les comptes utilisateurs et ferment les interfaces réseau, histoire de bien tout bloquer.
Ensuite, le binaire principal passe en mode destruction avec diskpart, robocopy et fsutil pour manipuler le système de fichiers, puis descend au niveau IOCTL pour écraser directement des secteurs physiques du disque. Les points de restauration sont supprimés, le journal USN est effacé. Aucune récupération possible.
LKaspersky ne pointe personne, et aucun élément technique ne désigne un État ou un groupe criminel en particulier. Le timing est quand même troublant : fin 2025 et début 2026, le Venezuela a traversé une crise politique majeure avec la capture de l'ancien président Nicolás Maduro le 3 janvier, et les tensions toujours fortes autour des infrastructures énergétiques. Coïncidence ou coordination, on ne saura probablement pas avant longtemps.
En pratique, un wiper qui cible PDVSA, ça rappelle immédiatement les attaques contre les infrastructures critiques qu'on a vues en Ukraine avec Stryker ou contre des clusters Kubernetes avec la variante TeamPCP.
L'objectif n'est pas le chantage ni le vol, c'est la destruction pure. Les opérateurs ne cherchent pas à exfiltrer quelque chose, ils veulent rendre l'infrastructure inutilisable le plus vite possible, pour déstabiliser ou punir.
Un réseau d'alimentation électrique ou de distribution de carburant paralysé quelques jours, ça a des conséquences directes sur la vie quotidienne et sur la stabilité politique d'un régime.
Ce qui inquiète, c'est aussi la qualité du code. Lotus n'est pas un script amateur collé à la va-vite : il enchaîne plusieurs étapes de sabotage méthodique, de la désactivation des défenses à la destruction bas niveau du disque.
Pour un pays qui n'a déjà pas la réputation d'avoir la cybersécurité la plus pointue du continent, encaisser ce genre d'outil, ça fait mal. Et la probabilité que d'autres échantillons du même auteur circulent déjà ailleurs est loin d'être nulle.
Bref, un wiper bien fichu sur une compagnie pétrolière d'État dans un pays en crise, c'est rarement l'œuvre d'un adolescent dans son garage. Affaire à suivre donc.
Source : Bleeping Computer
Vous voulez comprendre ce qui se passe dans le cerveau de votre bagnole ? Hé bien pour cela avant, il fallait du matos pro et des suites logicielles à licence annuelle. Mais maintenant, y'a CANviz .
Un pip install canviz, un module USB à quelques balles branché sur le bus CAN de la voiture, et hop, vous accédez à tous les secrets de votre voiture simplement en ouvrant votre navigateur sur localhost:8080. Toutes les trames qui circulent sur le réseau interne du véhicule s'affichent en direct dans un tableau qui défile sans ramer à 2000 fps si j'en crois le README, donc ça envoie !
Ce projet signé Chanchal Dhiman tourne sur n'importe quelle config équipée de Python 3.10 ou supérieur, et côté matériel, CANviz se branche sur plein de bazars tels que les modules à firmware Candlelight (genre FYSETC UCAN autour de 8 balles ou CANable 1.0 autour de 15), les périphériques slcan via port COM, et du matériel sérieux type PEAK PCAN-USB, Kvaser, Vector ou même socketcan sur Raspberry Pi. En gros, si votre clé USB CAN est compatible avec python-can, CANviz la gère !
L'interface décode alors les fichiers DBC (le format de base de données du CAN), donc au lieu de lire des paquets hexadécimaux chelous, vous voyez directement "vitesse moteur = 1450 rpm" ou "position accélérateur = 34%". Vous pouvez aussi filtrer par ID ou par nom de signal, et le filtre se garde dans l'URL. Comme ça, vous pouvez partager une vue à un pote en copiant simplement le lien.
Le truc vraiment pratique, c'est surtout la partie enregistrement. Vous capturez une session en .asc ou .csv, et vous la rejouez plus tard à vitesse variable (de 0.5x pour décortiquer lentement, jusqu'à 10x pour survoler), ou vous forgez vos propres trames depuis l'interface pour tester la réaction d'un module donné. Une API REST et du WebSocket ouvrent aussi la porte aux bricolages en Python, avec une doc interactive accessible sur /docs.
Autre truc malin, vu que c'est un serveur web derrière : vous pouvez déployer CANviz sur un Raspberry Pi planqué dans la bagnole et le consulter à distance en SSH. Par contre, pas de WebUSB ici. L'auteur a explicitement fait le choix de passer par python-can côté serveur pour des raisons de sécurité. L'accès USB reste donc dans le sandbox Python, et le browser ne touche rien. J'avoue, je préfère.
Le projet est sous licence MIT, et est encore jeune, mais l'approche est éprouvée. Pour ceux qui cherchent des alternatives desktop, y'a bien sûr CANgaroo côté Qt, ou SavvyCAN qui tourne aussi en natif. Et si vous voulez bidouiller votre voiture comme Charlie Miller l'a fait avec la Jeep , y'a toujours le Panda de Comma sorti en 2017 avec son soft Cabana.
Bref, pour quelques euros de module USB et un pip install des familles, vous pouvez transformer votre laptop en analyseur CAN niveau pro et ça c'est plutôt classe !
Apple a publié hier une mise à jour iOS qui ferme une faille utilisée par les forces de l'ordre américaines pour récupérer des messages supprimés dans des applications comme Signal.
La faille concernait la base de données des notifications : quand vous supprimiez un message dans l'appli, la version cachée dans le cache des notifications pouvait rester accessible jusqu'à un mois.
Concrètement, un message Signal effacé côté appli restait lisible par quiconque avait la main sur le téléphone et savait fouiller au bon endroit.
Le FBI, selon les documents repérés par 404 Media début avril, a utilisé cette faiblesse sur plusieurs affaires pour remonter des conversations pourtant explicitement effacées par les utilisateurs, y compris celles utilisant la fonction messages éphémères.
Apple a reconnu le problème, mais si ça a été fait avec les pincettes habituelle, avec une phrase du genre... "les notifications marquées pour suppression pouvaient être conservées sur l'appareil de manière inattendue", ce qui ne veut pas dire grand chose, ou au contraire, tout dire...
Dit plus simplement, il y avait un écart entre ce que l'utilisateur voyait disparaître et ce qui restait réellement sur le disque. Le patch a été rétroporté sur les anciennes versions d'iOS 18, ce qui suggère que la faille existait depuis un bon moment et a probablement été exploitée dans des affaires que l'on ne connaîtra jamais.
Meredith Whittaker, présidente de Signal a rappelé publiquement que les notifications pour des messages effacés ne devraient jamais rester dans la base de notifications d'un OS. C'est une évidence technique. Sauf que dans la pratique, la chaîne cache des notifications plus indexation iOS laisse des traces que les outils forensiques comme Cellebrite ou GrayKey savent exploiter depuis des années.
Le problème dépasse Signal. Toute application qui envoie une notification contenant le texte d'un message entier sur iOS pouvait voir ses contenus persistés dans le cache, même après un effacement explicite. Du coup, pour les journalistes, les avocats, les activistes ou simplement les gens qui tiennent à leur vie privée, mettre à jour le plus vite possible n'est pas une option mais une priorité.
Bref, quand on parle de messagerie chiffrée, la vraie surface d'attaque n'est plus le protocole mais tout ce que l'OS fait autour dans votre dos.
Source : The Hacker News
Depuis la version 2.91.0 du CLI GitHub publiée mardi, chaque commande que vous tapez dans gh envoie des données de télémétrie vers GitHub par défaut. L'activation est silencieuse, sans message au premier lancement, sans consentement explicite, et il faut fouiller dans la doc pour tomber sur la page dédiée au sujet.
GitHub décrit la collecte comme pseudonyme côté client. Concrètement, le payload embarque le nom de la commande lancée, un identifiant d'invocation, un identifiant d'appareil, l'OS, l'architecture, l'agent et quelques drapeaux.
L'entreprise précise que le contenu exact peut varier d'un appel à l'autre. La justification officielle : les équipes produit ont besoin de voir comment le CLI est utilisé, avec la montée en puissance des agents IA qui le pilotent de plus en plus souvent en arrière-plan.
Côté sortie, il y a trois moyens de couper la télémétrie. Vous pouvez définir la variable d'environnement GH_TELEMETRY à false, ou DO_NOT_TRACK à true, ou lancer gh config set telemetry disabled. Simple en apparence.
Sauf que rien de tout ça n'est signalé à l'installation, et qu'un utilisateur qui n'est pas tombé sur le billet de Brandon Vigliarolo dans The Register ne saura probablement pas que c'est activé sur sa machine.
Le terme pseudonyme mérite aussi qu'on le regarde de près. Pseudonyme ne veut pas dire anonyme : il y a un identifiant d'appareil stable, il y a un identifiant d'invocation, et GitHub connaît déjà votre compte si vous êtes authentifié avec gh auth login.
Du coup, le recoupement entre votre activité CLI et votre identité GitHub n'a rien de théorique, même si GitHub ne promet pas de le faire.
En pratique, la télémétrie des outils de dev n'est pas une nouveauté. VS Code le fait depuis des années, npm aussi, et la plupart des éditeurs jouent le même jeu. Ce qui coince ici, c'est le choix de l'opt-out plutôt que de l'opt-in, et l'absence d'annonce claire sur le changelog principal.
Les utilisateurs reprochent surtout à GitHub d'avoir glissé l'info dans une page de doc au lieu d'un billet de blog dédié. Pour un outil qu'utilisent des gens très à cheval sur leur vie privée, c'est un drôle de calcul.
Bref, un outil CLI qui s'active en mode collecte par défaut sans prévenir, ça pique. Heureusement une variable d'environnement suffit à couper. Mais il faut savoir qu'elle existe.
Source : The Register
360 Digital Security, la filiale cybersécurité du géant chinois Qihoo 360, revendique environ mille vulnérabilités inédites déterrées par un agent IA maison baptisé Vulnerability Discovery Agent.
L'annonce, faite le 22 avril, cite nommément Microsoft Office et le framework open source OpenClaw parmi les logiciels touchés. Le chiffre est donné sur un seul cycle de campagne.
Mille failles non documentées en un seul cycle de recherche, ça fait un peu tourner la tête. Ce type d'agent fonctionne en boucle pour scanner massivement les bases de code, trier ce qui est potentiellement exploitable, et valider les candidats avant publication interne.
Plus tôt dans l'année, 360 avait déjà présenté un autre outil dédié à la construction automatisée de chaînes d'exploitation. L'un déterre les failles, l'autre fabrique le code qui les utilise.
Mis bout à bout, ça donne une ligne de production offensive entièrement pilotée par IA, que l'équipe 360 décrit comme une réponse directe au projet Mythos d'Anthropic, qui fait le même pari côté occidental mais en mode défense.
Le vrai souci, c'est le devenir de ces 1 000 failles. Si toutes ont été remontées aux éditeurs concernés, tant mieux. 360 affirme d'ailleurs avoir utilisé les canaux de divulgation responsables, mais sans publier de calendrier de patch.
Sauf que l'entreprise est connue pour ses liens étroits avec le ministère chinois de la Sécurité d'État, et plusieurs de ses chercheurs ont déjà été soupçonnés par le passé de garder pour l'État ce qu'ils trouvaient. Du coup, l'annonce met les équipes de sécurité occidentales quelque peu en alerte.
Microsoft, qui patche Office tous les mois pour des failles trouvées à la main, va probablement devoir accélérer le rythme si ce genre de scan industriel se généralise. En pratique, la chasse aux vulnérabilités est en train de changer d'échelle.
On passe de quelques failles trouvées par un chercheur humain sur plusieurs semaines à un agent qui en déniche des centaines en quelques jours. Et la logique économique derrière est folle : un seul opérateur bien outillé peut désormais couvrir ce qu'il fallait avant à une équipe complète.
Bref, le mur est tombé côté IA offensive. Et les éditeurs qui patchent à la main ont un vrai problème de cadence face à un scan automatisé à cette échelle.
Source : Bloomberg
L'informatique quantique n'est plus un sujet de science-fiction (mais ça, vous le savez, je vous bassine avec ça depuis des années maintenant). Mais les progrès récents laissent penser que des machines capables de casser certains chiffrements actuels pourraient émerger dans les 10 à 15 prochaines années (voir 5 selon les plus optimistes). Ce n'est pas pour demain matin, mais en sécurité, attendre que la menace soit là pour agir, c'est déjà avoir perdu.
Surfshark a commencé à déployer une protection post-quantique sur son infrastructure WireGuard. Pas en mode "feature marketing", plutôt comme une évolution technique nécessaire. Qu'est-ce que ça change pour vous et pourquoi c'est une bonne nouvelle même si vous n'êtes pas cryptographe ?
Pour comprendre l'enjeu, il faut revenir deux minutes sur le fonctionnement du chiffrement moderne. La plupart des protocoles de sécurité actuels, comme RSA ou ECC, reposent sur des problèmes mathématiques difficiles à résoudre pour un ordinateur classique. Factoriser de très grands nombres, par exemple.
Un ordinateur quantique suffisamment puissant pourrait résoudre ces problèmes beaucoup plus rapidement, rendant obsolètes les méthodes de chiffrement actuelles. C'est ce qu'on appelle la menace "harvest now, decrypt later" ou des acteurs malveillants peuvent déjà intercepter et stocker des données chiffrées aujourd'hui, en attendant de pouvoir les déchiffrer demain quand la technologie quantique sera mature.
Le chiffrement post-quantique désigne donc une nouvelle génération d'algorithmes conçus pour résister à la fois aux attaques classiques et quantiques. Ces algorithmes reposent sur des problèmes mathématiques différents, comme les réseaux euclidiens ou les codes correcteurs d'erreurs, qui restent difficiles même pour un ordinateur quantique.
L'enjeu n'est pas immédiat pour l'utilisateur moyen comme vous et moi. Mais pour des données sensibles qui doivent rester confidentielles pendant des années, la transition doit commencer maintenant.
Un angle souvent négligé dans le débat post-quantique c'est son l'articulation avec l'intelligence artificielle. L'IA générative accélère déjà la découverte de vulnérabilités, la génération de code malveillant adaptatif, ou la personnalisation d'attaques. Combinée à terme avec des capacités de calcul quantique, elle pourrait permettre d'identifier plus rapidement les faiblesses d'implémentation, même dans des algorithmes théoriquement résistants.
Autrement dit, la menace n'est pas seulement "l'ordinateur quantique casse tout". C'est plutôt "l'IA optimise l'attaque, le quantique accélère l'exécution". Les deux technologies se renforcent mutuellement.
C'est pour cette raison que les fournisseurs de sécurité sérieux anticipent. Pas par alarmisme, mais par pragmatisme parce que migrer vers du post-quantique ça prend du temps. Il faut tester la compatibilité, valider les performances, former les équipes, etc. Mieux vaut commencer maintenant que dans l'urgence (l'urgence c'est pour sa déclaration d'impôts chaque année et c'est déjà bien suffisant).
Surfshark a annoncé le déploiement d'une protection post-quantique sur son implémentation de WireGuard. Voici ce qu'il faut retenir :
La solution repose sur une approche hybride. Le tunnel VPN utilise à la fois un algorithme classique (X25519) et un algorithme post-quantique (Kyber-768). Comme ça, même si l'un des deux venait à être compromis, l'autre maintient la confidentialité. C'est une stratégie de défense en profondeur appliquée au chiffrement lui-même.
Cette protection est déjà disponible sur macOS, Linux et Android, avec un déploiement progressif sur les autres plateformes. L'activation se fait côté serveur, sans intervention requise de l'utilisateur. Si votre client supporte la fonctionnalité, elle s'applique automatiquement.
Surfshark précise que cette implémentation suit les recommandations du NIST et de la communauté cryptographique internationale. Les algorithmes sélectionnés ont été soumis à un processus d'évaluation public, et leur intégration a fait l'objet de tests de performance pour éviter de dégrader l'expérience utilisateur.
Enfin, l'éditeur indique que cette évolution s'inscrit dans une feuille de route plus large qui comprend déjà des audits réguliers, les mises à jour des protocoles et la veille cryptographique active. Le post-quantique n'est pas un argument commercial isolé, mais une pièce d'une stratégie technique cohérente.
Le déploiement du post-quantique chez Surfshark est une bonne nouvelle, mais cela ne règle pas tous les problèmes de sécurité. D'abord, la protection ne concerne que le tunnel VPN. Elle ne protège pas contre le fingerprinting navigateur, les fuites DNS mal configurées, ou les compromissions de compte par phishing. Un VPN post-quantique ne compense pas une hygiène numérique défaillante.
Ensuite, la transition est progressive. Tous les serveurs ne sont pas encore équipés, et tous les clients ne supportent pas la fonctionnalité. Si vous avez besoin de cette protection pour un usage professionnel sensible, vérifiez la compatibilité de votre configuration avant de compter dessus (dans les paramètres de l'app, allez dans Paramètres VPN > Protocole et sélectionnez Wireguard).
Et enfin, le post-quantique reste un domaine en évolution. Les algorithmes sélectionnés aujourd'hui pourraient être révisés demain à la lumière de nouvelles recherches. La veille technique reste indispensable, même pour les fournisseurs les plus sérieux.
Ce qui me convainc dans l'approche de Surfshark, c'est le timing et la méthode. Le timing d'abord. Agir maintenant, alors que la menace quantique n'est pas encore immédiate pour la majorité des utilisateurs c'est plutôt bien vu. C'est exactement ce qu'on attend d'un fournisseur de sécurité, anticiper plutôt que réagir. Parce que réagir c'est déjà être en retard.
La méthode se passe sous forme d'implémentation hybride, progressive, basée sur des standards ouverts et validés par la communauté. Pas de solution maison non auditée, pas de promesse "quantum-proof" absolue. Juste une évolution technique raisonnée. Le chiffrement post-quantique n'est pas une fonctionnalité que vous verrez au quotidien. Elle travaille en arrière-plan, sans notification, sans badge "activé". Mais c'est précisément ce genre d'évolution discrète qui fait la différence entre un service qui suit les bonnes pratiques et un service qui les définit.
Est-ce que cela justifie à lui seul de choisir Surfshark ? Probablement pas. Mais si vous cherchez un VPN qui intègre une réflexion long terme sur la cryptographie, sans sacrifier la simplicité d'usage, c'est un argument supplémentaire en sa faveur. Si vous hésitez à franchir le pas, sachez que l'éditeur fait partie des premiers à déployer ce type de protection à grande échelle.
Surfshark fête son anniversaire, et comme souvent avec les bons plans du web, c'est vous qui touchez le vrai cadeau ! Le forfait Starter tombe à 1,78 €/mois sur 2 ans + 3 mois offerts (57,67 € pour 27 mois, soit 2,13 €/mois TTC). La promo est valable du 20 avril au 11 mai. À ce tarif-là, difficile de trouver une excuse pour continuer à laisser son trafic traîner en clair sur Internet.
Note : ce lien est affilié. Cela ne change rien pour vous, mais cela me permet de continuer à produire ce type de contenu sans dépendre de la publicité intrusive.
pgAdmin, l'outil "officiel" pour administrer vos bases PostgreSQL, c'est le type d'interface qu'on n'a pas vraiment envie d'ouvrir un lundi matin ! C'est lent, c'est cheum de ouf en mode figé dans les années 2000 et ça rame sérieusement dès qu'on tente un export un peu costaud. Alors oui je sais, DBeaver, c'est plus joli, mais faut se coltiner Java et un workspace qui traîne au démarrage.
Du coup quand bbDump est passé sur mon radar, j'ai eu envie de creuser un peu. C'est un gestionnaire PostgreSQL moderne, en Electron + Vue + TypeScript, signé par Poups, un dev indé français. L'outil reprend tout ce que vous faites habituellement en CLI (pg_dump, pg_restore, coups d'œil aux tables, schéma de la DB) et met ça dans une interface vraiment propre.
Le dashboard bbDump, tout de suite plus respirable que pgAdmin
Côté fonctionnalités classiques, vous avez ce qu'on attend d'un client PostgreSQL correct. Gestion multi-bases organisée par projet, backups avec liste, restauration, filtre par base, tailles et dates. De leur côté, les tâches planifiées via expressions cron sont configurables par base, et il y a même une visionneuse de logs en temps réel qui trace chaque opération pg_dump.
Ajoutez à ça un navigateur de tables avec édition inline (avec support complet des types), un constructeur de requêtes SQL visuel en plus de l'éditeur brut, l'export CSV, et un diagramme entité-relation interactif via Vue Flow pour visualiser les tables et les clés étrangères. Grâce à bbDump, plus besoin d'aller chercher un outil externe pour comprendre une base héritée d'un projet qui traîne !!
Le schema visualizer en mode ERD interactif, pratique pour décortiquer une base héritée
Mais le vrai twist, c'est l'intégration du MCP (Model Context Protocol) puisque bbDump expose 31 outils MCP aux agents IA, ce qui veut dire que votre Claude d'amour ou votre LLM peut interroger la DB, regarder un schéma, tester une requête. Et comme les mutations passent par un système de confirmation, pas de DROP TABLE à l'insu de votre plein gré !
Je vous avais déjà parlé de cette approche avec Ghidra MCP côté reverse engineering et BrowserWing côté automatisation navigateur. bbDump rejoint donc la famille côté backend de données.
Autre détail sympa, le dev a pensé à la sécurité puisque les backups sont chiffrés en AES-256-GCM, donc si vous synchronisez vos dumps sur un cloud random, pas de panique sur les données sensibles. Sur macOS, y'a même une mini-app menu bar pour accéder aux bases et aux connexions proxy sans ouvrir l'app complète.
Côté installation, c'est facile :
Connexion
curl -fsSL https://poups.dev/bbdump.sh | bash
sur macOS et Linux (qui reste en beta). Bien sûr, si balancer un script dans bash direct vous fait tiquer (normal), vous pouvez aussi chopper le DMG ou l'AppImage en release sur GitHub et inspecter avant. Le code est sous licence MIT, avec une doc dédiée et une page Ko-fi si vous voulez soutenir le projet. Par contre, rien pour Windows pour l'instant.
Le projet est encore tout jeune puisque sorti fin mars de cette année donc si vous cherchez un outil ultra-stable pour une prod critique, attendez un peu. Mais pour vos projets perso, votre dev local, ou juste pour arrêter de râler sur pgAdmin, ça vaut clairement le coup d'œil.
Bref, un dev français de talent qui se lance en indé sur un créneau pourri d'outils vieillots, avec une vision cohérente et une intégration MCP propre, moi j'aime bien. Je pense que Poups mérite d'être soutenu sur ce coup-là, d'où mon article !
Bon, les amis, si vous utilisez Tor Browser pour faire du sérieux, faut que vous sachiez un truc. Le bouton "New Identity", censé vous donner une nouvelle identité vierge à chaque clic... bah il laissait filer, jusqu'à il y a peu de temps, un identifiant stable tant que Firefox tournait.
Deux chercheurs de Fingerprint ont en effet trouvé comment une fonction toute bête du navigateur se transformait en empreinte unique de votre browser, partagée entre tous les sites que vous visitiez.
Il faut donc dès à présent faire la mise à jour vers Firefox 150 ou l'ESR 140.10.0 (la version long-terme utilisée par Tor Browser), ainsi que la dernière version de Tor Browser qui récupère le patch. Si vous voulez en savoir plus, la CVE c'est CVE-2026-6770 , classé comme sévérité modérée par Mozilla.
Le truc marche en vase clos mais traverse les murs.
Mais avant, IndexedDB c'est quoi ?
En gros c'est une mini-base de données que les sites web peuvent créer dans votre navigateur, pour stocker des trucs en local (du cache, des données offline, l'état d'une app web). Chaque site peut y ranger plusieurs bases nommées, et une petite fonction JavaScript indexedDB.databases() permet au site de demander la liste de ses bases.
Rien de foufou sur le papier. Sauf que dans Firefox en navigation privée, le navigateur renomme en coulisse chaque base avec un identifiant aléatoire (UUID), et range tout ça dans une seule grosse table interne. Et le gros problème, c'est que cette table est partagée entre tous les sites ouverts, et pas cloisonnée site par site.
Et là, ça devient croustillant puisque quand un site redemande la liste de ses bases, Firefox la renvoie sans la trier, dans un ordre qui dépend de la structure interne de cette table partagée. Du coup, deux sites totalement différents qui créent chacun seize bases dans le même ordre récupèrent exactement la même suite en retour. Pas l'ordre de création donc mais une permutation bizarre, genre g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k.
Je vous passe les détails mais ça fait dans les 17 000 milliards de combinaisons possibles. Donc largement de quoi distinguer votre navigateur parmi des millions, comme une empreinte digitale qui colle au doigt !
Et ce qui pique vraiment c'est que cet identifiant survit à la fermeture de toutes vos fenêtres privées. Tant que le process Firefox tourne en arrière-plan, l'ID reste. Un site peut donc vous reconnaître après que vous ayez fermé vos onglets privés, rouvert une session pensée comme neuve, et revisité le site. Pour le user, c'est une session fraîche alors que pour le serveur c'est clairement le même navigateur qu'il y a dix minutes.
Côté Tor Browser c'est pire puisque le bouton "New Identity" a pour mission explicite de couper tout lien avec ce que vous faisiez avant. Il ferme les onglets, efface l'historique, vide les cookies, tire de nouveaux circuits Tor. La promesse officielle, c'est "empêcher votre activité future d'être liée à ce qui précède".
Sauf que cette fameuse table interne, elle, ne bouge pas. Le New Identity reset donc tout sauf ce qu'il ignore. C'est comme changer de fringues dans le même ascenseur... en gardant le même parfum. Techniquement vous êtes différent, mais reconnaissable en deux secondes. Bref, c'est assez grave car un site capable d'exploiter la faille peut lier votre session avant-New-Identity à votre session après-New-Identity.
Tant qu'on n'a pas redémarré Firefox complètement, l'ID persiste.
Les chercheurs disent avoir fait une divulgation responsable, directement à Mozilla et au Tor Project avant publication donc c'est nickel, et les deux équipes ont poussé les patches avant de communiquer sur quoi que ce soit. Donc les utilisateurs à jour sont tout simplement protégés contre cette faille précise.
Après si vous êtes du genre parano, pensez à redémarrer complètement votre Tor Browser entre deux sessions vraiment sensibles. Ça coupe le process Firefox, ça vide cette fameuse table, et ça évite ce genre de surprise pour d'autres leaks similaires qu'on n'aurait pas encore trouvés.
A bon entendeur, salut !!
Il y a quelques jours, lors de la demo party Revision 2026 , dans une salle plongée dans le noir à Sarrebruck, un public de sceners regarde défiler les crédits d'une demo victorieuse. Au milieu des pseudos des graphistes, un nom : Sector9.
Le même mec qui, quarante ans plus tôt, faisait partie des trois gamins norvégiens qui ont fondé Razor 1911.
Le logo historique de Razor 1911, signé JeD / ACiD (via Wikimedia Commons )
La demo s'appelle simplement "Razor 1911", elle dure dix minutes, et sans surprise, elle finit donc par gagner la compo PC et le prix du public. Et ce qu'elle raconte, plan par plan, c'est l'histoire d'un groupe que le Department of Justice américain a qualifié officiellement de "plus ancien groupe de cracking encore actif sur Internet".
Razor 1911 existe depuis que vous écoutez de la musique 8 bit sur cassette audio. Le groupe a traversé l'époque du Commodore 64, de l'Amiga, l'ère du PC, le passage au CD-ROM, au DVD, puis aux ISO torrents, sans oublier la répression fédérale et l'arrivée des protections Denuvo. Et au moment où j'écris ces lignes, leurs cracktros font partie du patrimoine culturel de tous ceux qui un jour ont téléchargé un jeu sur eMule.
Et voilà que, 40 ans plus tard, cette bande de joyeux lurons gagne un prix demoscene où elle se raconte elle-même...
Mais pour comprendre vraiment ce que ça veut dire, il faut que je vous emmène à Oslo lors de cette nuit d'octobre 1985.
Imaginez une chambre d'ado dans la banlieue d'Oslo. C'est l'automne norvégien, il fait nuit à 17h, et la seule lumière dans la pièce vient d'un écran CRT qui tire sur le vert. Un Commodore 64 chauffe doucement sur un bureau encombré et dans le lecteur de disquettes, une 5"1/4 tourne avec ce bruit caractéristique de crécelle électrique.
Les ordinateurs domestiques des années 80 qui ont vu naître la scene, Amiga 500 et Atari 520 ST (photo Sam Gamdschie, CC BY 3.0)
Doctor No, Insane TTM et Sector9, trois gamins, viennent de fonder un groupe de cracking. Leur premier nom, très éphémère, c'est Trøndelag Cracking Service, ou TCS. Sauf qu'un groupe anglais utilise déjà les mêmes initiales et ça crée la confusion. Un autre groupe norvégien de la scene, Hellmates, leur suggère alors un nouveau nom : Razor. On est encore à l'automne 1985 et ça s'appelle d'abord Razor 2992, puis en novembre, nouveau changement de nom pour adopter définitivement Razor 1911.
La raison de ce 1911 est géométrique. En hexadécimal, 1911 décimal équivaut à 0x777. Trois fois 7, un par fondateur, soit un joli clin d'œil numérologique qu'ils vont se traîner durant quarante ans. C'est aussi, selon certaines sources d'époque, une pique à tous les groupes de cracking qui abusaient du 666 pour leur côté satanique un peu too much. Razor 1911 choisit délibérément le chiffre opposé. Un détail qui en dit long sur l'esprit de la scene naissante à l'époque.
Leur premier crack, c'est Kik Start, un jeu de motocross sorti par Mastertronic en 1985 sur Commodore 64. Un classique des obstacles parcours sur deux roues que tout le monde avait chez soi. Et c'est précisément là dessus, ce petit jeu vendu pas cher en Angleterre, que nos trois gamins norvégiens vont poser leur première signature sur la scene européenne.
Kik Start (Mastertronic, 1985), le tout premier jeu cracké par Razor 1911 sur Commodore 64 (capture via Lemon64 )
La scene C64 européenne tourne à plein régime à ce moment-là. Les BBS échangent des disquettes par courrier postal, les cracktros fleurissent avec leur ASCII art et leur musique chiptune, les groupes s'affrontent pour la "first release" des jeux populaires. Razor 1911 grimpe alors très vite dans la hiérarchie, mais reste un groupe parmi d'autres. Les vraies légendes de l'époque, c'est FairLight en Suède, The Humble Guys aux US, et TRISTAR & Red Sector Inc côté Allemagne.
Ce qui distingue Razor 1911 à ce moment-là ? Pas grand-chose, en fait.
Enfin, si... une sacrée envie de durer ! Car quand la plupart des groupes de l'époque se dissolvent après deux ans, parce qu'un membre part à l'armée ou qu'un autre se fait piquer son Commodore par ses parents, eux continuent. Et continuent. Et continuent...
Et ils ne le savent pas encore, mais dans trois ans, ils vont devoir tout recommencer sur une nouvelle plateforme.
Nous sommes maintenant en 1988. Un ado quelque part en Europe lance un jeu piraté sur son Amiga 500 flambant neuf. Avant que le jeu démarre, une intro 3D tourne en 50 fps pendant trois minutes. Des sphères qui tournent, un scrolltext qui envoie des greetings aux autres groupes de la scene, et une musique de tracker composée de huit canaux qu'il va siffler dans sa tête pendant des semaines. Et le logo à la fin ? Razor 1911 !
L'Amiga 500, la machine reine de la scene européenne à la fin des années 80 (photo Bill Bertram, CC BY-SA 2.5)
Entre 1987 et 1988, le C64 commence à fatiguer et Razor 1911 migre alors sur Amiga, la plateforme qui gagne toute la scene européenne. Ils font des demos, ils crackent des jeux, ils sortent des cracktros avec des effets graphiques qu'aucune autre plateforme ne permet. C'est l'âge d'or Amiga. On lance le jeu, on kiffe l'intro, et ensuite on joue.
Razor 1911 ne se contente d'ailleurs pas de cracker des jeux sur Amiga. Le groupe sort aussi des demos pures, des productions artistiques qui font la compét' avec les meilleurs sur la scene démo. En 1991, ils lâchent coup sur coup Yo! avec ses graphismes vectoriels fluides et ses transitions travaillées, puis Voyage, considérée comme leur chef d'œuvre Amiga avec un texture mapping 3D qui fait halluciner tout le monde à l'époque sur un simple Amiga 500. Leur musique trackée 4 canaux est même citée comme parmi les meilleures jamais produites sur la machine.
Voyage par Razor 1911 (1991), un chef d'œuvre avec texture mapping 3D sur Amiga 500 (capture via pouet.net )
Puis au début des années 90, nouveau virage. Le PC IBM prend la main, bon gré mal gré, et Razor 1911 suit le mouvement. Là, c'est une autre scene. Les rivaux changent, et The Humble Guys (THG) débarque en 1989 avec une idée qui transforme tout. Candyman et Fabulous Furlough, les fondateurs de THG, inventent le fichier NFO pour documenter leurs releases, et surtout ils établissent des relations avec les distributeurs pour obtenir les jeux avant leur sortie commerciale. Imaginez un jeu qui apparaît sur les BBS warez AVANT même d'arriver chez Babbage's. THG vient de redéfinir les règles du game.
Razor 1911 doit alors s'adapter, et vite. Ils perfectionnent leur méthode de cracking, recrutent des codeurs, signent leurs cracks avec des intros de plus en plus léchées. À ce stade, une cracktro Razor 1911 c'est un petit morceau d'art. Graphismes pixelisés travaillés pendant des nuits entières, musique, textes ASCII qui défilent, et timings précis pour impressionner un maximum de sceners avant que le jeu démarre. Comme ça, les gars gardent la cracktro pour la montrer aux potes et sans qu'ils ne le sachent, commencent à transmettre une nouvelle culture.
Sauf que les années 90 avancent, et un nouveau support va bientôt tout faire basculer.
En 1995, quelque part en Amérique du Nord, un mec dont personne ne connaît le vrai nom se fait appeler The Punisher. Il passe ses nuits devant une tour beige de PC, ventilateur qui souffle fort, écran 14 pouces, et un clavier mécanique qu'on entendait depuis le salon. Devant lui, un graveur de CD, nouveauté de l'époque, qui met trois heures à "brûler" une rondelle de 600 Mo. Et c'est lui qui va sauver Razor 1911.
Parce qu'en 1995, tout bascule. Les disquettes disparaissent. Les jeux sortent sur CD-ROM, et 600 Mo, ça passe mal sur un modem 14.4k. Razor 1911 pourrait alors disparaître à ce moment-là, comme pas mal de groupes de l'époque qui n'arrivent pas à faire la transition.
Mais heureusement pour eux, The Punisher prend les choses en main et pilote le passage au CD-ripping, puis aux ISO quand ce format devient la norme. Les ISO, pour les plus jeunes, c'est une image binaire complète d'un CD ou d'un DVD, fidèle au bit près. Techniquement plus lourd que les cracks disquette, mais aussi plus propre. Razor 1911 se retrouve alors en tête du peloton et leurs releases circulent sur les topsites (les serveurs FTP ultra-privés de la scene, accessibles sur invitation uniquement), puis se diffusent sur les BBS, et ensuite sur les réseaux peer-to-peer naissants.
À la fin des années 90, le groupe devient l'une des références majeures de la scene, officiellement considéré comme l'un des plus prolifiques au monde. Ils sortent des ISO de jeux AAA quelques heures après la sortie commerciale, parfois même avant. Le palmarès est impressionnant : Quake, Warcraft II, Warcraft III, Red Alert, Terminal Velocity... Tous les hits du moment, tous disponibles sur les topsites Razor avant que les boîtes n'arrivent dans les rayons des Babbage's ou des CompUSA. Le Department of Justice citera explicitement ces titres dans son acte d'accusation, pour donner la mesure du phénomène.
La scene de l'époque pointe un autre leader que The Punisher : un certain The Renegade Chemist, souvent mentionné dans les fichiers NFO des releases. Quand l'opération Buccaneer va tomber, le FBI désignera Shane Pitman ("Pitbull") comme leader officiel, mais dans la scene, beaucoup disent que le vrai pilote au moment du raid, c'était The Renegade Chemist. Deux versions différentes de la même histoire, selon qu'on lise un rapport fédéral ou un NFO d'époque.
Et c'est là que ça devient dangereux.
Parce que quand vous êtes trop visibles, très rapides et très bons, il y a un moment où le FBI le remarque. Et en 2001, les fédéraux américains préparent quelque chose d'inédit dans l'histoire de la poursuite des groupes warez.
À Washington, dans un bureau de l'US Customs Service, un procureur imprime une liste. Dessus, des pseudos. Et surtout des adresses.
Conover, Caroline du Nord, ce matin-là. Shane Pitman, 31 ans, est au boulot quand son téléphone sonne. Au bout du fil, un agent du FBI et ce qu'il lui dit est glaçant : ils sont devant chez lui avec un mandat, alors il a intérêt à rentrer immédiatement ouvrir la porte, sinon ils rentrent eux-mêmes à coups de bélier.
Pitman quitte son bureau, monte dans sa voiture, et roule jusqu'à chez lui. Arrivé sur place, il trouve sept à huit véhicules du FBI et des douanes garés devant sa maison. À peine sorti de sa voiture, plusieurs agents en équipement d'assaut, gilets pare-balles et écussons "FBI" dans le dos, l'entourent, le plaquent sur le capot et le fouillent. Des années plus tard, dans une interview qu'il donnera sur un forum public, il racontera ce moment en expliquant que, je cite : "On aurait dit que j'étais Saddam Hussein ou quelque chose comme ça". Pour un mec qui distribuait des copies crackées de Warcraft, le dispositif était effectivement un peu surdimensionné.
Au même moment, à Richmond en Californie, Sean Michael Breen, 38 ans, se fait embarquer dans les mêmes conditions. Et à la même heure, dans cinq autres pays, Canada, Royaume-Uni, Australie, Finlande, Norvège, Suède, soixante autres personnes se font alpaguer simultanément.
C'est l'opération Buccaneer. 62 suspects visés, 70 mandats de perquisition, 150 ordinateurs saisis en une matinée et des pistes suivies dans 20 autres pays. C'est la plus grosse offensive coordonnée jamais menée contre la scene warez de l'histoire.
Reconstitution de l'opération Buccaneer - Image IA
Et les groupes visés ne sont pas que Razor 1911. Il y a aussi DrinkOrDie (DoD), RiSC, RequestToSend (RTS), ShadowRealm (SRM), WeLoveWarez (WLW), POPZ. Soit toute la tête de gondole de la scene cracker Internet de l'époque. Le FBI a passé 14 mois en investigation undercover, infiltré les serveurs, recoupé les pseudos, remonté les identités. Une opération patiente, méticuleuse, invisible. Certains membres sont alpagués à leur domicile, d'autres à leur travail, d'autres à la fac pendant qu'ils sont en cours.
Parmi les prises les plus symboliques, il y a aussi Christopher Tresco, 24 ans, connu sous le pseudo "BigRar". Pas un membre de Razor 1911 celui-là, mais de DrinkOrDie. Et accessoirement administrateur système du département d'Économie du MIT. Un boulot idéal pour héberger des topsites warez sur les serveurs d'une des plus prestigieuses universités américaines, ce qu'il faisait tranquillement jusqu'à ce matin du 11 décembre. Il prendra 33 mois de prison fédérale.
Le 6 juin 2003, Shane Pitman est condamné à 18 mois de prison fédérale pour conspiration de violation du copyright par le juge James Cacheris à Alexandria, Virginie. Le 10 février 2004, dans une cour d'Oakland, Sean Michael Breen prend 50 mois devant la juge Saundra Armstrong. C'est la peine la plus lourde de toute l'opération Buccaneer. Le chiffre qui sort lors du procès est vertigineux : Breen aurait distribué pour près d'un demi-million de dollars de jeux crackés sur une décennie. En plus de la prison, il doit donc verser 690 236,91 dollars de restitution au seul Cisco Systems. Au total, 22 personnes seront condamnées pour felony copyright infringement dans le cadre de Buccaneer.
Sur le papier, le groupe est décapité. Les leaders sont en taule ou en attente de jugement. Les membres restants se planquent, changent de pseudo, se disséminent. La communauté pense alors sincèrement que Razor 1911 est mort, tout comme DrinkOrDie qui ne se relèvera jamais.
Sauf que non.
Le 22 juin 2006, 5 ans et demi après Buccaneer, sur les topsites privés de la scene, une release apparaît silencieusement. Un vieux logo familier dans le fichier NFO, sans annonce triomphante. Juste un fichier qui commence à circuler. Les sceners qui le voient passer s'arrêtent une seconde. Puis sourient.
Razor 1911 est de retour.
Le groupe reprend le rythme, s'adapte aux nouvelles protections, signe ses cracks avec des cracktros modernisées. Au milieu des années 2010, ils sont de nouveau parmi les plus prolifiques du monde à cracker les nouveautés. Comme si Buccaneer n'avait jamais existé.
Puis arrive Denuvo, LA protection anti-copie hardware-assisted qui fait trembler toute la scene pendant des années. Razor 1911 y laisse des plumes, comme tout le monde. Les méthodes évoluent. Certains membres s'orientent alors vers la demoscene pure, tandis que d'autres continuent à cracker. Au bout du compte, les hyperviseurs finissent par contourner Denuvo en quelques heures . Le groupe mute, mais reste vivant.
Certaines sources affirment même que Razor 1911 se serait dissous vers 2012, ce qui est factuellement contredit par leurs releases récentes, notamment une cracktro pour Red Dead Redemption 2 sortie en mai 2024 et la demo de Revision 2026 dont on va parler juste après.
Entre temps, une autre histoire complètement dingue va éclater en 2023. Un joueur de GTA nommé Vadim M. remarque un truc bizarre en fouillant les fichiers des jeux Rockstar vendus sur Steam. Plusieurs titres, notamment Manhunt, Max Payne 2 et Midnight Club II, contiennent dans leurs exécutables des morceaux de code qui correspondent exactement aux cracks Razor 1911 de 2003. Rockstar Games, filiale de Take-Two, aurait tout simplement récupéré les versions crackées par Razor 1911 pour contourner ses propres DRM obsolètes et les revendre sur Steam.
Analyse du binaire de Midnight Club de Rockstar ( source )
Le comble, c'est que Rockstar a trifouillé le crack en question, ce qui a introduit des bugs sur Windows Vista et au-delà. Le message que ça donne c'est que même les studios qui chassent les reverse engineers en justice sont obligés, à un moment, d'utiliser leur travail pour faire tourner leurs propres jeux.
Et voilà... Tout ceci nous amène jusqu'à il y a quelques jours, quand lors de la Revision 2026 (la plus grosse demoparty mondiale, qui se tient tous les ans à Sarrebruck), Razor 1911 sort une demo PC de dix minutes titrée simplement "Razor 1911". Un voyage audiovisuel à travers les différentes époques du groupe. Windows 95, SoftICE, pixel art C64, effets Amiga et j'en passe... Le tout scripté avec des musiques signées brghtwhtlghtnng, zabutom et Ziphoid. Le concept est porté par Flopine, Anat, dubmood et goto80 et le code est signé rez, replay et blkpanther. C'est incroyable !
Et surtout dans les credits graphiques, un nom, celui de Sector9. Le même Sector9 qui, en octobre 1985, regardait une disquette tourner dans un C64 depuis sa chambre à Oslo. 40 ans plus tard, il est toujours à la table, toujours à faire du pixel art pour son groupe.
Je pense que vous comprenez maintenant pourquoi Razor 1911 n'est pas juste un groupe warez mais une vraie institution culturelle !
La longévité de ce groupe dépasse largement l'existence de la plupart des entreprises tech. Plus long que le leadership de Microsoft, plus long que l'histoire commerciale d'Apple sur le marché grand public, plus long que n'importe quelle plateforme de jeux vidéo encore active aujourd'hui. Razor 1911 a survécu au C64, à l'Amiga, à Windows 3.1, 95, XP, 7, 10, 11. Ils ont survécu aux BBS, à IRC, à eDonkey, à BitTorrent. Ils ont même survécu au FBI.
Et s'ils ont traversé les époques, c'est parce que la scene n'est pas un business. C'est une pratique culturelle qui se transmet de génération en génération, avec ses règles, son vocabulaire, ses rivalités, ses codes d'honneur bizarroïdes.
Des générations entières de développeurs et de chercheurs en sécurité sont passés par la scene avant de devenir des professionnels reconnus dans l'industrie. Je pense par exemple à Jonathan James ou Ehud Tenenbaum à l'époque. Razor 1911 illustre cette trajectoire fascinante où l'art, le crime et la passion se mélangent dans des proportions variables selon les décennies. Et le reverse engineering qui sert aujourd'hui à la recherche en sécurité, est exactement le même savoir-faire qu'avait celui qui crackait un jeu Amiga en 1990.
Bref, 40 ans après, la bande est toujours là, et rien que pour ça, chapeau bien bas !
Sources : Wikipedia | Wikipedia Operation Buccaneer | Waxy.org | DOJ Pitman | DOJ Breen | Interview Pitbull Defacto2 | MIT Technology Review | BleepingComputer Rockstar | Defacto2 | Les NFO de Razor1911
ChipSoft, l'éditeur qui fournit le logiciel de dossiers médicaux à environ 80 % des hôpitaux aux Pays-Bas, vient d'être touché par un ransomware. Le site de l'entreprise est hors ligne depuis le 7 avril, et on ne sait pas encore si des données de patients ont été volées.
L'attaque a été confirmée le 7 avril par Z-CERT, l'agence néerlandaise qui surveille la sécurité informatique dans le secteur de la santé. ChipSoft développe le logiciel HiX, qui gère les dossiers médicaux de patients dans la grande majorité des hôpitaux du pays. Le site web de l'entreprise est tombé dans la journée et reste inaccessible.
Z-CERT a envoyé un mémo confidentiel aux clients de ChipSoft pour leur demander de couper leur connexion VPN vers les systèmes de l'éditeur. Onze hôpitaux ont déconnecté leurs systèmes par précaution. Les autres ont indiqué que leurs données patients étaient en sécurité et que leurs services continuaient de fonctionner.
ChipSoft a confirmé qu'il y avait eu un "incident de données" avec un "possible accès non autorisé". L'entreprise ne peut pas garantir que des données de patients n'ont pas été consultées ou copiées. Le groupe de hackers derrière l'attaque n'a pas été identifié, et aucun montant de rançon n'a été rendu public.
Plusieurs hôpitaux, dont le Rijnstate Hospital, l'Antoni van Leeuwenhoek (spécialisé en cancérologie) et le Franciscus Hospital ont déclaré ne pas être affectés. Mais la portée réelle de l'attaque reste floue.
Z-CERT classe les ransomwares et l'extorsion comme les menaces principales pour les organisations de santé néerlandaises dans son rapport annuel.
Le secteur reste une cible privilégiée parce que les données médicales ont une valeur élevée sur le marché noir, et que les hôpitaux ne peuvent pas se permettre de rester longtemps sans accès à leurs systèmes.
Quand un seul éditeur gère les dossiers médicaux de 80 % des hôpitaux d'un pays, une attaque sur cet éditeur prend une dimension un peu inquiétante.
Pour l'instant les dégâts semblent contenus, mais le fait que ChipSoft ne puisse pas exclure un vol de données, c'est quand même un gros point d'interrogation. Et ça rappelle qu'un système de santé aussi centralisé, ça peut vite devenir une faiblesse.
Source : NL Times
J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.
Hazmat
prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un
brew install dredozubov/tap/hazmat
puis
cd /tmp
hazmat init --bootstrap-agent claude
Et hop, 10 minutes plus tard votre agent tourne dans sa cage. (le premier snapshot est ultra loooong mais après c'est de l'incrémental donc ça ira plus vite)
L'isolation repose sur 3 couches indépendantes, un peu comme les sas d'un sous-marin. Il y a d'abord un utilisateur agent dédié (vos fichiers perso deviennent alors hors de portée, point). Ensuite, une politique seatbelt générée dynamiquement à chaque session qui consiste à ce que le kernel de macOS vérifie chaque accès fichier et refuse tout ce qui n'est pas explicitement autorisé pour cette session précise.
Et par-dessus, des règles pf firewall qui empêchent l'agent d'envoyer du trafic SMTP, IRC, FTP, Tor ou VPN. Comme ça, un agent qui tentera d'exfiltrer vos données par mail se retrouvera bloqué net au niveau du noyau.
Côté supply chain, Hazmat force npm ignore-scripts=true par défaut. Comme ça, par exemple
le fameux hack axios
qui livrait un RAT via un hook postinstall en 2 secondes chrono n'est plus possible ici ! Y'a aussi une blocklist DNS qui redirige les services de tunnel connus (ngrok, pastebin, webhook.site) vers localhost. Contre un domaine perso fraîchement enregistré, ça passera mais les vecteurs d'exfiltration classiques, ça devrait résister.
Hazmat utilise TLA+, le même formalisme que les ingés d'Amazon utilisent pour vérifier les protocoles de DynamoDB. Genre, l'installation des règles sudoers AVANT le firewall (évidemment, ça crée une fenêtre de vulnérabilité), les restrictions qui bloquaient les lectures mais pas les écritures, ou encore une restauration cloud sans vérifier qu'un snapshot existait...etc, c'est le genre de truc qu'aucun test unitaire n'aurait chopé.
Ça supporte Claude Code (y compris le fameux --dangerously-skip-permissions), OpenCode et Codex. Attention par contre, si votre projet utilise Docker, y'a deux cas de figure : soit le daemon Docker est privé au projet et Hazmat le route automatiquement vers un mode Docker Sandbox, soit c'est un daemon partagé et là faudra passer --docker=none explicitement.
La commande hazmat explain montre aussi exactement ce que le sandbox autorise avant de lancer quoi que ce soit... et ça, c'est pas du luxe quand on sait pas trop ce qu'on va lâcher dans la nature. Le hazmat diff qui affiche les changements faits par l'agent depuis le dernier snapshot Kopia, c'est plutôt bien pensé. Et si l'agent casse un truc ? hazmat restore et c'est reparti, comme un Ctrl+Z géant pour tout votre projet.
Si vous avez déjà configuré votre Mac avec teaBASE pour sécuriser votre env de dev, c'est un complément logique.
Côté limites, faut être honnête, Seatbelt n'est pas documenté par Apple depuis macOS 10.5 et c'est du defense-in-depth, et pas une vraie frontière de VM. Quand à l'exfiltration HTTPS elle n'est pas bloquée car l'agent peut toujours curl n'importe quoi sur le port 443. C'est logique mais bon, c'est pas étanche à 100% quoi...
Et surtout c'est macOS only pour l'instant (le port Linux est en chantier), et bien sûr le /tmp partagé entre les comptes locaux reste un vecteur potentiel. J'aurais aimé aussi que le réseau soit coupé par défaut sauf whitelist, mais bon, faudra attendre. Après entre ça et laisser Claude Code en roue libre avec les pleins pouvoirs sur votre machine... y'a pas photo.
Bref, pour du vibe coding sur Mac, c'est le minimum vital.
Le noyau Linux 7.1 devrait supprimer la possibilité de compiler un noyau pour les processeurs Intel 486. C'est la première fois depuis 2012 qu'une architecture processeur est retirée du noyau, et le minimum requis passera du 486 au Pentium. L'Intel 486 a 37 ans.
L'Intel 486 est sorti en 1989. C'est le processeur qui a fait passer les PC de la ligne de commande au monde graphique, et il a été vendu pendant une bonne partie des années 90.
Le 486SX, sa version sans coprocesseur mathématique, et l'AMD Elan, une variante embarquée, sont aussi concernés par cette suppression. Le patch a été proposé par Ingo Molnar, un des développeurs historiques du noyau Linux.
La dernière fois que Linux a retiré le support d'une architecture processeur, c'était en 2012, quand le 80386 avait été abandonné. Ca fait donc 14 ans que personne n'avait touché à ce genre de nettoyage.
Le patch supprime trois options de configuration du noyau : M486, M486SX et MELAN. Sans ces options, il ne sera plus possible de compiler un noyau Linux spécifiquement pour un 486. Le processeur minimum deviendra le Pentium, qui supporte les instructions TSC et CMPXCHG8B, deux fonctions que le 486 ne gère pas.
Molnar explique que le code de compatibilité pour ces vieux processeurs pose régulièrement des problèmes et demande du temps de maintenance que les développeurs préfèrent consacrer à autre chose. Linus Torvalds avait d'ailleurs déclaré dès 2022 que les processeurs 486 n'étaient plus utilisés que comme pièces de musée.
Le retrait du 486 ne veut pas dire que Linux abandonne le 32 bits. Le noyau continue de supporter les architectures 32 bits, et il y a encore suffisamment de processeurs Atom et de systèmes embarqués 32 bits en circulation pour que ça reste le cas un moment.
Mais la tendance est claire : l'avenir de Linux sur x86 est en 64 bits, et le code 32 bits finira par suivre le même chemin que le 486.
Aucune distribution Linux récente ne proposait de toute façon un noyau compilé pour 486. Les utilisateurs qui font tourner Linux sur ce type de matériel pourront continuer avec des noyaux plus anciens.
Ca concerne très peu de monde en pratique, mais c'est quand même un petit moment d'histoire informatique. Le 486 a été le premier vrai processeur grand public chez Intel, et le voir disparaître du noyau Linux après 37 ans de bons et loyaux services, ça fait quelque chose.
En tout cas les développeurs du noyau semblent soulagés de pouvoir enfin faire le ménage. Pour la petite histoire, mon premier PC était un 386 SX25, et je suis ensuite passé directement au Pentium 60 (celui qui avait le bug de la virgule flottante), je trouve ça dingue qu'avec tous les ordinateurs que j'ai eu chez moi, je n'ai jamais eu de 486 !
Source : Phoronix
Le système de distribution d'applications Linux vient de publier la version 1.16.4, qui corrige quatre failles de sécurité découvertes dans son mécanisme de bac à sable.
La plus critique permettait à une app de sortir de son environnement isolé pour accéder à tous les fichiers de la machine et y exécuter du code. Le Steam Deck et la plupart des grandes distributions sont concernés.
Flatpak, c'est le format de distribution d'applications qui s'est imposé sur Linux ces dernières années. Son principe : chaque application tourne dans un bac à sable isolé du reste du système, un peu comme sur iOS. C'est aussi le format utilisé par le Steam Deck de Valve pour installer des applications en mode bureau.
La version 1.16.4, publiée le 7 avril, corrige quatre failles de sécurité. La plus grave, référencée CVE-2026-34078, est une vraie mauvaise surprise : une application pouvait exploiter des liens symboliques dans les options d'exposition du portail Flatpak pour accéder à l'intégralité des fichiers de la machine hôte, et même y exécuter du code.
La deuxième faille (CVE-2026-34079) permettait de supprimer des fichiers sur la machine hôte en passant par un bug dans le cache du chargeur dynamique ld.so. Flatpak supprimait les fichiers de cache obsolètes sans vérifier que le chemin fourni par l'application pointait bien vers le bon répertoire.
Deux autres problèmes ont aussi été corrigés : l'un permettait de lire des fichiers via le service système de Flatpak, l'autre de perturber le téléchargement d'une application lancé par un autre utilisateur, sans possibilité de l'arrêter proprement.
Toutes les distributions Linux qui utilisent Flatpak sont concernées, et c'est un paquet de monde : Fedora, Ubuntu, Linux Mint, SteamOS sur le Steam Deck, et bien d'autres.
La mise à jour vers la version 1.16.4 est disponible, ou le sera très vite, via les canaux habituels de chaque distribution. Si vous utilisez un Steam Deck en mode bureau avec des apps Flatpak installées via Discover, la mise à jour devrait arriver automatiquement.
C'est quand même un comble : un système conçu pour isoler les applications qui laisse une porte grande ouverte vers tout le système. Que Flatpak se fasse prendre en défaut sur son coeur de métier, ça fait un peu désordre.
Bon par contre, la réactivité a été bonne : la faille a été identifiée et corrigée, et les détails n'ont été publiés qu'avec le correctif disponible. C'est la base, mais au moins c'est fait.
Source : Phoronix
Anthropic vient de lâcher une bombe !
Le labo derrière Claude a dévoilé le Projet Glasswing , une initiative de cybersécurité qui embarque un nouveau modèle, Claude Mythos, tellement efficace pour trouver des failles qu'ils ont décidé de ne pas le rendre public. En gros, l'IA est devenue meilleure que la plupart des humains pour dénicher des vulnérabilités zero-day... et ça va faire mal ^^.
Concrètement, Mythos a trouvé des milliers de zero-days dans tous les OS et navigateurs majeurs ces dernières semaines. Et pas des failles mineures, hein ! Une vulnérabilité dans OpenBSD qui traînait depuis 27 ans, un bug dans FFmpeg vieux de 16 ans qui avait survécu à 5 millions d'itérations de tests automatisés... et des exploits chaînés dans le noyau Linux (3, 4, parfois 5 vulnérabilités enchaînées de manière autonome) qui permettent une escalade de privilèges complète. Comme le dit un chercheur dans la vidéo de présentation : "J'ai trouvé plus de bugs ces dernières semaines que pendant tout le reste de ma carrière combinée".
Et le truc qui tue, c'est que Mythos n'a pas été entraîné spécifiquement pour la cybersécurité. Il a juste été entraîné pour être bon en code... et par effet de bord, il est devenu redoutable en sécu. En fait, les benchmarks sont assez parlants. Sur CyberGym (reproduction de vulnérabilités), Mythos tape du 83% contre 67% pour Opus 4.6. Mais c'est sur l'exploitation de Firefox 147 (en collaboration avec Mozilla je tiens à le préciser), que le fossé est le plus flippant : 84% de taux de réussite en exploitation shell, contre 15% pour Opus 4.6 et 4% pour Sonnet.
Lors de tests internes , une version précoce de Mythos enfermée dans un sandbox sécurisé a réussi à s'en échapper (on lui en avait donné l'instruction pour le test), a développé un exploit multi-étapes pour accéder à Internet, puis a envoyé un email au chercheur pour le prévenir de son évasion. Le chercheur l'a reçu lorsqu'il était en train de faire sa pause sandwich dans un parc ! Dans moins de 0,001% des cas, ces versions précoces ont même carrément tenté de dissimuler des actions interdites en modifiant l'historique git pour ne pas laisser de traces. Bon, Anthropic précise que ces comportements ont été corrigés dans la version finale parce que c'était clairement pas tolérable... mais quand même.
Ce qui est vraiment impressionnant, c'est cette coalition derrière Glasswind. Apple, Microsoft, Google, AWS, NVIDIA, CrowdStrike, Cisco, Palo Alto Networks, JPMorgan, Broadcom, la Linux Foundation... des partenaires qui d'habitude se tirent dans les pattes, réunis autour de la même table, plus 40 autres organisations.
Le problème c'est que Mythos ne sera pas accessible au public. Trop dangereux. Seuls les professionnels de la sécurité vérifiés y auront droit, via un "Cyber Verification Program" dédié. Je suis triste, j'aurais vraiment kiffé le tester...
Anthropic met 100 millions de dollars de crédits sur la table pour la recherche, plus 2,5 millions pour l'OpenSSF et 1,5 million pour la fondation Apache. Le programme "Claude for Open Source" donne un accès dédié aux mainteneurs de projets open source. C'est du bon gros marketing c'est sûr, mais quand on voit le nombre de mainteneurs open source qui bossent seuls le soir sans budget sécu... franchement, c'est pas de refus.
Du coup, on vient vraiment de passer à une autre échelle.
L'année dernière, o3 d'OpenAI avait trouvé UN zero-day Linux et c'était déjà une première mondiale. Là, Mythos en trouve des milliers et crée des preuves de concept d'exploitation quasiment toujours du premier coup. C'est chouette pour la sécurité mais cette capacité est clairement un couteau à double tranchant. Entre les mains d'un défenseur, c'est un bouclier mais entre les mains d'un attaquant... bon, on préfère pas y penser.
Anthropic s'engage à publier un rapport dans les 90 jours sur les vulnérabilités patchées et à terme, ils veulent créer un organisme indépendant, public-privé, pour coordonner tout ça. Comme l'a dit le CTO de CrowdStrike : "ce qui prenait des mois prend maintenant des minutes".
Bref, Glasswing c'est le moment où l'IA en cybersécurité passe du labo au terrain, mais maintenant reste à voir si le bouclier sera déployé plus vite que l'épée.
Un passionné a tenté de récupérer son Pokémon coincé dans un Pokéwalker, ce petit podomètre vendu avec Pokémon HeartGold sur DS en 2009, après avoir perdu la cartouche de jeu.
Entre reverse engineering du protocole infrarouge et manipulation du générateur de nombres aléatoires, la tentative est bien technique. Et le résultat est plutôt cruel, pour une raison que personne n'avait anticipée…
Le Pokéwalker, pour ceux qui ne s'en souviennent pas, c'était ce petit podomètre vendu avec Pokémon HeartGold et SoulSilver sur Nintendo DS en 2009. Le principe était simple : vous transfériez un Pokémon de votre partie vers cet accessoire, vous le glissiez dans votre poche, et chaque pas comptait pour gagner des points et débloquer des objets.
Le tout communiquait avec la cartouche DS par infrarouge. Sauf que voilà, si vous perdez la cartouche (ce qui arrive plus souvent qu'on ne le croit après 15 ans), votre Pokémon reste coincé dans le Pokéwalker. Pas de cartouche, pas de transfert retour. C'est exactement le problème auquel s'est retrouvé confronté Etchy, un créateur de contenu spécialisé dans Pokémon Gen 4.
Le travail de fond, c'est Dmitry qui l'avait fait il y a quelques années en décortiquant complètement le Pokéwalker. A l'intérieur : un microcontrôleur Renesas H8, une EEPROM de 64 Ko, un accéléromètre Bosch et un émetteur infrarouge générique. La communication entre la cartouche et le Pokéwalker passe par un protocole IR à 115 200 bauds, et chaque octet est simplement XOR avec 0xAA avant envoi.
Dmitry avait même réussi à exécuter du code arbitraire sur l'appareil en exploitant un débordement de buffer dans la décompression. Etchy s'est appuyé sur tout ce travail pour tenter sa mission de sauvetage. Son idée : créer une nouvelle sauvegarde avec les bons identifiants pour tromper le Pokéwalker.
Le dispositif ne vérifie que la version du jeu (HeartGold ou SoulSilver), la région et les identifiants du dresseur. En manipulant le générateur de nombres aléatoires du jeu, Etchy a réussi à générer une sauvegarde avec des IDs correspondants.
Et ça a marché. En partie. Le Pokéwalker a accepté la connexion et transféré les données du Pokémon. Sauf que le vrai identifiant unique du Pokémon, son PID, celui qui définit ses stats, sa nature, son apparence, n'existe que sur la cartouche d'origine.
Le Pokéwalker ne stocke qu'une version allégée des données : l'espèce, les attaques, l'objet tenu, le genre. Le PID, lui, restait sur la cartouche perdue. Du coup, le Pokémon récupéré n'est qu'une copie incomplète. Ca ressemble à votre Typhlosion, ça porte son nom, mais ce n'est pas vraiment lui. Comme le résume Etchy dans sa vidéo : il n'y a pas de moyen de sauver un Pokémon piégé dans un Pokéwalker.
C'est le genre d'histoire qui parle à tous ceux qui ont grandi avec une DS dans la poche. On a tous eu ce moment où un accessoire, une sauvegarde ou un périphérique finissait au fond d'un tiroir, avec des données qu'on pensait sans importance.
Etchy et Dmitry montrent qu'il y a une vraie communauté prête à passer des heures sur du reverse engineering pour trois octets de données. C'est beau et un peu absurde en même temps. Le plus cruel dans l'histoire, c'est que Nintendo n'avait visiblement pas prévu qu'on puisse perdre sa cartouche tout en gardant le Pokéwalker. Bref quinze ans plus tard, votre Typhlosion attend toujours dans son petit boîtier, et personne ne viendra le chercher.
Source : Hackaday
