Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierGénéralistes

Un thermostat Honeywell bourré de failles

27 mai 2026 à 12:55

Des chercheurs ont passé le thermostat connecté Honeywell X2S à la moulinette du reverse-engineering. Le résultat est un peu embarrassant.

L'appareil en question, c'est un thermostat Wi-Fi qui se pilote depuis le smartphone et s'intègre aux installations domotiques, embarque deux puces principales. Un microcontrôleur Renesas Cortex-M33 cadencé à 200 MHz avec TrustZone (la techno qui isole les zones sensibles de la puce pour protéger les données critiques), et une puce Realtek qui gère le Wi-Fi et le Bluetooth Low Energy. À côté, deux mémoires Flash Winbond chiffrées.

Pour aller fouiller dedans, les chercheurs ont fabriqué une petite carte d'interface avec des pogo-pins (des broches à ressort qui viennent appuyer sur les points de test du circuit, sans rien souder). Avec ça, ils ont pu accéder au firmware et le décortiquer tranquillement.

Le bilan est donc assez gênant. La puce Realtek embarque une fonction de déchiffrement à la volée appelée RSIP, exploitable. Le protocole TLS, censé sécuriser les échanges avec les serveurs, contient une faille qui permet une attaque "man-in-the-middle" toute bête (un intermédiaire qui se glisse entre votre thermostat et le serveur pour lire ou modifier les échanges). Et un bug dans la génération des clés de session permet de les retrouver à coup sûr. Bref, l'appareil est troué de partout.

Le code de l'exploration est dispo sur Codeberg sous le nom "fuji-exploration", pour qui veut creuser.

Honeywell est une grosse boîte, pas un petit fabricant chinois sans-le-sou. Un thermostat connecté n'est pas un gadget anodin : il est branché en permanence sur votre réseau Wi-Fi domestique, et il sait à quelle température vous vivez, donc indirectement quand vous êtes chez vous. Voir une marque de ce niveau sortir un produit avec autant de vulnérabilités basiques, ça pose question.

Le pire, c'est qu'il n'y a aucune raison technique pour expliquer ces failles. La cryptographie correcte existe depuis vingt ans, les frameworks TLS sécurisés sont gratuits et bien documentés, et un bug dans la génération de clés se détecte logiquement sans trop problème. Quelqu'un a juste décidé que ce n'était pas la priorité.

Bref, encore un objet connecté à ajouter à la longue liste des trucs qu'on ne devrait pas laisser entrer chez soi sans l'isoler sur un réseau séparé.

Source : Hackaday

L'Italie démantèle Cinemagoal, l'énorme appli de streaming pirate

26 mai 2026 à 16:05

Le fisc italien a frappé fort il y a quelques jours. La Guardia di Finanza, sous la direction du parquet de Bologne, vient de démanteler un réseau de piratage de streaming baptisé Cinemagoal, dans une opération nommée "Tutto Chiaro" (tout clair, en italien).

Plus de 100 perquisitions ont été menées dans 17 régions du pays, plus des saisies coordonnées en France et en Allemagne via Eurojust (l'agence européenne qui coordonne les enquêtes judiciaires entre pays de l'UE). Joli coup de filet.

Le système était assez bien huilé. Cinemagoal proposait à ses clients un accès à Netflix, Disney+, Spotify, Sky et DAZN pour 40 à 130 euros par an, soit une fraction du prix de l'ensemble des abonnements officiels.

Pour faire fonctionner ce petit business, l'équipe derrière l'appli avait monté une infrastructure de machines virtuelles en Italie qui aspiraient en permanence les clés de déchiffrement DRM (les codes numériques qui débloquent la lecture des contenus protégés) à partir de vrais comptes payants.

Toutes les trois minutes, de nouvelles clés étaient renvoyées aux clients, ce qui rendait le système difficile à bloquer en temps réel par les plateformes officielles.

L'astuce des trois minutes n'était pas innocente. En renouvelant les clés à intervalle court, Cinemagoal contournait les outils antifraude que Netflix et consorts utilisent pour détecter les comportements bizarres sur un compte. Difficile pour la plateforme de repérer un piratage à grande échelle quand chaque clé volée n'est utilisée que quelques minutes avant d'être remplacée.

Côté budget, l'enquête estime à environ 300 millions d'euros le manque à gagner cumulé pour les ayants droit sur plusieurs années. Les autorités ont aussi mis la main sur les serveurs étrangers qui hébergeaient le code source complet de l'appli et les bases de données de clés, ce qui devrait empêcher le service de redémarrer sous un autre nom.

Plus inhabituel, l'opération s'attaque aussi aux utilisateurs finaux. Environ un millier d'abonnés à Cinemagoal ont été identifiés et reçoivent en ce moment des avis d'amende administrative allant de 154 à 5 000 euros. C'est une approche assez différente de ce qu'on voit en France, où les pirates côté consommateurs sont rarement inquiétés (ouf). L'idée du parquet italien, c'est vraiment de faire peur.

Et puis il y a la question de la durée. Cinemagoal tournait depuis plusieurs années sans gros problème, ce qui veut dire que les plateformes officielles ont mis du temps à repérer la fuite, ou en tout cas à coordonner une réponse efficace avec les autorités. Vu les sommes en jeu, ça pose quand même la question de la solidité des protections DRM actuelles face à des équipes techniques motivées pour tout pirater.

Source : Bleeping Computer

Le firmware Linux manquant des laptops HP Panther Lake vient enfin d'arriver

26 mai 2026 à 15:50

Si vous venez d'acheter un portable HP équipé d'un Intel Core Ultra Series 3 (nom de code Panther Lake) et que vous y faites tourner Linux, vous allez accueillir cette nouvelle avec une certaine satisfaction. Intel et HP ont enfin poussé le firmware nécessaire à l'activation du fameux Integrated Sensor Hub dans linux-firmware.git, le dépôt officiel utilisé par à peu près toutes les distributions Linux du marché.

Petite mise en contexte quand même... Vous le savez, le firmware, c'est le tout petit logiciel bas niveau qui permet à un composant matériel de fonctionner. Et l'Integrated Sensor Hub (l'ISH pour les intimes), c'est un co-processeur intégré dans les puces Intel récentes.

Son job est de gérer les capteurs du laptop (orientation de l'écran, accéléromètre, gyroscope, capteurs de lumière, etc.) sans déranger les gros cœurs du CPU principal. Ça permet en fait à la machine de capter ce qu'il se passe autour d'elle même quand elle est en veille, sans vider la batterie.

Le problème, c'est que ce petit co-processeur a besoin d'un firmware spécifique pour fonctionner. Et sans ce firmware, l'ISH était muet sur Linux. Résultat : des fonctions comme la rotation automatique de l'écran sur un PC convertible, l'allumage à la détection de présence ou les économies d'énergie liées aux capteurs ne fonctionnent tout simplement pas, ou alors franchement mal.

Le pilote était déjà dans le noyau Linux depuis longtemps. C'est la pièce manquante, le firmware lui-même, qui était à la bourre. Sans lui, il faut bidouiller, copier des fichiers à la main depuis Windows, ou faire une croix sur certaines fonctions. C'est le genre de situation qui fait fuir les utilisateurs vers Windows ou macOS sur du matos neuf.

De la part d'HP, c'est plutôt un bon rattrapage. Le constructeur historique pousse régulièrement des laptops pré-installés avec Linux à destination des développeurs et des entreprises (la gamme ZBook sous Ubuntu, par exemple, qui existe depuis quelques années). Avoir un bon support dès la sortie du carton, ça compte vraiment pour ce public-là, qui ne veut pas passer une heure à chasser les firmwares disparus pour faire marcher son trackpad ou son lecteur d'empreintes.

Intel, de son côté, a fait pas mal d'efforts ces derniers temps pour simplifier sa licence de firmware et accélérer la mise à dispo de ces fichiers binaires pour Linux. On a d'ailleurs vu la même histoire avec le firmware NPU (la puce dédiée à l'intelligence artificielle) qui a été publié juste avant pour Panther Lake.

Bref, pour qui voulait passer à un laptop HP Panther Lake sous Linux dès maintenant, le timing est devenu nettement meilleur.

Source : Phoronix

Outlook se met à perdre les images dans vos mails, Microsoft confirme le bug

26 mai 2026 à 15:27

Si vous avez remarqué récemment que les logos de vos correspondants pros sont remplacés par une vilaine croix rouge dans Outlook, ou pire, que certaines pièces visuelles disparaissent purement et simplement de vos mails, ce n'est ni votre antivirus ni votre connexion.

The Register a sorti le sujet la semaine dernière, et Microsoft a fini par confirmer un bug introduit dans la version 2604 (Build 19929.20164) de Classic Outlook, qui fait planter l'affichage de certaines images dans les emails.

Le problème ne touche pas n'importe quelle image. La condition pour le déclencher, c'est d'avoir une option de mise en page particulière activée, "Habiller le texte en haut et en bas" (l'image flotte au-dessus du texte avec le contenu qui s'écoule au-dessus et en dessous).

Avec cette configuration, Outlook se prend les pieds dans le tapis et affiche à la place un message d'erreur du genre "L'image liée ne peut pas être affichée. Le fichier a peut-être été déplacé, renommé ou supprimé.", ou parfois rien du tout, juste un trou blanc.

Le plus pénible, c'est que les premières victimes sont les signatures de mail qui contiennent un logo d'entreprise. Vous savez, ce petit truc obligatoire qui doit faire identité de marque sur chaque message envoyé. Eh bien, chez pas mal de monde, ces logos se retrouvent désormais accompagnés d'une jolie croix rouge ou d'une boîte vide. Pratique pour faire pro auprès des clients.

Microsoft a publié sur son site de support un correctif temporaire qui consiste à demander aux utilisateurs de changer le réglage d'habillage de leurs images, en passant sur un autre mode (intégré dans le texte, derrière le texte, etc.). Pas idéal. Encore moins quand on ne sait même pas où trouver ce réglage et qu'on l'a mis en place il y a deux ans avec l'aide du service info de la boîte.

Pour la suite, c'est encore moins drôle. Microsoft précise que les images des messages d'origine reviendront normalement une fois le correctif déployé, ce qui est plutôt rassurant. Sauf que pour les réponses ou les transferts faits pendant la période bugée, certaines images peuvent disparaître définitivement, parce qu'elles ne se seront tout simplement pas attachées au nouveau message.

Ce qui veut dire que tout un fil de discussion sur un projet visuel risque de perdre des morceaux en chemin sans qu'on s'en rende compte tout de suite.

Aucune date n'est annoncée pour le déploiement du correctif définitif. C'est typiquement le genre de bug qui aurait dû être attrapé en interne avant publication, sur une fonctionnalité aussi basique que l'affichage d'une image.

Et c'est aussi un rappel utile que Classic Outlook (la version installée historiquement sur Windows, par opposition au New Outlook web) reste largement utilisée en entreprise et que ses bugs touchent vraiment beaucoup de monde.

Au passage, si vous hésitez entre attendre le correctif et passer sur le nouveau Outlook ou un client tiers, ça peut être l'occasion de jeter un œil ailleurs.

Source : The Register

Heretic - Virer la censure d'une IA en une commande

Par : Korben ✨
26 mai 2026 à 08:08

Y'a des entreprises qui claquent des millions pour bien aligner leurs modèles d'IA afin qu'ils refusent toutes les questions sensibles qui font flipper nos amis puritains d'outre-Atlantique et y'a Heretic , un outil signé Philipp Emanuel Weidmann, qui balaye toute censure sur n'importe quel modèle en moins de 30 minutes avec une simple carte graphique de gamer.

Je vous explique... Vous devez avoir Python et une version récente de PyTorch sur votre machine, puis vous tapez pip install heretic-llm, puis heretic Qwen/Qwen3-4B-Instruct-2507 avec le nom du modèle que vous voulez décensurer.

Et l'outil fait alors sa vie et 20 à 30 minutes plus tard, vous récupérez une version du modèle qui a lâché prise sur l'essentiel de ses refus. Pas de dataset à préparer et surtout pas besoin de comprendre les entrailles d'un transformer, avec ce truc !

Dans un modèle aligné, le réflexe de refuser (le fameux "désolé, je ne peux pas vous aider avec ça") correspond souvent à une direction précise dans ses calculs internes. Les chercheurs appellent ça la "direction de refus". Et l'idée de l'abliteration, c'est de repérer cette direction et de la gommer des poids du modèle. En gros, on coupe le câble qui déclenche le "non", en touchant le moins possible au reste.

D'autres outils d'abliteration existaient déjà , mais leur réglage restait largement manuel et il y a aussi des gens comme mlabonne ou huihui-ai qui publient des modèles décensurés en ajustant les paramètres à la main, modèle par modèle, avec des résultats souvent inégaux. Mais Heretic, lui, automatise complètement le réglage. Pour cela, il s'appuie sur Optuna, un framework d'optimisation qui teste des dizaines de configurations et garde les meilleures tout seul. Et son seul objectif c'est de virer un max de refus tout en abîmant le moins possible le modèle d'origine.

Et de ce que je comprends, ça marche super bien ! Sur Gemma-3-12B, le modèle de Google de base refuse 97 fois sur 100 les prompts sensibles du benchmark maison. Mais après un petit passage dans Heretic, il tombe à 3 refus sur 100, soit le même niveau que les meilleures "nettoyages" manuels.

Et surtout, Heretic affiche une divergence de 0,16 là où les versions faites main grimpent à 0,45 voire 1,04 (C'est une mesure de l'écart de comportement sur les questions normales... plus c'est bas, mieux c'est).

Cela veut donc dire qu'il abîme beaucoup moins le modèle au passage.

Maintenant, tous les modèles n'y passent pas, car un gros calibre demande bien plus de VRAM et cela peut grimper à plusieurs heures. De plus, une étude comparative récente montre que le raisonnement mathématique est ce qui souffre le plus de ce genre d'abliteration, quel que soit l'outil utilisé.

Et surtout, y'a déjà des chercheurs qui bossent sur des défenses pour rendre les modèles résistants à ce genre d'attaque. Donc on verra bien, mais tant que c'est possible autant en profiter car des modèles sans bridage, ça permet notamment à des chercheurs d'étudier leurs propres failles, ou pour des usages du quotidien, de faire passer des demandes banales qui seraient bloquées (genre texte créatif, reverse engineering ou demande de conseils médicaux, ce genre de choses...)

Voilà, si vous bidouillez du LLM en local , allez voir ce projet car ça peut vous "ouvrir" quelques portes ^^.

Quand les Motorola prennent une commission sur vos achats Amazon

Par : Korben ✨
26 mai 2026 à 07:34

J'sais pas si vous avez vu, mais sur les Motorola Razr 2026, l'app maison Smart Feed intercepte le lancement de l'application Amazon pour y glisser en soumsoum un petit code d'affiliation. Comme ça, à chaque fois que vous tapez sur l'icône Amazon, votre clic se met à rapporter une commission à un compte tiers. Vous ne payez pas un centime de plus rassurez-vous, c'est le principe de l'affiliation, mais il me semble que c'est pas très réglo de ne pas le dire. En plus je pense que ça va à l'encontre des CGU d'Amazon... Breeeef, y'a rien qui va dans cette histoire.

Le truc se déclenche donc uniquement quand vous ouvrez Amazon le menu des applications, et pas depuis un raccourci sur l'écran d'accueil. A ce moment là, pendant une fraction de seconde, Chrome clignote à l'écran, et votre téléphone passe par un site nommé kira-abboud.com, pour ensuite utiliser un lien qui repart vers l'app Amazon avec le code d'affiliation sramz-kff-008-20 comme si de rien n'était. Comme ça Amazon, pense que vous arrivez de ce lien affilié.

C'est tellement rapide que la plupart des gens ne verront jamais rien....

Sauf que kira-abboud.com renvoie vers une influenceuse mode, @kirasfashionfinds présente sur Instagram, et qui n'a aucun lien apparent avec Motorola. Pire, le code d'affiliation collé à votre session ne correspond même pas à ceux qu'elle a déjà publiés. Et voilà comment on se retrouve avec un téléphone vendu par une grosse marque qui détourne vos clics vers un compte tiers, sans la moindre explication.

Côté technique, les logs réseau pointent vers devicenative.com. C'est une régie qui place de la pub sur les smartphones via un SDK intégré aux launchers Android, avec une intégration Motorola documentée. En clair, le mécanisme qui pourrit votre app Amazon pointe vers un kit publicitaire préinstallé d'usine.

Reste à savoir maintenant si c'est un choix assumé de Motorola ou un SDK pub qui part en vrille, voire un hack... et pour l'instant, personne ne le sait.

Ce qui est sûr, c'est que le coupable porte un nom et un numéro de version. Sur la version 2.03.0056 de Smart Feed, aucun détournement alors que sur la 2.03.0070, le hijack apparaît. Et bizarrement, installer manuellement cette même version mise à jour ne reproduit pas le comportement. Autrement dit, y'a quelque chose qui s'active côté serveur ou côté usine, et pas juste dans le code de l'app. C'est vraiment super bizarre...

Les Razr 2026 et Razr Fold sont touchés, tout comme le Razr 60 Ultra de 2025 à l'origine du signalement. Le Moto G Stylus 2026 testé en parallèle, lui, ne l'est pas.

Après la bonne nouvelle, c'est que la parade est facile à faire ! Direction Paramètres, Applications, vous cherchez Smart Feed, et vous le désactivez. D'après les tests que j'ai pu lire, ça n'a pas d'impact visible sur le reste du téléphone donc mieux vaut désactiver cette merde parce que c'est réversible en deux clics et bien moins casse-gueule que de virer l'app via adb.

Perso, qu'un téléphone vendu par une marque sérieuse détourne nos clics vers un compte tiers via un domaine bidon, ça me rend fou et même si à l'échelle d'un clic, la commission c'est trois fois rien, étalé sur tout un parc d'appareils, ça finit par peser lourd niveau oseille pour celui qui encaisse.

Ce problème dépasse le cadre "Motorola" d'ailleurs puisque less apps préinstallées qu'on ne peut pas virer (les fameux bloatware) sont devenues un canal de monétisation à part entière et comme personne ne vérifie jamais ce que ces trucs font tourner en arrière-plan, c'est la fête du slip ! C'est exactement le même genre de paranoïa raisonnable que quand on se demande si votre téléphone vous écoute sauf qu'ici, pas besoin de théorie, puisque ce détournement est parfaitement visible.

Pour l'instant, Motorola a été contacté mais n'a pas réagi et le code d'affiliation continue de tourner sur les appareils concernés tant que Smart Feed reste actif. J'imagine quand même qu'Amazon va s'occuper de le désactiver en attendant d'en savoir plus.

Bref, bon courage si vous avez un Motorola récent !

Source

Google neutralise la première cyber-attaque massive générée par une IA

12 mai 2026 à 13:49

Google a balancé l'info via son équipe cyberdéfense, le GTIG (Google Threat Intelligence Group). Des cybercriminels ont utilisé une IA générative pour dénicher et écrire un code d'attaque exploitant une faille inconnue (ce qu'on appelle un zero-day, une vulnérabilité que l'éditeur du logiciel n'a pas encore corrigée).

Et ils s'apprêtaient à lancer une vague d'attaques massives. C'est, d'après Google, la première fois qu'on observe ça dans la vraie vie, pas en labo.

La faille concernait un outil d'administration de serveur open-source très utilisé, dont Google ne donne pas le nom (le temps que tout le monde installe le correctif).

Le bug permettait de contourner la double authentification, le fameux code à 6 chiffres ou la notification sur le téléphone qui sécurise vos comptes. En pratique, il fallait quand même un identifiant et un mot de passe valides au départ, donc ce n'est pas une attaque magique en un clic. Mais une fois ce sas franchi, la 2FA tombait toute seule.

Ce qui a mis la puce à l'oreille des chercheurs, c'est l'allure du script Python utilisé pour exploiter la faille. Trop bien écrit, trop documenté, trop scolaire en fait.

Il était bourré de commentaires pédagogiques (le genre qu'on retrouve dans un tuto pour débutant), il affichait un menu d'aide impeccable, et surtout un score de dangerosité CVSS complètement inventé. Cette dernière trouvaille, c'est l'indice qui ne trompe pas, seul un modèle de langage peut halluciner un chiffre officiel avec autant d'aplomb.

John Hultquist, le chef analyste du GTIG, explique que les IA génératives sont vraiment douées pour repérer ce genre de faille logique de haut niveau, là où les outils d'audit classique (les "fuzzers" qui bombardent un logiciel de données aléatoires pour le faire planter) passent à côté.

Google précise au passage que ce n'est pas Gemini, son propre modèle d'IA, qui a été utilisé. Lequel alors ? Mystère, l'équipe de Mountain View ne le dit pas. On imagine que les criminels n'ont pas demandé poliment l'autorisation à un éditeur d'IA. Affaire à suivre.

Le rapport donne d'autres pépites. Le groupe nord-coréen APT45 utiliserait l'IA pour tester des milliers d'exploits en masse. Des opérateurs chinois liés à l'État expérimenteraient l'IA pour chasser les vulnérabilités.

Des backdoors (des portes dérobées cachées) sur Android interrogent directement Gemini pour piloter les téléphones infectés. Et côté désinformation, des opérations russes intègrent du faux audio généré par IA dans de vraies images d'actualités. Bref, ça bouge de partout.

Bonne nouvelle quand même, la campagne d'attaque massive a été désamorcée. Google a coordonné un correctif discret avec l'éditeur avant que les criminels puissent appuyer sur le bouton. Cette fois.

Bref, l'IA fabrique maintenant des armes prêtes à l'emploi pour les criminels, et personne ne sait quel modèle a fait le boulot. Rien de rassurant donc.

Source : The Hacker News

Vos câbles fibre optique peuvent servir à vous espionner, et ça marche très bien

12 mai 2026 à 13:08

Une fibre optique de télécom standard, celle qui passe peut-être à quelques mètres de votre bureau en ce moment, peut être transformée en microphone à distance.

C'est ce qu'ont démontré des chercheurs à la conférence NDSS 2026, le rendez-vous annuel de la sécurité réseau qui s'est tenu à San Diego. Leur démo est carrément flippante. Pas de matériel posé sur place, pas de signal radio détectable, et une qualité audio largement suffisante pour transcrire ce qu'on dit dans une pièce.

Le principe repose sur une technique appelée DAS (Distributed Acoustic Sensing, en français "détection acoustique distribuée"), qui consiste à envoyer un laser dans la fibre depuis une extrémité et à analyser comment la lumière revient.

Quand des ondes sonores frappent le câble, elles le font vibrer de manière minuscule, ce qui modifie le trajet de la lumière. En mesurant ces modifications, on peut reconstituer le son d'origine, comme si la fibre devenait un long micro de plusieurs dizaines de mètres.

Pour booster la sensibilité, les chercheurs ont fabriqué un petit accessoire qu'ils appellent "Sensory Receptor", en gros un cylindre en plastique PET de 65 mm de diamètre autour duquel ils enroulent 15 mètres de fibre. Le cylindre concentre les vibrations et amplifie le signal capté.

Les résultats ? À deux mètres de la fibre, le taux d'erreur sur les mots (le WER, qui mesure combien de mots sont mal transcrits par un système de reconnaissance vocale) descend sous les 20 %. Dans un test grandeur nature mené dans un bureau, avec une cinquantaine de mètres de fibre séparant les deux pièces et le boîtier installé sous un meuble, ils tombent à 9 %.

Quasiment un transcript parfait donc. En bonus ils ont utilisé OpenAI Whisper et NVIDIA Parakeet, deux modèles d'IA de reconnaissance vocale grand public, donc rien d'exotique côté logiciel.

Et le truc qui change tout, c'est l'indétectabilité. Une fibre passive ne consomme pas d'électricité, n'émet aucune onde radio, et passe inaperçue aux détecteurs de mouchards classiques utilisés par les services de contre-espionnage. 

es balayages TSCM (les outils déployés pour chercher des micros cachés dans une pièce sensible) passent à côté. Limite tout de même : il faut être à environ 5 mètres maximum de la fibre, et celle-ci ne doit pas être enterrée trop profondément. Mais dans n'importe quel immeuble de bureaux moderne, où la fibre court partout dans les faux plafonds, ça peut fonctionner !

Source : Hackaday

Des faux installateurs Claude Code se baladent dans Google

12 mai 2026 à 08:09

Des faux installateurs Claude Code se baladent dans Google

Les chercheurs d'Ontinue, une boîte de cybersécurité, ont publié une analyse d'une campagne de vol de données qui vise directement les développeurs.

La méthode est en fait assez simple. Vous tapez "install claude code" dans Google, vous cliquez, plein d'innocence, sur le premier résultat sponsorisé, et là vous tombez sur une page qui ressemble trait pour trait à la doc officielle d'Anthropic. Sauf que le serveur derrière n'a rien à voir, et la commande d'installation à copier-coller a été modifiée.

L'astuce technique est intéressante. La commande PowerShell affichée n'est pas visible dans le code source qu'un scanner automatique pourrait analyser, elle est générée à la volée dans le HTML de la page. Du coup, les scans de sécurité voient du contenu légitime, l'utilisateur copie une commande malveillante, et paf, un loader PowerShell d'environ 600 Ko se lance discrètement.

Ce loader essaie ensuite quelque chose de carrément vicieux. Il abuse de IElevator2, une interface interne de Chromium (le moteur derrière Chrome, Edge, Brave, Vivaldi, Opera) lancée en janvier 2026 par Google pour mieux protéger les cookies et mots de passe avec un chiffrement renforcé. Le malware injecte un petit module dans le navigateur pour appeler cette interface depuis l'intérieur, ce qui lui permet de récupérer les clés et de déchiffrer toute la base. Cookies de session, mots de passe enregistrés, infos de paiement. Tout y passe.

Trois domaines pirates ont été enregistrés sur six jours en avril, tous derrière Cloudflare pour compliquer le takedown. Le bout de code utilisé ne correspond à aucune famille de malware connue (Lumma, StealC, Vidar). Le plus proche serait Glove Stealer, repéré en novembre 2024, mais avec une orchestration différente. Bref, ce serait un nouveau venu fabriqué exprès pour cette campagne.

Et la cible, c'est précisément les développeurs. Ce sont eux qui installent Claude Code (l'outil en ligne de commande d'Anthropic pour coder avec l'IA, concurrent direct de Cursor).

Et un développeur, dans son navigateur, c'est l'accès à GitHub, à AWS, à des dashboards de production, à des comptes Cloud, à des secrets qui se revendent potentiellement très cher. Les défenses classiques qui surveillent les exécutables natifs ne voient rien, tout se joue au niveau de l'appel COM (la mécanique Windows qui permet à des programmes de se parler entre eux) et de PowerShell.

Petit conseil : passez par anthropic.com directement, jamais par un résultat sponsorisé. Si vous avez collé une commande douteuse récemment, c'est le moment de regarder ce qui tourne sur votre machine.

Source : Infosecurity Magazine

Robots chiens Unitree - La backdoor que personne ne corrige

Par : Korben ✨
11 mai 2026 à 13:40

Si vous croisez un robot-chien Unitree dans un hall d'HLM, sur un parking, un chantier, ou en train de patrouiller dans votre ville, faut que vous sachiez 2 trucs quand même :

Un, n'importe qui peut le rooter en moins d'une minute avec son téléphone. Et de deux, le robot lui-même envoie en continu un flux chiffré vers un tunnel cloud opéré depuis la Chine. C'est en tout cas ce que Benn Jordan, musicien indépendant et chercheur amateur, vient de démontrer hier dans une enquête de 24 minutes qui fait, comme il le dit lui-même, un meilleur boulot que toute l'infrastructure cybersécurité du gouvernement américain.

Pour le hacker, suffit donc de se connecter au robot en Bluetooth, puis d'injecter une commande curl à la fin du mot de passe Wi-Fi, on éteint le toutou, on le rallume, et au reboot le robot exécute votre commande quand il active le Wi-Fi. C'est tout et c'est vraiment magique !! Pas besoin d'accès root physique donc mais juste un bon vieux téléphone et un Bluetooth pourri !

Le boss !

Alors vous pensez peut-être que ce n'est pas très grave parce que ces robots sont des gadgets mais c'est faux puisque les robots-chiens Unitree sont actuellement utilisés par les services de police de Pullman (Washington), Port St. Lucie (Floride) et Topeka (Kansas) et un peu partout ailleurs dans le monde.

Les Marines américains les déploient en test, certains armés de lance-roquettes, les forces chinoises leur sanglent diverses armes sur le dos depuis un moment et l'Ukraine s'en sert pour repérer des munitions non-explosées. Et dans le civil, ces robots circulent même dans des HLM d'Atlanta pour le compte de sociétés de surveillance privée...

En France, le tableau est un peu différent. Pas de déploiement confirmé par les forces de l'ordre ou l'armée pour l'instant. Chez nous, c'est Boston Dynamics Spot et l' E-Doggy d'Evotech (robot 100% français, utilisé au déminage pendant les JO 2024) qui tiennent ces marchés-là. Les Unitree restent encore dans les labos tels que l' INRIA Paris et le labo HUCEBOT de Nancy qui utilisent le Go2 pour leurs recherches en locomotion robotique.

En dehors de la recherche, le cas le plus avancé est celui d'Orano, qui a testé fin 2025 le G1 humanoïde d'Unitree sur son site nucléaire de Marcoule en partenariat avec Capgemini (c'est un humanoïde, pas un quadrupède, mais même fabricant, même firmware, mêmes questions). Côté distribution, INNOV8 Power est également partenaire officiel Unitree depuis VivaTech 2025 et INGEN Geosciences distribue la marque depuis 2020. Le réseau pour vendre ces robots à des boîtes de sécurité privées françaises est donc déjà bien en place.

Du coup quand un mec démontre qu'on peut en prendre le contrôle complet rapidement, ça mérite qu'on regarde ça d'un peu plus près...

Et quand je dis contrôle complet, c'est pas un excès de langage. Avec cet accès root, Benn Jordan a réussi à enregistrer, télécharger et live streamer l'audio et la vidéo captés par le robot. Sans authentification donc ni même sans passer par l'app officielle. C'est assez dingue... On peut même contrôler les mouvements du robot. Une belle merde donc !

Cette faille n'est d'ailleurs pas une nouveauté absolue puisque j'avais déjà couvert le hack BLE des humanoïdes Unitree en décembre dernier. Et ensuite rebelote en mars dernier avec deux nouvelles CVE sur le Go2, partiellement patchées. La répétition des conneries devient un peu lourdingue chez Unitree...

La deuxième partie de l'enquête, elle, atteint un autre niveau puisque Benn Jordan a entendu parler de rapports affirmant que d'autres robots Unitree contenaient une backdoor envoyant des données à des serveurs étrangers. Il a donc voulu vérifier ça lui-même.

Il a donc transformé un Raspberry Pi sous Linux en routeur avec le mode moniteur activé, et lancé BetterCap pour analyser chaque paquet sortant.

Et là, surprise, le robot refuse purement et simplement de s'authentifier. Le hic, c'est que quelque chose côté serveur cloud détecte que le routeur est anormal et bloque la connexion. En analysant un peu plus finement la connexion, il a remarqué que la première IP chopée au sniff pointait vers Odessa, en Ukraine... Vu qu'aucune doc fabricant ne mentionne ce point d'accès, le truc devient alors officiellement louche... Le robot semble savoir quand il est "analysé" et cette détection d'environnement anormal est précisément le truc qui transforme une affaire de faille classique en problème de sécurité nationale.

Benn Jordan a donc ensuite contourné ça avec un routeur de voyage standard avant de sniffer derrière les paquets, et il a fini par confirmer ce qu'on appelle officiellement la CVE-2025-2894 . Il s'agit d'un tunnel P2P préinstallé sur le Go1 qui se connecte automatiquement au démarrage à une plateforme appelée CloudSail, opérée par une boîte chinoise nommée Zhexi Technology.

Le truc est référencé dans MITRE depuis le printemps 2025, soit environ un an. En 2025, les chercheurs Andreas Makris et Kevin Finisterre ont même chopé la clé API de CloudSail et identifié près de 2000 robots vulnérables sur ce réseau, dont des unités installées au MIT, à Princeton, à Carnegie Mellon et à l'université de Waterloo.

Côté américain, la seule action gouvernementale connue suite à ça, a été une mise en garde des Marines US concernant l'usage de produits Unitree en opérations militaires. Rien d'autre.

Et là on arrive à un point de blocage assez brutal. Les failles démontrées par Benn (le hack Bluetooth, la prise de contrôle complète) et la backdoor CloudSail ne peuvent pas être corrigées en même temps, parce que les solutions se neutralisent mutuellement.

Pour boucher les failles de Benn, il faut passer par une mise à jour firmware officielle d'Unitree. Mais cette mise à jour ferme aussi l'accès root au système. Sans accès root, impossible de détecter ou bloquer le tunnel CloudSail de l'intérieur. Du coup, on a un robot sécurisé contre les hackers, mais des données qui filent quand même vers la Chine.

À l'inverse, si vous gardez le firmware actuel pour maintenir l'accès root (et donc la capacité de surveiller et bloquer CloudSail), les failles restent béantes. N'importe quel inconnu avec un téléphone peut alors prendre le contrôle complet de votre flotte de robots clébards. Bien sûr, couper Internet sur le robot évite les deux problèmes à la fois, mais le rend inutilisable dans la plupart des déploiements opérationnels.

Si vous avez un Unitree à la maison ou en entreprise, voilà la recommandation perso de Benn Jordan. Selon lui, plutôt que d'installer la dernière mise à jour, mieux vaut ne plus jamais mettre à jour le firmware (gardez en tête que c'est son avis radical, pas une bonne pratique standard). Parce qu'à la prochaine mise à jour, vous risquez de perdre la capacité de rooter votre propre robot, et avec elle la capacité de détecter, bloquer ou rediriger la backdoor.

Vous perdrez aussi la possibilité d'écrire manuellement des services qui empêchent les hackers d'exploiter les autres failles. En clair, sa meilleure défense contre Unitree, c'est de figer le firmware actuel.

Un Flipper Zero suffisait déjà à neutraliser un robot-chien de la concurrence, mais ici "couper" le robot de son fabricant pour s'en protéger, c'est un autre délire...

Source

Les données de 120 000 adhérents LFI dans la nature

11 mai 2026 à 13:14

Un hacker au pseudo "fuzzeddffmepg" a balancé sur un forum cybercriminel le 7 mai une base de données présentée comme provenant d'Action Populaire, le réseau militant numérique de la France Insoumise.

Au programme : environ 120 000 adresses email uniques, 20 000 numéros de téléphone, et un paquet de données personnelles couvrant pratiquement neuf ans d'activité, de 2017 à 2026.

Le contenu de la fuite est franchement gênant pour les adhérents. On y trouve les noms et prénoms des utilisateurs, leurs adresses email et numéros de téléphone, leurs adresses postales liées à des paiements, leurs participations à des groupes et événements, mais aussi des messages privés et échanges internes, plus des données de paiement et d'abonnement.

La période couverte va de 2017 à 2026, soit pratiquement toute l'histoire d'Action Populaire en tant que plateforme militante. Le hacker affirme avoir exploité une faille sur une infrastructure décrite comme obsolète, et il menace de publier d'autres extractions, dont des serveurs de messagerie.

Côté LFI, aucune confirmation officielle pour le moment. Silence radio. Ce qui n'est pas franchement la meilleure stratégie quand vos propres adhérents lisent partout sur le web que leurs données traînent en libre service.

La situation a un goût particulièrement improbable parce que LFI venait justement de déposer une proposition de résolution pour créer une commission d'enquête parlementaire sur "l'accumulation et la fuite de données personnelles en France". Sauf que voilà, demander une enquête sur les fuites pendant qu'on se fait fuiter, c'est un peu tendu.

Au passage, ce hack n'est pas isolé. Depuis quelques mois, les fuites se multiplient en France, du public au privé : CPAM, Parcoursup, ANTS, et maintenant un parti politique. Le hacker a clairement expliqué viser une infrastructure obsolète, et c'est un peu le même refrain qu'on entend partout sur l'état général de la sécurité des plateformes hébergées en France.

Concrètement, les risques pour les adhérents exposés sont réels. L'appartenance politique étant une donnée sensible au sens du RGPD, ces 120 000 personnes peuvent désormais s'attendre à des campagnes de phishing très ciblées, du harcèlement téléphonique en règle, et possiblement de l'usurpation d'identité.

Pour les militants, c'est franchement pénible. La CNIL devrait normalement être saisie par le parti dans les 72 heures suivant la prise de connaissance de l'incident~~, mais sans communication officielle, impossible de savoir si cette obligation a été respectée~~. Mise à jour : la LFI a bien prévenu ses membres et adhérents !

Screenshot

Bref, une infrastructure à l'abandon finit toujours par parler. Et ça tombe pile quand LFI réclamait plus de protection des données. Joli timing.

Source : French Breaches

myAudi permettaient de localiser un véhicule à partir de son code VIN

Par : Korben ✨
11 mai 2026 à 11:49

Le numéro VIN de votre voiture est visible sur le bas du pare-brise et récupérable par n'importe qui qui passe à côté. Et croyez le ou non, mais c'est pourtant sur ce numéro, visible de tous, que repose en partie le modèle de sécurité de myAudi, l'application connectée pour contrôler son véhicule Audi à distance.

Un chercheur qui se présente sous le pseudo Decoder a décidé de regarder ça de plus près. Son setup c'est un émulateur Android Pixel 7, Burp Suite en proxy pour intercepter le trafic réseau ainsi que Frida Server et Objection pour contourner le certificate pinning de l'app. Des outils et du boulot classique de pentest mobile, pas particulièrement sophistiqué donc...

Et ce qu'il a découvert grâce à ça, c'est que n'importe quel utilisateur myAudi peut ajouter le véhicule de quelqu'un d'autre à son compte en entrant simplement le VIN. Le rôle attribué est "GUEST_USER" donc au premier abord, ça peut sembler anodin mais ça donne quels accès, au juste ? Hé bien on va voir ça car c'est pas si simple.

Tout d'abord, l'introspection GraphQL est activée en production sur l'API de myAudi, ce qui revient à laisser un plan d'architecte en libre accès dans le hall d'entrée d'une banque. N'importe qui peut donc cartographier l'intégralité des fonctionnalités exposées.

Plus sérieux et toujours pas patché à l'heure de la publication, via l'API msg.audi.de, un utilisateur avec le rôle GUEST_USER peut aussi récupérer l'IMEI et l'ICCID de la carte SIM embarquée dans le véhicule. Ces identifiants permettent alors potentiellement de tracer la carte SIM sur les réseaux mobiles.

Et là, la faille qui a été corrigée depuis, ce sont celles concernant les "requêtes en attente" d'un véhicule qui étaient lisibles par n'importe quel "invité". Parmi elles, les commandes "honk & flash" (klaxon + appels de phares) qui contenaient la position GPS de la voiture. Du coup, avec juste un VIN, on pouvait savoir physiquement où se trouvait la voiture... Ça rappelle un peu comment les données Strava avaient suffi à localiser le porte-avions Charles-de-Gaulle en pleine mission.

Et derrière tout ça, il y a CARIAD, la filiale "software" du groupe Volkswagen dont j'avais déjà évoqué les difficultés l'an dernier, et qui gère les services numériques pour VW, Audi, Seat et Skoda.

CARIAD a donc patché la faille GPS mais pour le reste, c'est encore "under evaluation". Je rappelle que c'est la même filiale qui, en décembre 2024, avait exposé les données de 800 000 véhicules électriques via une mauvaise configuration AWS, avec des coordonnées GPS précises à 10 centimètres près pour les modèles VW et Seat. Le Chaos Computer Club l'avait découvert, et des politiciens, des chefs d'entreprise et des forces de l'ordre se trouvaient dans le lot des données exposées...

Donc bon, y'a encore un peu de taf pour sécuriser ces voitures un peu trop connectées... En tout cas, l'analyse de Decoder est disponible sur son blog si ça vous dit. De son côté, il précise continuer à creuser l'architecture CARIAD car y'a sûrement d'autres trucs rigolo à trouver.

On verra bien...

JDownloader a diffusé des versions piégées, votre PC est peut-être compromis

11 mai 2026 à 10:58

Entre le 6 et le 7 mai 2026, le site officiel jdownloader.org a été compromis et a servi pendant un peu plus d'une journée des installeurs piégés à la place des versions légitimes du célèbre gestionnaire de téléchargements.

Concrètement, les liens alternatifs pour Windows et l'installateur shell pour Linux ont été remplacés par un loader qui déploie un RAT (Remote Access Trojan) écrit en Python sur la machine de la victime. Pour ceux qui ne connaissent pas, un RAT donne à l'attaquant un contrôle total à distance de votre PC : exécution de commandes, vol de données, installation d'autres malwares, et tout ce qui peut se faire avec un compte utilisateur compromis.

Bonne nouvelle dans le malheur. Tous les canaux de distribution n'ont pas été touchés. La version macOS est passée à travers, pareil pour les installations via Flatpak, Winget et Snap, ainsi que pour le package JAR principal de JDownloader. Seuls les liens "alternative download" Windows et le script shell Linux du site officiel sont contaminés. Si vous utilisez ces canaux pour vous mettre à jour, c'est sur eux qu'il faut vérifier.

Le problème a d'abord été relevé par un utilisateur Reddit, "PrinceOfNightSky", qui a constaté que les exécutables téléchargés étaient signalés par Microsoft Defender et signés par des éditeurs douteux (Zipline LLC, The Water Team) au lieu de la signature légitime AppWork GmbH.

Une fois alerté, le développeur de JDownloader a confirmé la fuite, mis le site hors ligne, et publié un rapport d'incident détaillé pour permettre l'analyse externe. La porte d'entrée des attaquants ? Une vulnérabilité du CMS du site qui permettait de modifier les listes de contrôle d'accès et le contenu sans authentification. Pas génial.

Le malware Windows fonctionne en deux étages. Un petit programme téléchargé sert de loader, qui récupère et exécute ensuite le vrai payload en se connectant à deux serveurs de commande nommés parkspringshotel[.]com et auraguest[.]lk. Architecture modulaire, ce qui veut dire que l'attaquant peut envoyer le code Python qu'il veut depuis ses serveurs et adapter sa charge en temps réel. Vol de mots de passe, persistance, mouvement latéral sur le réseau local, tout y est possible.

Si vous avez téléchargé JDownloader depuis le site officiel entre le 6 et le 7 mai, faites donc très attention. Réinstallez complètement l'OS et changez tous vos mots de passe. Un RAT donne suffisamment d'accès pour qu'un nettoyage par antivirus seul ne soit pas une garantie suffisante. Pénible mais c'est le seul moyen propre.

Source : Bleeping Computer

GitHub commit spoofing - Quand n'importe qui peut être Linus

Par : Korben ✨
10 mai 2026 à 16:06

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...

Pourquoi Git laisse passer ça

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.

Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)

Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :

# 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.

Étape 2 : Repérer un commit douteux

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...

Étape 3 : Signer vos commits avec SSH

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 .

Étape 4 : Activer Vigilant Mode

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.

La position de GitHub (et pourquoi je trouve ça discutable)

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é ^^.

Source

Hash MD5 - 60% des mots de passe craqués en moins d'une heure

Par : Korben ✨
8 mai 2026 à 16:52

60% des mots de passe hashés en MD5 peuvent être cassés en moins d'une heure... C'est ce que dit en tout cas une étude de Kaspersky publiée cette semaine qui se base sur +231 millions de mots de passe qu'on peut trouver sur le dark web et tirés de fuites ayant eu lieu entre 2023 et 2026. D'après leurs tests, 48% sont craqués en moins d'une minute et 60% en moins d'une heure. C'est pas très rassurant, surtout si votre base tourne encore au MD5.

Ce qui a changé ces dernières années, c'est surtout la puissance des GPU modernes qui n'a cessé d'augmenter. Par exemple, une RTX 5090 monte à 220 milliards de hash MD5 par seconde ce qui représente une augmentation de +34% par rapport à la RTX 4090 ! Du coup, louer un GPU cloud pour lancer une attaque par dictionnaire revient à quelques dizaines de centimes à quelques dollars de l'heure. C'est rentable hein ?

L'étude souligne aussi que 53% des mots de passe du corpus se terminent par des chiffres. Et là, du point de vue des règles hashcat, c'est du pain bénit car les crackers adorent la prévisibilité. Alors attention si vous administrez un service web avec une gestion de comptes utilisateur car les attaques modernes (dictionnaire + règles hashcat) règlent aujourd'hui son compte à une bonne partie du corpus et cela en moins d'une minute. Par contre, les mots de passe longs avec symboles variés résistent encore puisque c'est exponentiel ! Vaut mieux une phrase de passe avec plein de mots et facile à retenir du genre running-douche-afford-laborer-art-amber-deftly-acetone-lego-reoccupy qu'un mot de passe court et complexe comme 3d2^vO$RZ1.

Bref, MD5 pour les mots de passe c'est mort donc si vous avez encore ça dans vos bases, migrez moi tout ce bordel rapidement ! La migration maintenant, ça se fait vers Argon2id en priorité... Je balance pas ça au pif, hein, c'est le standard recommandé par OWASP et le NIST, et c'est memory-hard, donc les GPU ne peuvent pas juste brute-forcer des milliards de hashs par seconde comme avec MD5.

Après si votre stack est ancienne et qu'Argon2id n'est pas dispo, bcrypt reste une option solide. Dans tous les cas, évitez SHA-1, SHA-256 ou SHA-512 sans algorithme adaptatif car ils sont rapides par conception, donc tout aussi crackables que MD5.

Source

Dirty Frag - L'exploit kernel Linux qui donne un accès root sur toutes les distros

Par : Korben ✨
8 mai 2026 à 10:47

Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.

L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.

Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!

La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.

Alors comment ça marche ?

Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.

Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.

Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.

Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.

Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.

Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.

Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.

En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.

Tester avec Lima sur macOS

Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :

# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :

Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :

echo 3 > /proc/sys/vm/drop_caches

Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.

Alors que faire ?

Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.

Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...

En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.

Source : https://github.com/V4bel/dirtyfrag

Surfshark sort Dausos : le protocole VPN qui pense enfin à vous

Par : Korben ✨
7 mai 2026 à 07:25
-- Article en partenariat avec Surfshark VPN --

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 en détail : pas une adaptation, une création native

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.

Les briques techniques qui font la diff

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 à 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.

Les gains concrets pour votre quotidien

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.

Comment l'activer et disponibilité

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 :

  1. Installez/mettez à jour vers la dernière version Surfshark depuis l'App Store macOS.
  2. Allez dans Paramètres > Paramètres VPN.
  3. Protocole > Sélectionnez Dausos.
  4. Connectez-vous à un serveur.

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'en pense pour de bon

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 refé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.

Le tarif du moment

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.

Profitez de l'offre !

*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.  *

Scattered Spider - Un cybercriminel arrêté à cause d'un collier en diamants

Par : Korben ✨
6 mai 2026 à 15:06

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"

Source

Quand les hackers de Rockstar font monter l'action Take-Two

Par : Korben ✨
6 mai 2026 à 14:35

Énorme retournement de situation. ShinyHunters, le groupe qui avait piraté Rockstar via Anodot mi-avril et exigé une rançon, a fini par balancer ses données sur internet quand l'éditeur a refusé de payer. Le but était de faire mal financièrement à Take-Two, sauf que les chiffres révélés étaient si impressionnants que l'effet a été l'exact opposé. En effet, l'action Take-Two est passée d'environ 202 dollars à presque 208 dollars en une matinée, soit une capitalisation boursière qui a pris à peu près un milliard de dollars dans la foulée. C'est fou !

Ce que les hackers ont mis en ligne, c'est notamment que GTA Online génère plus d'un million de dollars par jour , soit autour de 500 millions par an. Et tout cela, 13 ans après le lancement sur 5 plateformes différentes, simplement grâce aux Shark Cards (les cartes prépayées du jeu). Pour un éditeur qui s'apprête à sortir son GTA 6 en novembre prochain, faut dire que ce genre de stats montre qu'ils ont les reins hyper solides, ce qui rassure les investisseurs.

Bref, au lieu de sanctionner Take-Two pour la fuite de données et la faille Anodot, Wall Street y a simplement vu la confirmation de ce que tout le monde soupçonnait : la machine à cash de Rockstar tourne à plein régime, et un éventuel GTA 6 au même niveau de monétisation, même partielle, ferait exploser les compteurs !!

Rockstar a également publié une déclaration courte et carrée pour dire que la violation n'aurait pas d'impact sur le studio ou le dev de GTA 6. Rien de plus...

C'est donc un retournement de situation assez fou côté où des hackers, en cherchant à frapper l'éditeur au portefeuille, lui ont en fait permis de gonfler sa capitalisation d'un milliard. Difficile de faire pire en termes de coup raté ^^. A moins que les gens de ShinyHunters aient fait un peu de délit d'initié en amont avant de leaker les données... allez savoir ??

Reste à voir si la SEC ou les autorités européennes voudront enquêter sur cette fuite, sachant qu'au passage des données salariés et de joueurs ont aussi été exposées. Quoiqu'il en soit, côté marché, c'est plié et le cours de l'action est resté bien haut !

Source

❌
❌