Benjamin Code , le développeur préféré de votre développeur préféré, a reçu ce week-end un e-mail d'achat bidon avec le mot pentester dedans. En grattant un petit peu, il a découvert que quelqu'un s'amusait à trifouiller l'un de ses SaaS sans le prévenir.

Visiblement, c'est un autre créateur, Melvyn (melvynx), qui lui propose des formations autour de l'IA, qui pour les besoins d'une vidéo a fait tourner Kimi K3 en mode "hack" pour poutrer certains sites et montrer, vidéo à l'appui, que l'IA trouvait les failles toute seule.

Depuis, X s'écharpe. D'un côté, ceux pour qui la faille est corrigée et tout le monde y gagne, zéro dégât. De l'autre, ceux qui parlent d'accès illégal, pur et simple.

Alors qu'en est-il exactement ?

Eh bien, parlons de la loi d'abord, parce qu'en France, elle est limpide. L'article 323-1 du Code pénal punit "le fait d'accéder ou de se maintenir, frauduleusement" dans un système informatique de "trois ans d'emprisonnement et de 100 000 € d'amende". Créer un faux compte, simuler un paiement avec de faux numéros de CB, toucher aux données, ça aggrave les choses et on passe rapidement à cinq ans et 150 000 € (article 323-3).

Pour moi, l'argument du "il n'a rien cassé" ne tient pas une seconde en droit. Dans l'affaire Bluetouff, la Cour de cassation a validé une condamnation pour maintien frauduleux alors que les fichiers étaient accessibles sans mot de passe, tout simplement parce que Bluetouff avait continué en sachant l'accès anormal. Je trouve que ce qui est arrivé à Bluetouff, c'était abusé, mais peu importe mon avis, cela montre bien qu'aux yeux de la loi, zéro dégât ne veut pas dire qu'il n'y a pas d'infraction.

Ce qui fait basculer un pentest légal en délit, ce n'est ni la compétence, ni la bonne intention de la personne derrière, ni même ce que j'en pense. C'est UNE seule chose : L'autorisation préalable du propriétaire du système. Et je ne crois pas que Benjamin Code pratique le bug bounty sur ses systèmes...

Si on parle d'un point de vue hacking éthique, voire tout simplement en matière de nétiquette, la règle (et le bon sens, et la courtoisie) c'est d'abord d'avoir l'accord écrit avant de faire le test, et puis bien sûr de signaler la faille en privé à l'éditeur, tout en lui laissant assez de temps pour la corriger avant de communiquer dessus publiquement.

Par exemple, un bug bounty, c'est ça... C'est un périmètre défini, un canal de signalement, une protection pour le chercheur qui reste bien dans ce cadre. En dehors, il n'y a aucune protection. Et le dispositif français qui couvre les lanceurs d'alerte (article L2321-4 du Code de la défense) ne protège que le signalement de bonne foi à l'ANSSI, jamais l'intrusion elle-même.

Melvyn a reconnu lui-même juste après son "exploit" que "certains tests sur des SaaS tiers n'ont pas été précédés d'une autorisation écrite". Tu m'étonnes...

Alors les kikoulol de X.com peuvent bien jouer les spécialistes en long en large ou en travers, ça ne change rien. Kimi K3 ou pas, dégâts ou pas, tester le système d'un autre sans son feu vert, même avec une IA autonome, ça a un nom dans le Code pénal...

Maintenant, je ne pense pas que ça ait besoin d'aller plus loin que ça... Dans un monde idéal, ce qui serait super, c'est que Melvyn fasse des excuses publiques à Benjamin Code et aux autres créateurs de SaaS qu'il a "poutrés", et puis qu'il évite de refaire ce genre de conneries dans le futur.

Source : le billet de Melvyn sur Codelynx

727 mots de passe testés par seconde, c'est le score incroyable d'une Game Boy Advance reprogrammée en casseur de mots de passe par solst-ice, un développeur qui avait visiblement une console de 2001 qui traînait et pas mal de temps à tuer ^^. Son projet s'appelle GBA-Hashcat, et c'est un "port" de hashcat (le célèbre outil de crackage) sur le petit hardware portable de Nintendo.

Enfin, un port entre grosses guillemets, parce que le vrai hashcat gère plus de 300 algorithmes de hash optimisés et une palanquée de méthodes d'attaque alors que là, vous avez le droit à un seul truc, du SHA-256, et rien d'autre.

Le programme embarque la wordlist ignis-1M, une liste de 8 Mo qui contient environ 1 million de mots de passe parmi les plus courants. Pour chaque ligne, la GBA calcule le hash SHA-256, le compare à un hash cible codé en dur dans le programme, et regarde si ça correspond.

C'est une attaque par dictionnaire, quoi, sauf que, je vous rappelle, ça tourne sur une puce ARM7TDMI cadencée à 16,78 MHz avec 288 Ko de RAM.

Du coup, forcément, ça rame de fou... au rythme de 727 hachages par seconde mais c'est normal car cette console n'a jamais été pensée pour ce genre de calcul. Pour vous donner une idée, un PC moderne avec un GPU décent va environ 30 millions de fois plus vite, soit des milliards de tentatives par seconde.

Alors que la GBA, elle, met une bonne vingtaine de minutes à avaler toute sa liste de 1 million de mots.

Après côté bidouille c'est assez fort car, certes, la wordlist de 8 Mo tient dans la cartouche, mais faire tourner une routine SHA-256 propre sur une puce aussi poussive, avec ses malheureux 288 Ko de RAM pour bosser, il faut le vouloir ! Solst-ice s'est donc appuyé sur le moteur Butano, un framework C++ open source taillé pour développer des jeux GBA, qu'il a détourné pour faire mouliner des hashs à la place de sprites.

Et voilà, ce projet loufoque rejoint la longue tradition des gens qui font faire n'importe quoi à leur Game Boy Advance, comme ce clavier GBA à monter soi-même que je vous montrais récemment.

Bref, comme un ministre ou un notaire, ça ne sert strictement à rien, et c'est pour ça qu'on kiffe ! Le code est sur le GitHub de solst-ice si vous voulez jouer.

Source

Un chercheur en sécurité nommé Ian Carroll s'est amusé à lâcher Claude Opus sur la billetterie de Live Nation, afin d'y trouver des failles de sécurité, et l'IA lui a carrément écrit toute la chaîne d'exploitation sans aucune aide. Lui n'a eu qu'à le lancer...

Tout démarre avec une session de fuzzing sur l'API des terminaux, fgtapi.frontgatetickets.com. Carroll repère un truc... chaque endpoint qui contient le mot "device" réclame un paramètre deviceUID, et ce paramètre ne demande aucune authentification. Il colle un simple guillemet à la fin, la requête se met à ramer, et là, signe classique, le paramètre file direct dans une requête SQL sans le moindre échappement.

Une injection SQL bien à l'ancienne (si vous voulez voir à quoi ça ressemble, j'avais déjà décortiqué le principe il y a un bail).

Sauf qu'un WAF AWS est planté devant pour bloquer ce genre de payload. Et c'est là que Claude entre en scène. L'IA pige toute seule que le pare-feu n'inspecte que la couche extérieure de la requête, et qu'il suffit de planquer l'injection dans une sous-requête imbriquée pour passer sous le radar.

Ensuite elle se fabrique un oracle booléen aveugle qui fait que selon que la condition testée est vraie ou fausse, le serveur renvoie deux réponses différentes, "MC70-023" pour vrai, "Intellitix Upload" pour faux. Vous enchaînez ensuite les questions oui/non, et vous reconstituez la base entière, caractère par caractère.

Et la base, elle est bien garnie. Plus de 500 tables dans un ensemble baptisé fgs avec dedans les emails et mots de passe du personnel, ceux des clients, les tokens de reset, les tokens d'API et les jetons OAuth encore actifs. Avec ça, Carroll précise qu'il aurait pu émettre autant de billets gratuits qu'il voulait, pour n'importe quel événement.

Mais c'est une personne pleine de sagesse (et qui ne veut pas aller en prison) alors il ne l'a pas fait. Et surtout, il a tout remonté à Live Nation. Le lendemain où il les a contactés, la boîte confirmait le déploiement d'un correctif.

Ce qui est intéressant ici, c'est que le contournement du WAF par sous-requête, et la construction de l'oracle, tout ça a été proposé par Claude, et ne vient pas d'une demande du chercheur. On avait certes, déjà vu l'IA d'Anthropic dénicher des failles dans Firefox ou éplucher du code Apple II vieux de 40 ans mais là, c'est un sacré cran plus loin, je trouve.

Merci à Ian Carroll pour le writeup détaillé .

Source : CyberSecurityNews

Vous vous souvenez du streamer Twitch qui s'était fait piquer sa caisse en plein live, à cause d'un boîtier bizarre posé contre sa porte d'entrée ?

Tout le monde a crié au fake évidemment, sauf que dans une certaine mesure, c'était vrai ! Et le voleur, c'était Mark Rober en personne, l'ex-ingénieur de la NASA devenu YouTubeur, qui a inventé toute cette mise en scène pour démontrer une bonne fois pour toutes comment on vole une voiture récente sans même toucher à la serrure.

La méthode s'appelle la relay attack, l'attaque par relais, et le principe est tellement simple que c'en est gênant. En effet, les voitures passent leur vie à chuchoter, quatre fois par seconde environ, des petits "hé psst, t'es là, ma clé ?". Et quand la clé est assez proche pour entendre ce murmure, elle hurle en retour le mot de passe secret qui déverrouille les portes et permet de démarrer le véhicule. Sauf que ce chuchotement, une équipe de voleurs peut le capter depuis votre voiture, l'amplifier, et le balancer jusqu'à votre clé restée sur le meuble de l'entrée ou dans la poche de votre veste. La clé croit alors que la voiture est juste là, elle répond, et hop, la caisse s'ouvre. Ça prend 30 secondes chrono, ça ne déclenche aucune alarme, et surtout y'a aucune effraction, ce qui arrange bien ces inutiles d'assureurs.

Alors pour bien comprendre comment tout ceci fonctionne, Rober a voulu s'équiper comme un vrai voleur. Direction le dark web, où un certain Dimitri (un russe... Bah quoi les clichés ?) lui a vendu un boîtier de vol clé en main pour 12 000 dollars en Bitcoin. L'appareil arrive, il le passe au CT Scan pour voir ce qu'il y a dedans sans le faire péter, et le verdict tombe : il s'est fait escroquer comme un débutant.

En fait, tous les composants hors de prix de ce machin pouvaient être remplacés par la même chose que ce qu'on trouve dans un babyphone vidéo de 2004.

Le babyphone de 2004 dont les entrailles remplacent un boitier dark web a 12 000 dollars.

La caméra du babyphone capte un signal, l'antenne le transmet à l'écran déporté et il suffit de couper deux fils au bon endroit pour transformer ça en relais radio . Son clone maison lui est donc revenu à quelques centaines de dollars de matos au lieu des douze mille que Dimitri a empochés. Et surtout il fonctionnait mieux que l'original. Breeeef...

Avant ce genre d'attaque, voler une bagnole demandait quand même un peu de doigté. Le slim jim, une tige métallique qu'on glissait dans la portière, a été tué dans les années 90 par les constructeurs qui ont blindé les mécanismes de serrure. Le démarrage en pontant les fils façon Mac Gyver est devenu inutile le jour où un calculateur ECU a pris le contrôle du moteur. Et plus récemment, vous avez peut-être entendu parler des Kia Boys , ces ados qui ont fait le tour de TikTok en démarrant des Kia et Hyundai d'avant 2022 avec un simple câble USB enfoncé dans le contact.

C'était couillon, mais ces modèles n'avaient pas d'antidémarrage électronique... une économie de bout de chandelle des constructeurs qui leur a quand même coûté 8,3 millions de véhicules à patcher en urgence. Comme quoi, la sécurité par l'obscurité, ça finit toujours par se payer un jour ou l'autre...

Et est-ce que vous saviez ce que deviennent ces voitures une fois envolées ??

Eh bien, même si l'essentiel des vols est l'œuvre d'abrutis d'ados qui font joyride pour Instagram , le reste est récupéré par une filière criminelle très organisée, démonté en pièces détachées dans un atelier en moins d'une heure ou encore expédié en conteneur à l'autre bout du monde.

Maintenant, pour bloquer les attaques relais et toutes ses déclinaisons, il suffit d'empêcher votre clé d'entendre ce "chuchotement" de la voiture. La première règle, qui est aussi la plus bête, est donc de ne JAMAIS poser vos clés près de la porte d'entrée... Éloignez-les au maximum, à l'autre bout de votre logement si vous le pouvez

Et la deuxième règle, c'est d'empêcher la clé de capter quoi que ce soit... Une boîte à biscuits en métal fait par exemple parfaitement l'affaire. Ou alors un bout de papier alu pour l'emballer...

Une simple boite a biscuits en métal suffit a rendre la clé sourde.

C'est ce qu'on appelle une cage de Faraday dans laquelle le signal radio préfère filer dans le métal conducteur plutôt que de traverser. Les pochettes anti-RFID vendues une dizaine d'euros font pareil et sont quand même plus classe, mais testez-les avant de leur faire réellement confiance.

Ah et sinon, sur certains modèles comme ma Ioniq 5 , vous pouvez aussi désactiver l'ouverture automatique "à distance via la clé et "sans les mains" et exiger une pression sur le bouton de la clé. C'est plus safe même si c'est moins fun ^^.

Un grand merci à Lilian pour le partage.

Oliver Sieber, un chercheur de chez Exodus Intelligence, vient de publier l'exploit complet d'une faille qui tient dans un seul caractère. C'est la CVE-2026-23111, planquée dans nf_tables, c'est à dire au bout du noyau Linux qui filtre les paquets réseau. Un bug discret donc, qui transforme un compte tout pourri, sans le moindre privilège, en compte root sur la machine... et qui vous fait sortir d'un conteneur au passage.

Le scénario, vous le connaissez si vous traînez ici depuis un moment. Un utilisateur qui dispose d'un compte sans droit particulier sur une machine Linux (y compris parce qu'il a exploité une autre faille avant, dans une appli web par exemple) lance l'exploit, et se retrouve avec les pleins pouvoirs. Pas de vecteur distant, rien à cliquer : c'est l'arme qu'on dégaine une fois le pied dans la porte. Que ce soit un shell avec des droits limités, un conteneur compromis, un compte de service... tout y passe et hop, root sur l'hôte !

Le bug lui-même, c'est ce qu'on appelle un use-after-free, c'est à dire que le noyau réutilise un bout de mémoire qu'il a déjà libéré, et forcément ça part en vrille. Exodus a titré son analyse complète "Off By !", un clin d'œil au classique off-by-one des développeurs, sauf qu'ici le coupable c'est un test inversé. Un caractère de trop, une condition qui dit l'inverse de ce qu'elle devrait, et voilà. Et le correctif, lui, tient en une seule ligne.

Le fameux caractère : le ! qui inversait le test dans nft_map_catchall_activate(). Le correctif le retire, et c'est tout (commit 8fdb05de).

La faille a d'ailleurs été reproduite deux fois, par deux équipes qui ne se sont pas concertées. Exodus l'a validé sur Debian Bookworm, Debian Trixie, Ubuntu 22.04 et 24.04. FuzzingLabs avait sorti sa propre version dès avril, par un chemin complètement différent, et l'avait fait tourner sur RHEL 10 juste avant le Pwn2Own de Berlin. Bref, ça marche, c'est bien documenté, et c'est public.

Mais le pire, c'est le calendrier de tout ce merdier puisque le patch a été mis à dispo le 5 février. Ensuite, y'a eu l'exploit de FuzzingLabs publié le 16 avril, suivi d'un write-up détaillé d'Exodus le 8 juin. Autrement dit, ça fait des mois que le correctif existe et des semaines que le code d'exploitation traîne dans la nature.

La seule chose qui vous sépare donc d'un compte root offert à n'importe qui, c'est d'avoir mis à jour ou pas.

Et cette faille s'ajoute à une sacrée série de failles root-local sur Linux ce printemps. Y'a eu Copy Fail , y'a eu Dirty Frag et sa variante Fragnesia ... à chaque fois le même refrain, un compte sans droit qui finit root sur une install standard. C'est devenu presque routinier, et Synacktiv pointe une raison plutôt pertinente en nous expliquant que c'est à cause (ou grâce ^^) aux outils d'IA qui décortiquent les patchs pour en sortir un exploit rapidos, qui marche direct avant même que la correction soit déployée partout.

Du coup, qu'est-ce que vous devez faire ?

Hé bien le plus simple d'abord, c'est de mettre à jour le noyau et vous rebootez. Ubuntu a corrigé 22.04, 24.04 et 25.10, Debian a patché Bookworm et Trixie (avec un backport en 6.1 pour Bullseye), et Red Hat, SUSE et Amazon Linux ont suivi. Comme la version corrigée exacte dépend de votre distrib, jetez donc un œil à l'advisory qui correspond à la vôtre.

Si vous gérez une machine où tournent des utilisateurs ou des workloads pas franchement de confiance, vous pouvez également couper le chemin d'attaque sans attendre le patch. La faille a besoin des user namespaces non privilégiés, un mécanisme qui laisse un process lambda se bricoler son propre bac à sable avec des droits root à l'intérieur.

Et nf_tables comme ces namespaces, sur la plupart des desktops et pas mal de serveurs, c'est actif par défaut, donc oui, sans le patch vous êtes probablement exposé.

Pour les désactiver, le plus universel c'est user.max_user_namespaces=0 : un sysctl -w user.max_user_namespaces=0 pour tout de suite, et la même ligne dans un fichier genre /etc/sysctl.d/99-userns.conf pour que ça tienne au reboot.

Ça marche sur toutes les distros mais c'est radical, ça coupe tous les user namespaces, même ceux de root. Sur Debian et les vieilles Ubuntu, t'as plus fin avec kernel.unprivileged_userns_clone=0 qui ne vise que les non-privilégiés. Et sur Ubuntu 24.04, bonne nouvelle, c'est déjà restreint par défaut via AppArmor. Attention quand même, ça peut casser des trucs qui s'appuient dessus, genre le bac à sable de Chrome ou Flatpak.

À faire en connaissance de cause, donc.

La parade en vrai : une fois les user namespaces non privilégiés coupés, un compte lambda qui tente d'en créer un (le prérequis de l'exploit) se fait jeter sur un "No space left on device".

Après la bonne nouvelle, c'est que d'après les chercheurs, aucune exploitation dans la nature pour cette faille précise n'a été constaté à ce jour. Après comme sa cousine Copy Fail, elle, a déjà atterri au catalogue des failles activement exploitées de la CISA, ne traînez pas trop. Bref, comme d'hab padpanik, vous mettez à jour, vous rebootez, et on n'en parle plus.

Source

Flipper Devices, les gens derrière le fameux Flipper Zero , viennent de dévoiler leur prochain joujou, le Flipper One . Et leur annonce démarre par cette phrase de Pavel Zhovner, le co-fondateur : « on est franchement terrifiés, et on a besoin de vous ».

Apparemment, ce nouveau projet l'angoisse et faut être honnête, y'a de quoi. Car le Flipper One, ce n'est pas un Flipper Zero en plus gros. C'est carrément un mini-PC Linux ARM de poche, pensé comme un couteau suisse pour le réseau. Et là où le Zero causait uniquement aux protocoles de proximité (NFC, RFID, sub-GHz, infrarouge), le One joue dans la cour du dessus, en s'adressant également au monde IP, donc tout ce qui est Wi-Fi, Ethernet, 5G et même satellite. Ahaha, j'adore !

Et côté tripes, s'ils tiennent leurs promesses, ça va envoyer du lourd ! En effet, on va y retrouver un Rockchip RK3576 8 cœurs cadencé avec GPU Mali et un NPU pour faire tourner des modèles d'IA en local, 8 Go de RAM, deux ports Gigabit Ethernet indépendants, du Wi-Fi 6E qui gère le monitor mode, un modem 5G en module M.2, et une sortie HDMI 2.1 en 4K.

En gros, vous avez un routeur, un analyseur de signaux et un thin client réunis dans un truc qui tient dans la poche.

Puis y'a surtout ce truc de "double cerveau" avec à côté du gros CPU, un microcontrôleur RP2350 (celui du Raspberry Pi Pico 2) en plus qui pilote l'écran, les boutons et l'alimentation. Comme ça, même quand le Linux est éteint, l'appareil reste vivant et vous pouvez toujours gérer le boot et l'affichage sans réveiller le monstre.

Mais le vrai sujet de cette annonce, ce n'est pas la fiche technique. C'est l'ouverture du bestiau car le Flipper One vise un noyau Linux pur, celui de kernel.org, sans patch vendeur, ni blob binaire ou autres drivers proprio. C'est un truc de puriste qui va faire plaisir à tous les barbus !

Parce que oui, chez Flipper Devices, ils en ont marre des fabricants ARM qui balancent leurs « board support packages » crades que personne ne comprend, comme le fait Raspberry Pi au passage. Alors pour y arriver, ils bossent à fond avec Collabora afin de pousser le support du RK3576 directement dans le kernel officiel.

Et c'est là qu'arrive le « we need your help » car plutôt que de bidouiller dans leur coin, ils ouvrent d'un coup tout le processus de développement dès le premier jour. Leurs trackers de tâches, leurs débats d'architecture, leurs docs à moitié finies, bref tout le bazar que les boîtes planquent d'habitude, bah eux, ils le mettent à dispo ! Et c'est pour cela qu'ils cherchent des gens pour le support du kernel, pour tester le Wi-Fi en audit et injection, pour trancher le choix du bureau (KDE Plasma ou un gestionnaire en tiling plus léger ?), et même pour entraîner un petit modèle d'IA maison.

Et au-dessus de tout ça, ils préparent leur Flipper OS, une couche sur du Debian qui introduit une notion de « profils » qui n'est ni plus ni moins qu'un instantané complet du système avec ses paquets préconfigurés. Vous bootez dessus, vous le clonez, vous le cassez, et hop vous revenez à une copie propre sans tout reflasher.

Ils bossent aussi sur FlipCTL, un framework pour habiller les utilitaires Linux en menus sur petit écran, avec comme objectif de le rendre installable d'un simple apt install ailleurs que sur leur produit.

Après, j'espère que ça va bien se passer pour eux car malgré leur succès, Flipper Devices traîne un passif chargé. Le Flipper Zero s'est écoulé à plus d'un million d'exemplaires, mais il a été viré d'Amazon en 2023, étiqueté « appareil de skimming », puis carrément banni au Canada début 2024 sous prétexte qu'il servait à voler des voitures.

C'était d'ailleurs des accusations bidons vu que le bestiau dans sa forme de base est incapable de mener les attaques par relais qu'on utilise en général pour voler des voitures. Heureusement pour eux, la justice canadienne a fini par reculer, mais bon, leur réputation grand public est faite malheureusement.

L'autre point qui va vous calmer, c'est que vous ne pourrez pas encore l'acheter... Le moyen le plus rapide sera de lâcher 350 $ dans leur prochaine campagne Kickstarter prévue cette année. Et encore, le projet pourrait ne jamais sortir...

Voilà, du coup, si l'idée d'un Linux de poche sans compromis vous parle, le mieux pour aider, c'est peut-être d'aller mettre les mains dans le cambouis sur leur portail dev.

Perso, un cyberdeck ouvert jusqu'au noyau, moi ça me plait bien. Le Flipper Zero, ça m'a jamais convaincu mais ce Flipper One, déjà pour moi, il est beaucoup plus convaincant... On verra s'ils tiennent la distance maintenant. Et si vous voulez creuser le genre, jetez un œil à ce cyberdeck fait maison , au WiFi Pineapple côté audit sans fil, et à Intercept pour l'analyse radio.

À suivre de très près !

Le CNRS vient de confirmer un incident de cybersécurité qui a mené au téléchargement non autorisé de fichiers contenant des données personnelles d'anciens agents. Noms, adresses, numéros de sécurité sociale, RIB : la totale donc. L'organisme a déposé plainte et prévenu la CNIL.

Des données très sensibles

C'est ce lundi 16 février que le CNRS a informé ses agents d'une fuite de données sur un de ses serveurs. Des fichiers contenant des informations de ressources humaines ont été téléchargés sans autorisation. Et on ne parle pas de données anodines : noms, prénoms, dates de naissance, adresses postales, numéros de sécurité sociale et RIB. Le tout accompagné du statut de l'agent, du type de contrat et de la structure d'affectation. Le serveur a été isolé et arrêté dès la découverte de l'incident, et l'organisme assure que la fuite ne s'est pas propagée au reste de ses infrastructures.

Qui est concerné ?

Seuls les personnels recrutés avant le 1er janvier 2007 sont touchés, qu'ils aient été titulaires ou non. Si vous avez travaillé au CNRS après cette date, vous n'êtes pas concerné. Le nombre exact de victimes n'a pas été communiqué, mais vu la taille de l'organisme, on parle potentiellement de plusieurs milliers de personnes. Le CNRS recommande de prévenir sa banque, de surveiller ses comptes, de vérifier si ses données circulent sur haveibeenpwned.com, et de rester vigilant face aux tentatives de phishing ou d'usurpation d'identité. La CNIL et l'ANSSI ont été prévenues, et une plainte a été déposée auprès de la section cybercriminalité du parquet de Paris.

Les institutions françaises en ligne de mire

On n'est pas vraiment sur une première niveau cyberattaques sur des services de l'état. Le ministère de l'Intérieur, celui des Sports, et d'autres organismes avaient été visés. L'URSSAF a aussi confirmé une fuite touchant les données de 12 millions de salariés. Le CNRS lui-même avait été la cible d'un défacement de plusieurs de ses sous-domaines fin janvier. Deux incidents distincts, mais la tendance est claire, et c'est franchement moche.

On va quand même saluer le fait que le CNRS a communiqué rapidement, avec un communiqué officiel et une FAQ pour les personnes concernées. C'est loin d'être toujours le cas. Mais on va quand même se questionner sur le fait que des RIB et des numéros de sécu trainent sur un serveur, alors qu'on parle de données parfois veilles depuis presque 20 ans... Pourquoi ces informations étaient-elles encore accessibles ? La question du stockage prolongé de données sensibles revient sur la table, et visiblement, personne n'a encore de bonne réponse. En attendant, si vous avez porté la blouse du CNRS avant 2007, un petit tour sur votre relevé bancaire ne serait pas du luxe.

Article invité publié par Vincent Lautier . Vous pouvez aussi faire un saut sur mon blog , ma page de recommandations Amazon , ou lire tous les tests que je publie dans la catégorie "Gadgets Tech" , comme cette liseuse Android de dingue ou ces AirTags pour Android !

Est-ce que vous vous souvenez du bruit d'un lecteur de disquette ? Ce "clac-clac" mécanique qui signifiait qu'on allait enfin lancer Monkey Island ou Doom ?

Et bien, si vous avez encore un carton de disquettes 3,5 pouces qui traîne au fond du grenier, vous allez pouvoir enfin en faire quelque chose de nouveau en vous inspirant de ce bidouilleur de génie, Mads Chr. Olesen, qui vient de transformer ces reliques en télécommande TV physique pour les enfants.

Partant du constat que les télécommandes modernes sont devenues des usines à gaz et que les applis de streaming sont conçues pour nous faire scroller à l'infini, il a voulu créer un truc tangible où une disquette = un déclencheur pour une vidéo (ou une playlist). L'enfant choisit sa disquette, l'insère, et hop, le film se lance sur la TV via un Chromecast. Pas besoin de stocker le film sur les 1,44 Mo de la galette (ce qui serait un exploit en soi), la disquette contient juste une commande de lecture. C'est magique !

Côté technique, c'est du hacking de hardware comme je les aime... Le boîtier cache un duo de choc composé d'un ATmega (type Arduino) pour piloter le lecteur de disquettes et d'un ESP8266 pour causer en WiFi avec le Chromecast. Alors pourquoi deux puces ? Hé bien parce que la lecture des données brutes d'une disquette demande un timing ultra précis que l'ESP8266 a du mal à gérer tout seul à cause de ses tâches WiFi.

Hé ce n'est que ce n'est pas du simple RFID collé sur une disquette puisque le système lit vraiment les données physiques ! Sur chaque disquette préparée, on trouve un petit fichier autoexec.sh (généralement placé sur les premiers secteurs du disque). Ainsi, quand on insère la galette, l'ATmega réveille l'ESP, lit la commande et l'envoie via la liaison série. L'ESP n'a alors plus qu'à piloter le Chromecast via le réseau local pour lancer la vidéo.

Pour alimenter tout ça, il utilise des batteries 18650 (attention les amis, si vous reproduisez ça, n'oubliez pas le circuit de protection BMS, ça ne rigole pas avec le Lithium) et tout ce petit monde repart en sommeil 30 secondes après l'action pour économiser l'énergie. Et après lecture, petit détail bien geek, la tête se déplace vers la piste 20. Ce n'est pas pour éviter de rayer le disque, mais plutôt pour s'assurer que la tête n'exerce pas de pression prolongée sur la zone de données critique (piste 0) en cas de choc.

Les doigts dans le nez !

Voilà, j'ai trouvé ça très cool, surtout avec ce côté bien retro, mais au delà de ça, c'est un super moyen de redonner du sens au contenu. Ça apprend aux gamins qu'un film, c'est un objet physique qu'on choisit, pas juste un flux infini. Voilà, si vous avez envie de ressortir le fer à souder, foncez voir les détails du projet.

Et bravo à Mads pour cette superbe bidouille !

Source

Vous vous êtes déjà demandé ce que cache vraiment un site web ? Genre, au-delà de sa jolie façade ? Hé bien je vous présente Web-Check , un scanner OSINT qui va déshabiller n'importe quel domaine pour vous montrer tout ce qui se passe sous le capot.

Je vous ai déjà parlé d'OSINT.rocks qui centralise pas mal d'outils d'investigation. Et bien là, c'est un peu le même délire mais orienté analyse de sites web. Vous balancez une URL et hop, le projet vous ressort un rapport complet avec tout ce qu'il y a à savoir : certificat SSL, enregistrements DNS, en-têtes HTTP, géolocalisation du serveur, ports ouverts, stack technique utilisée... Bref, une vraie radio du site.

Ce qui est cool avec cette boîte à outils, c'est qu'elle ne se contente pas de gratter la surface puisque ça effectue plus de 30 types d'analyses différentes ! Vous voulez savoir si un site utilise un WAF (Web Application Firewall) ? Vérifier la configuration email (SPF, DKIM, DMARC) ? Voir l'historique du domaine via la Wayback Machine ? Tout est possible ! Et même les Core Web Vitals pour les obsédés de la performance !

Pour l'installer, c'est ultra simple. Si vous êtes team Docker (et vous devriez l'être), une seule commande suffit :

docker run -p 3000:3000 lissy93/web-check

Et vous avez votre instance perso qui tourne sur localhost:3000. Pas besoin de galérer avec des dépendances ou de configurer quoi que ce soit. Du coup, vous pouvez scanner vos propres sites sans que vos requêtes passent par un service tiers.

Pratique pour les paranos de la vie privée !

Le projet tourne sous TypeScript avec Astro en front, et tout le code est disponible sur GitHub sous licence MIT. Ça veut dire que vous pouvez le modifier, l'héberger où vous voulez, et même contribuer si le coeur vous en dit.

La partie détection de stack technique me plait beaucoup. C'est un peu comme ce que fait SSH-Audit pour les serveurs , sauf que l'outil identifie automatiquement les frameworks, CMS, bibliothèques JavaScript et autres composants utilisés par un site. Super utile donc pour les pentesters qui veulent mapper rapidement une cible, ou simplement pour les curieux qui se demandent "tiens, c'est quoi cette techno qu'ils utilisent ?".

Vous avez aussi une démo en ligne sur web-check.xyz si vous voulez tester avant d'installer quoi que ce soit. Mais bon, pour une utilisation régulière, je vous conseille vraiment l'instance locale. C'est plus rapide et vous gardez le contrôle sur vos données.

Voilà, si vous bossez dans la sécu, si vous êtes journaliste d'investigation, ou si vous êtes juste curieux de savoir ce que racontent les sites que vous visitez, ce scanner OSINT devrait rejoindre votre boîte à outils.

Allez jeter un œil, et vous me remercierez je pense !

Moi je pensais qu'un lave-linge c'était juste... un lave-linge. On tourne le bouton, le bouton tout rond, et paf, ça lave... Mais aujourd'hui ces bestioles sont bourrées d'électronique et connectées à fond au cloud. Et forcément, ça a donné des idées à deux chercheurs allemands qui ont présenté leurs travaux au 39C3 (Chaos Communication Congress).

Severin von Wnuck-Lipinski et Hajo Noerenberg ont passé des mois à décortiquer les entrailles de machines Miele et BSH (Bosch, Siemens, Neff, Gaggenau) et leurs découvertes sont super intéressantes pour qui s'intéresse notamment au droit à la réparation et à la domotique (sans dépendre du cloud).

Côté Miele, Severin a découvert que la plupart des machines fabriquées après 1996 embarquent une interface de diagnostic optique. Un petit port infrarouge planqué sur la façade qui permet aux techniciens de se connecter avec un outil proprio appelé MDU (Miele Diagnostic Utility). Le protocole c'est du bon vieux UART à 2400 bauds avec parité paire. Pas de chiffrement mais juste une clé de sécurité à 16 bits.

Et c'est là que ça devient croquant à souhait car pour trouver ces clés de diagnostic, Severin a exploité une faille de timing sur le microcontrôleur 8 bits. En gros, quand vous envoyez une mauvaise clé, le microcontrolleur met un tout petit peu plus de temps à répondre que quand le premier octet est correct. En mesurant ces délais avec un oscilloscope, il a pu deviner les clés octet par octet.

Et c'est grâce à cela qu'il a créé FreeMDU , un outil open source qui permet de dialoguer avec les appareils Miele et compatibles. Diagnostics, codes erreur, compteurs de cycles... tout est accessible et y'a même une intégration Home Assistant pour les fans de domotique DIY.

Côté BSH, Hajo a attaqué le D-BUS, le bus de communication propriétaire qui relie tous les composants internes (moteur, pompe, interface utilisateur, module WiFi). C'est également du UART à 9600 bauds sur des connecteurs RAST, avec une tension de bus de 9V pour les lave-linge et 13.5V pour les lave-vaisselle.

Le plus beau c'est qu'en fouillant le firmware du module timeline (celui qui gère l'affichage du temps restant), Hajo a trouvé des easter eggs planqués par les développeurs dans les graphiques. Comme quoi même les ingénieurs Bosch ont le sens de l'humour ^^.

Suite à ça, Hajo a développé bsh-home-appliances , un projet open source avec une extension ESPHome pour intégrer les appareils BSH dans Home Assistant. Vous pouvez donc suivre votre cycle de lavage, recevoir des notifications, et même accéder aux diagnostics sans passer par l'app proprio.

Et le final de la présentation était épique puisque les deux chercheurs ont connecté un lave-linge Miele à l'application BSH Home Connect via une couche de compatibilité maison qu'ils ont baptisée AMBCL (Advanced Miele BSH Compatibility Layer). Un Miele qui parle le Bosch, ça c'est fait !

Bref, si vous avez un appareil Miele ou BSH qui traîne et que vous voulez reprendre le contrôle sans dépendre du cloud du fabricant, les outils sont maintenant disponibles. C'est ça aussi le droit à la réparation : pouvoir diagnostiquer soi-même sa machine sans appeler un technicien à 150 euros de l'heure.

Par contre, bidouillez vos propres appareils uniquement parce que faire ça sur le lave-linge de votre meilleur pote, c'est pas cool et c'est illégal, alors fézez pas les cons !

Source

Vous avez un Steam Deck, un Lenovo Legion Go ou un ROG Ally qui traîne dans un coin parce que pas le temps de jouer, vous avez trop de boulot... Je connais bien vous inquiétez pas.

Mais si je vous disais que ce petit truc qui prend la poussière peut devenir votre meilleur allié pour les audits de sécurité discrets ?

Mais siii ! J'vous jure !

C'est en tout cas ce que propose Balor , un framework offensif fraîchement sorti et développé par Jean-Claude Charrier , qui grâce à ça peut d'un coup, transformer votre console gaming en une station de pentest portable.

Son concept est parti d'un constat simple... Quand vous débarquez en mission de pentest avec un cahier des charges qui exige de la discrétion, sortir un WiFi Pineapple c'est un peu comme débarquer en costard dans un festival de métal. Ça se voit !! Mais avec une console portable gaming par contre, vous avez juste l'air d'un type qui fait une pause entre deux réunions.

Ni vu ni connu, j't'embrouille !

Balor tourne sous CachyOS et Arch Linux, s'installe en une dizaine de minutes et embarque pas moins de 8 stacks pour environ 130 options au total. Côté WiFi, vous avez aircrack-ng, wifite, bettercap et même des versions de Wifiphisher réécrites spécialement pour Python 3.13. Pour l'OSINT, c'est Maltego, theHarvester, Shodan et compagnie. Et y'a aussi du Metasploit, Burpsuite, Nmap, Masscan, SQLMap, Hashcat, John the Ripper... Bref, la totale.

Le truc sympa c'est que tout passe par un wrapper unique appelé "balorsh". Vous tapez balorsh wifi et hop, le menu WiFi apparaît ! Pareil pour balorsh llm qui lance un assistant IA local via Ollama avec des personas adaptés comme Red Team pour l'offensif, Blue Team pour le défensif, Purple Team pour mixer les deux...etc.

L'installation se fait via un script qui dépose tout dans /opt/balorsh/data/ et la désinstallation est tout aussi propre. En plus chaque stack est modulaire, donc si vous n'avez besoin que du cracking de mots de passe, vous installez juste cette partie. Pour les sysadmins qui voudraient comprendre les workflows pentest sans se taper toute la doc, c'est aussi un bon point d'entrée. Genre enchaîner theHarvester, amass, massdns et httprobe pour du recon, ça devient accessible même sans être certifié OSCP ^^.

Côté limitations, Balor reste exclusif à l'écosystème Arch/CachyOS mais rassurez-vous, un portage Debian est envisagé si la demande suit.

Perso je trouve l'approche vraiment bien trouvée et le fait que ce soit un projet français plutôt qu'une énième distro sécu américaine corporate, ça fait plaisir. Voilà, par contre comme d'hab, c'est un outil pour les audits autorisés uniquement avec contrat signé, et pas pour aller embêter le WiFi du voisin, hein ^^.

Alors déconnez pas !

Encore merci à Jean-Claude d'avoir partager sa création avec moi.

Les vieux de la vieille connaissent forcement Cheat Engine puisque c'est LE logiciel culte pour tripatouiller la mémoire des jeux , trouver l'adresse où est stockée votre santé, votre or, vos munitions, et la modifier à la volée. Sauf que manuellement, c'est un travail de fourmi... Trouver un pointeur stable qui ne change pas à chaque redémarrage du jeu, ça peut prendre des jours, voire des semaines de bidouillage.

Hé bien quelqu'un a eu l'idée un peu folle de brancher Claude directement sur Cheat Engine et visiblement le résultat est au rendez-vous.

Le projet s'appelle cheatengine-mcp-bridge et c'est un pont entre les IA compatibles MCP (Claude, Cursor, Copilot) et Cheat Engine. Concrètement, ça veut dire que vous pouvez maintenant demander à Claude de faire le boulot de reverse engineering à votre place, en langage naturel.

Dans cet outil, y'a trois couches qui communiquent ensemble : l'IA qui reçoit vos questions en langage humain, un serveur Python qui traduit tout ça en commandes techniques, et un script Lua côté Cheat Engine qui exécute les opérations sur le processus ciblé.

Et les possibilités sont dingues puisque l'outil expose pas moins de 39 "tools" MCP différents. Vous pouvez lire la mémoire (entiers, floats, strings, pointeurs), suivre des chaînes de pointeurs complexes du genre [[base+0x10]+0x20]+0x8, scanner des valeurs, analyser du code désassemblé, identifier des objets C++ via les infos RTTI, et même poser des breakpoints hardware. Il y a même le support du DBVM, le mode hyperviseur de Cheat Engine qui permet un traçage niveau Ring -1 , beaucoup plus difficile à détecter pour les protections anti-cheat classiques.

Avec ce MCP, vous lancez un jeu, vous demandez à Claude "Scanne l'or, j'en ai 15000". L'IA trouve alors 47 résultats. Vous dépensez un peu d'or dans le jeu, vous dites "Maintenant j'en ai 14900". Claude filtre et garde 3 adresses. Ensuite vous demandez "C'est quoi qui écrit sur la première adresse ?", et hop, breakpoint hardware posé automatiquement. Ensuite, un petit "Désassemble moi cette fonction", et vous avez tout le code de la fonction AddGold devant les yeux.

Tout ce processus qui prenait des heures de tatonnement se fait maintenant en mode conversation.

Vous connaissez les cyberdecks ?

Non ?? Pourtant, je vous en ai parlé déjà. Ce sont des petits ordis portables custom qu'on voit par exemple dans les films cyberpunk, où genre, le mec sort son bouzin de sa poche et hop, il peut hacker le monde entier. HACK THE PLANET !! Oué Oué !

Et bien tenez-vous bien car le Hackberry Pi CM5 9900 , c'est exactement ça, mais en vrai !

Le Hackberry Pi c'est donc un projet DIY qui transforme un Raspberry Pi Compute Module 5 en plateforme de hacking portable, ce qui est parfait pour les pentesters, les gens de l'infosec, ou simplement les geeks qui veulent un Linux puissant dans un format ultra-compact.

Le châssis mesure 143,5 x 91,8 x 17,6 mm pour 306 grammes et vous avez une coque en aluminium sur le devant et le dos, avec une partie centrale imprimée en 3D. À l'intérieur, un écran tactile 720x720, un vrai clavier physique style BlackBerry 9900, et un Raspberry Pi CM5 avec un quad-core Cortex-A76 qui tourne à 2,4 GHz.

L'écran est carré, ce qui est un format assez inhabituel mais plutôt pratique quand vous bossez en terminal. Le clavier, c'est celui du BlackBerry 9900, donc un vrai clavier physique avec des touches qui cliquent, et si vous avez déjà tapé sur un clavier tactile pendant 3 heures d'affilée, vous comprendrez pourquoi c'est cool.

Côté connectique, vous avez aussi 2 ports USB 3.0, un HDMI pleine taille, un slot M.2 2242 pour un SSD NVME, un lecteur microSD, une batterie de 5 000 mAh, et même des enceintes stéréo intégrées. La batterie vous donnera environ 5 heures en veille et 3 ou 4 heures en utilisation active. Et une recharge complète se fera en 3 heures via USB-C.

Donc plutôt que d'utiliser votre ordi principal pour vos tests de sécu, vous pouvez monter un environnement dédié sur ce petit deck. Vous flashez Kali Linux sur le SSD NVME, vous ajoutez quelques dongles WiFi style ALFA Network AWUS036ACM, peut-être un adapteur Bluetooth, un hub USB, et hop, vous avez une plateforme de pentesting portable.

Le truc cool, c'est surtout que le projet est modulaire donc vous pouvez par exemple modifier l'antenne WiFi.. Les fichiers STL sont également dispo en ligne, donc si vous avez une imprimante 3D, vous pouvez vous imprimer un support d'antenne custom. Certains ont même ajouté des radios logicielles (SDR) pour jouer avec les fréquences radio.

Ensuite, l'installation est assez simple. Vous commencez par insérer le module CM5 dans son slot dédié, vous ajoutez le SSD NVME, vous imprimez éventuellement votre support d'antenne custom, vous flashez Raspbian sur une carte microSD pour le boot initial, puis vous installez Kali Linux sur le NVME, et vous configurez les options de boot pour démarrer directement depuis le SSD.

Si vous avez capté tout ce qui est écrit ci-dessus, ce sera simple oui. Sinon, faudra lire un peu de doc ^^.

Le système supporte aussi plusieurs OS : Kali pour le pentesting, Pi OS par défaut, Ubuntu, LineageOS (Android), Manjaro, TwisterOS, ou même ParrotOS. Et vous pouvez basculer entre les environnements selon ce que vous voulez faire.

Maintenant niveau prix, comptez environ 300-350 dollars pour le setup complet. Le châssis Hackberry Pi CM5 9900 coûte 168 dollars, le module Raspberry Pi CM5 Lite avec 16 Go de RAM tourne à 132 dollars, vous ajoutez un SSD NVME de 256 Go, la batterie 5 000 mAh avec charge MagSafe, et quelques accessoires.

C'est dispo chez plusieurs revendeurs : Elecrow, Carbon Computers, Tindie, ou même Etsy mais le module CM5 par contre, faudra le sourcer séparément, genre chez Pishop.us.

Ce projet a été développé par ZitaoTech, c'est open source, donc toute la communauté peut contribuer, améliorer les designs, partager des configs, etc et y'a d'ailleurs déjà pas mal de mods qui circulent, notamment des antennes externes pour améliorer la portée WiFi pendant les tests de pénétration.

Comme ça, si vous êtes dans la sécu offensive, c'est quand même pratique d'avoir un device dédié qui ne risque pas de foutre en l'air votre config perso si un test part en vrille. Vous isolez vos outils, vos payloads, vos exploits sur un système séparé, et si ça plante, bah vous rebootez le deck, c'est tout.

Et puis franchement, c'est plutôt classe je trouve de sortir un truc comme ça de sa poche. Ça donne l'impression que vous êtes en mission, comme dans les films... vous dégainez votre petit cyberdeck avec son clavier BlackBerry, vous vous branchez sur un port Ethernet, et hop, vous lancez vos scans. Ça a plus de gueule je trouve qu'un laptop Dell sous Windows avec un autocollant Mr. Robot ^^.

A découvrir ici !

Vous voyez cette liseuse Kindle qui traîne sur votre table de chevet depuis des années ? Mais si, ce truc que vous avez oublié dans un coin parce que vous n'aimez pas lire, qui est toujours connecté au Wi-Fi, et qui contient votre numéro de carte bleue pour acheter des bouquins en un clic ?

Hé bien un chercheur en sécu vient de découvrir qu'un simple ebook vérolé pouvait lui permettre de prendre le contrôle total de votre compte Amazon.

Valentino Ricotta, un hacker éthique qui bosse chez Thalium (la division recherche de Thales à Rennes), a présenté ses trouvailles à la conférence Black Hat Europe à Londres avec un titre qui résume bien le délire : "Don't Judge an Audiobook by Its Cover".

Histoire de rentrer un peu plus dans les détails, sachez que cette faille exploite du code qui n'a rien à faire sur une Kindle de base. Ricotta s'est attaqué au système qui parse les fichiers audiobooks Audible, un format multimédia proche du MP4. Ainsi, même sur les Kindle qui ne peuvent pas lire d'audio, le système scanne quand même ces fichiers pour en extraire les métadonnées comme le titre, l'auteur et la couverture.

En analysant le code de parsing proprio d'Amazon, il a alors découvert une erreur de calcul classique dans l'estimation de la mémoire nécessaire par le logiciel. Du coup, en bricolant un faux fichier audiobook avec des valeurs bien choisies, il a pu déclencher un heap overflow qui lui permet d'écrire des données là où il ne devrait pas.

L'exploit tourne silencieusement en arrière-plan sans que la victime ne s'en aperçoive. Ricotta a ensuite enchaîné avec une deuxième vulnérabilité dans le service interne qui gère le clavier virtuel de la Kindle. Ce service tournait avec des privilèges élevés mais sans contrôle d'accès correct, ce qui lui a permis de charger du code malveillant et de prendre le contrôle complet de l'appareil. À partir de là, il a pu voler les cookies de session Amazon, ces fameux tokens qui vous maintiennent connecté à votre compte.

Bref, une fois qu'un attaquant a mis la main sur une Kindle et ces tokens, les possibilités sont plutôt larges : accès aux données perso, infos de carte bancaire, et même pivot vers votre réseau local ou d'autres appareils liés à votre compte Amazon. Les victimes potentielles sont donc tous ceux qui font du "side-loading", c'est-à-dire qui téléchargent des ebooks sur des sites tiers et les balancent sur leur Kindle via USB. Avec ça, même sans avoir de connexion internet, le mal est vite fait.

C'est pas la première fois que quelqu'un découvre une faille sur les Kindle via des ebooks vérolés, puisque des chercheurs de Realmode Labs et Check Point avaient déjà fait le coup en 2021 et là aussi les deux failles ont été jugées "critiques" par Amazon et corrigées depuis... Et Ricotta a empoché 20 000 dollars de bug bounty que Thales a reversé à une asso caritative.

Bravo à lui !

Source

Quand je revoie des films comme WarGames ou Hackers, je me rends compte que je suis un poil nostalgique de ces écrans noirs avec du texte vert, des modems qui crapotent, et de la magie des connexions longue distance sur des réseaux qui tenaient avec du scotch et des prières… Hé bien cool pour moi (et pour vous, si vous avez la même pathologie de moi) y’a un taré des Internet qui a recréé tout ça, et c’est jouable directement dans votre navigateur.

Ça s’appelle Telehack , et c’est une simulation complète de l’ARPANET et d’Usenet tels qu’ils existaient entre 1985 et 1990. Le site propose 26 600 hôtes virtuels, des milliers de fichiers d’époque, des jeux d’aventure textuels, un interpréteur BASIC fonctionnel et même des utilisateurs historiques reconstitués à partir de vraies archives. Le créateur, connu uniquement sous le pseudo “Forbin” (une ref au film “Le Cerveau d’acier” de 1970), a vraiment pondu un truc de dingue que vous devez tester absolument !

Le plus beau dans tout ça, c’est que vous pouvez vous y connecter comme à l’époque. En telnet sur les ports 13, 1337 ou 8080, en SSH sur le port 2222, et même… avec un vrai numéro de téléphone américain (+1 213 835-3422) accessible en modem analogique 14,4 kbps. Pour les nostalgiques du grésillement, c’est du bonheur.

Une fois connecté, vous vous retrouvez donc avec une invite de commande minimaliste. Tapez ensuite netstat pour voir la liste des hôtes accessibles, puis telnet pour vous connecter à un système distant, ou dial pour composer des numéros de téléphone virtuels comme un vrai phreaker des années 80. Y’a même des outils de hacking d’époque comme wardial.exe et porthack.exe pour progresser dans le jeu et débloquer de nouveaux systèmes.

Côté contenu, c’est également un vrain musée vivant. Toutes les archives Usenet intégrées proviennent de la collection d’Henry Spencer, un type de l’Université de Toronto qui a sauvegardé plus de 2 millions de messages entre 1981 et 1991 sur 141 bandes magnétiques récupérées de justesse avant d’aller à la poubelle.

Ces messages sont les plus anciens posts Usenet encore existants, et vous pouvez donc les lire directement dans Telehack. C’est pas ouf ça ?

Pour les amateurs de jeux, y’a Zork , Adventure et tout un tas de jeux en Z-code jouables directement. L’interpréteur BASIC inclus permet également d’exécuter des centaines de programmes historiques et si vous aimez Star Wars en ASCII , le film complet en animation texte est disponible.

D’ailleurs, la simulation au sein de Telehack va assez loin dans le réalisme puisque comme je vous le disais, les utilisateurs historiques sont reconstitués à partir de vraies archives UUCP de l’époque. Vous pouvez faire un finger @host sur n’importe quel système pour voir qui est “connecté”. Les mots de passe des systèmes sont volontairement faibles (secret, love, trustno1…) comme c’était le cas à l’époque et le côté hacking vous fera gagner des badges (HACK5, HACK10, HACKER) au fur et à mesure que vous compromettez des systèmes.

Telehack est passé à ce jour d’un petit projet en 2010 à une communauté de plus de 50 000 utilisateurs et vu la qualité du truc, c’est mérité. Pour ceux qui ont connu cette époque ou ceux qui veulent comprendre comment c’était avant le web, c’est une expérience unique, les amis !

Pour y accéder : telehack.com dans votre navigateur, ou telnet telehack.com si vous voulez faire les choses proprement. Enjoy !

L’histoire du jour est signée Luke M, un hacker qui a découvert comment rooter une caméra avec… du son !

L’appareil en question est une caméra chinoise de la marque Yi qui utilise une fonctionnalité appelée “Sonic Pairing” pour faciliter la configuration WiFi. Comme ça, au lieu de galérer à taper votre mot de passe WiFi sur une interface minuscule avec vos gros doigts boudinés, vous jouez simplement un petit son depuis votre téléphone et c’est ce son qui contient votre clé WiFi encodés en modulation de fréquence. La caméra écoute, décode, et se connecte.

Magique, non ?

Sauf que cette fonctionnalité marquée en “beta” dans l’app Yi IoT contient deux bugs magnifiques : une stack overflow local et un global overflow. En gros, en fabriquant un fichier audio malveillant avec les bons patterns, Luke a pu injecter du code arbitraire dans la caméra, ce qui lui permet d’obtenir un shell root qui se lance via la commande telnetd avec les identifiants par défaut. Tout ça, sans accès physique… juste la lecture d’un wav ou d’un MP3.

Pour arriver à ses fins, Luke a utilisé Frida , un framework de hooking que j’adore, capable d’intercepter les fonctions natives de l’app. Cela lui a permis de remplacer les données légitimes attendues par l’app par son propre payload.

Le premier bug (stack overflow) n’étant pas suffisant seul, Luke a dû utiliser un autre bug ( un out-of-bounds read via DOOM ) pour leaker un pointeur et contourner l’ ASLR . Mais le second bug (global overflow) est bien plus intéressant puisqu’il lui permet directement de faire une injection de commande via system() lors du pairing, sans avoir besoin d’autre chose.

Voici la waveform utilisée par le second exploit

Et comme la chaîne que vous pouvez envoyer via le son peut faire jusqu’à 128 bytes c’est largement suffisant pour un telnetd ou n’importe quelle commande shell. Notez que pour que l’exploit marche, le bind_key doit commencer par ‘CN’, ce qui force un path exploitable et, en bonus fait causer la caméra en chinois ^^.

Après faut savoir que ce hack amusant ne fonctionne que si la caméra n’est pas encore connectée au cloud. Donc c’est pas très utile pour attaquer des caméras déjà déployées mais ça illustre bien le problème de tout cet IoT pas cher avec des tas de features “pratiques” comme ce “Sonic Pairing” qui finissent par être catastrophique dans la pratique.

Voilà… si vous voulez les détails techniques complets avec les waveforms et le code d’exploit, foncez lire ça sur Paged Out! #7 .

Vous avez une caméra de surveillance connectée chez vous ? Du genre petite caméra Yi à 15 balles achetée sur AliExpress pour surveiller le salon ou le chat quand vous n’êtes pas là ? Alors tenez-vous bien parce qu’un chercheur a réussi à faire tourner DOOM dessus. Et sans toucher au firmware s’il vous plait ! Il a juste exploité le stream vidéo et quelques bugs bien sentis de l’appareil.

Luke M a publié son projet Yihaw sur GitHub et ça fait un peu peur car si quelqu’un peut hijacker le stream de votre caméra pour y balancer un FPS des années 90, il peut aussi faire pas mal d’autres trucs beaucoup moins rigolos.

Le hack est assez cool d’ailleurs car ces caméras Yi tournent sur un petit processeur ARM sous Linux. Elles ont donc une app mobile qui vous permet de voir le stream en temps réel et Luke M a trouvé plusieurs vulnérabilités dans la stack réseau de la caméra. Je vous passe les détails mais avec ces bugs, il peut injecter du code arbitraire sans modifier le firmware.

Il peut alors créer trois threads qui tournent en parallèle. Le premier récupère les frames YUV420p directement depuis le capteur de la caméra. Le deuxième convertit ça en h264. Le troisième, au lieu d’envoyer le flux vidéo normal, envoie DOOM. Du coup, vous ouvrez l’app Yi IoT sur votre smartphone et vous voyez le Doomguy buter des demons au lieu de voir votre salon. C’est rigolo, hein ?

Ces caméras Yi, il y en a des millions installées partout dans le monde. Bureaux, maisons, magasins…etc car elles sont pas chères, elles marchent plutôt bien, elles ont une app correcte, mais leur sécurité c’est une vraie passoire. C’est bourré de bugs qu’on trouve en une après-midi avec un fuzzer basique.

Luke M liste plusieurs exploits dans son repo GitHub et c’est un vrai buffet à volonté pour quelqu’un qui veut prendre le contrôle de ces caméras. Bien sûr ce serait illégal alors personne ne le fait, surtout parce que ça demande quand même un peu de boulot pour chaque modèle de caméra. Mais les outils existent, les vulnérabilités sont connues, et si un chercheur solo peut le faire pour s’amuser avec DOOM, imaginez ce qu’un botnet bien pensé pourrait faire.

Tous ces trucs qu’on a chez nous, qui tournent sur du Linux embarqué avec des stacks réseau écrites à l’arrache par des équipes chinoises sous-payées qui doivent sortir un produit tous les trois mois.

C’est beau non ?

Source (c’est du PDF)

Vous connaissez peut-être ces machines à mélanger les cartes qu’on trouve dans tous les casinos américains ?

Moi je ne savais même pas que ça existait, mais apparemment, le Deckmate 2, fabriqué par Shufflemaster (devenu depuis Light and Wonder), c’est la Rolls des shufflers. Un shuffler c’est pas un légume dégeu, c’est un mélangeur de cartes et on en trouve notamment au World Series of Poker (La biz à Patrick Bruel ^^), et dans tous les grands poker rooms de Vegas.

Cela permet d’automatiser le mélange pour accélérer le jeu et surtout éviter que ceux qui distribuent les cartes (les dealers) trichent avec de faux mélanges. La machine a même une caméra intégrée qui scanne chaque carte pour détecter si quelqu’un essaie de retirer un as ou d’ajouter un sept de pique.

En septembre 2022, il y a eu un scandale qui a secoué le monde du poker. Au Hustler Casino Live de Los Angeles, une joueuse relativement débutante, Robbi Jade Lew, gagne un pot de 269 000 dollars avec un call complètement fou. Elle avait valet-quatre dépareillés (un truc nul), et son adversaire Garrett Adelstein bluffait avec huit-sept. Techniquement, son call était correct, mais aucun joueur sensé n’aurait misé 109 000 dollars sur une main pareille sans savoir que l’adversaire bluffait… Le casino a donc lancé une enquête et conclu que le shuffler ne pouvait pas être compromis.

Mais même si ce n’était pas le cas pour cette affaire, est ce que c’est vrai ? Est ce qu’un Deckmate 2 peut être hacké ? Pour le chercheur en sécurité, Joseph Tartaro, ça s’est présenté comme un nouveau défi personnel !

Il a donc acheté un Deckmate 2 d’occasion avec deux collègues et a passé des mois à le démonter… pour finalement trouver quelques trucs intéressants, vous allez voir.

Il a découvert que la machine a un port USB accessible sous la table, là où les joueurs posent les genoux. Tartaro a donc créé un mini-ordinateur de la taille d’une clé USB qui, une fois branché, réécrit le firmware de la machine. La seule sécurité qu’il y a, c’est au démarrage, quand la machine vérifie que le code n’a pas changé en comparant son empreinte à une valeur connue.

C’est une simple comparaison de hash et le problème est que Tartaro peut modifier cette valeur de référence aussi… Du coup, le système de vérification contrôle que le code piraté correspond au hash piraté. C’est ballot ^^. Et une fois le firmware modifié, la machine continue à fonctionner normalement sauf qu’elle transmet maintenant l’ordre exact des 52 cartes via Bluetooth vers une app smartphone. Et comme la caméra interne de ce Deckmate 2 scanne déjà toutes les cartes pour détecter les fraudes, il suffit d’exploiter cette fonctionnalité.

Un journaliste de Wired a décidé de mettre ça en pratique dans des conditions réelles et vous allez voir, c’est sympa à voir.

Y’a plein de problèmes avec les IA, mais y’en a un encore un peu trop sous-estimé par les vibe codeurs que vous êtes… Ce problème, c’est qu’on leur fait confiance comme à un collègue, on leur montre notre code, nos repos privés, nos petits secrets bien planqués dans les variables d’environnement…

Par exemple, quand vous passez en revue une pull request sur GitHub, vous faites quoi ? Vous lisez le code ligne par ligne, vous cherchez les bugs, les failles de sécu, les optimisations possibles. Mais les commentaires vous les lisez ? Au mieux on les survole, c’est vrai, car c’est de la comm’ entre devs, et pas du code exécutable.

Sauf pour Copilot Chat pour qui un commentaire c’est un texte comme un autre. Et selon Omer Mayraz , chercheur en sécurité chez Legit Security, c’est exactement ce qui en fait une zone de confiance aveugle parfaite pour une attaque.

Ce qu’a découvert Omer Mayraz c’est donc une vulnérabilité critique dans GitHub Copilot Chat avec un score CVSS de 9.6 sur 10. Cela consiste à planquer des instructions malveillantes dans des commentaires markdown invisibles comme ça, ces commentaires ne s’affichent pas dans l’interface web de GitHub, mais Copilot Chat les voit parfaitement et les traite comme des prompts légitimes.

Du coup, l’attaquant peut forcer Copilot à chercher des secrets dans vos repos privés, à extraire du code source confidentiel, voire à dénicher des descriptions de vulnérabilités zero-day non publiées. Tout ça sans que vous ne voyiez rien venir évidemment !

Voici une démo complète de l’attaque en vidéo :

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/camoleak-github-copilot-vulnerability-prompt-injection/camoleak-github-copilot-vulnerability-prompt-injection-1.mp4">lien vers la vidéo</a>.

Si vous faites du pentest, il doit vous arriver parfois de lancer un petit bruteforce sur un formulaire un peu pourri, pour tester les mots de passe classiques gens 1234, ou admin…etc. Mais parfois, certains formulaires de connexion donnent envie de se flinguer… Les sélecteurs CSS changent à chaque rafraîchissement, les noms des champs sont aléatoires…etc bref, ça peut vite être un véritable labyrinthe pour automatiser quoi que ce soit.

Heureusement pour vous les amis, le développeur Mor David s’est occupé du problème et a inventé BruteForceAI, un outil de bruteforce qui comme son nom l’indique, embarque une bonne dose d’intelligence artificielle.

La petite subtilité donc avec BruteForceAI, c’est qu’il ne se contente pas de lancer des milliers de combinaisons en mode berserk. Non, l’outil étudie d’abord la page HTML avec un modèle de langage qui comprend la structure du formulaire. Cette première phase atteint un joli 95% de précision dans l’identification des éléments de connexion, comme ça plus besoin de passer des heures à mapper manuellement les sélecteurs CSS.

C’est un système en deux temps où l’IA déchiffre d’abord le HTML et génère automatiquement les sélecteurs CSS nécessaires. Puis seulement après, l’attaque démarre avec des comportements qui imitent un humain : délais aléatoires, rotation des user-agents, logique de retry intelligente. L’outil peut même détecter les changements dans le DOM pour valider qu’une connexion a réussi.

Pour faire tourner la bête, il vous faudra Python 3.8+, Playwright pour l’automatisation du navigateur, et un modèle LLM. Vous avez le choix entre Ollama en local avec llama3.2:3b (pratique pour rester discret) ou Groq dans le cloud avec llama-3.3-70b-versatile si vous voulez plus de puissance.

Les modes d’attaque proposés sont assez classiques mais efficaces… Par exemple, le mode Brute-Force teste exhaustivement toutes les combinaisons possibles, tandis que le mode Password-Spray est plus subtil puisqu’il teste chaque mot de passe sur plusieurs comptes pour éviter les blocages après X tentatives échouées. Cette dernière technique est d’ailleurs redoutable contre les entreprises qui imposent des politiques de mots de passe uniformes.

D’après une analyse récente de CipherX Labs , l’IA rend le cracking de mots de passe 100 fois plus rapide qu’avec les méthodes traditionnelles. Un mot de passe de 10 caractères, même avec majuscules, minuscules et symboles, est maintenant considéré comme faible. L’aspect éthique est évidemment crucial ici et Mor David insiste sur le fait que l’outil est uniquement destiné aux tests de sécurité autorisés, à la recherche et aux programmes de bug bounty. Si vous faites des choses illégales avec ça, vous irez obligatoirement en prison et ce sera bien fait pour vous !

BruteForceAI dispose aussi d’un système de notifications plutôt bien pensé. Quand l’outil trouve des identifiants valides, il peut vous prévenir via Discord, Slack, Teams ou Telegram. Tout est loggé dans une base SQLite pour l’analyse post-attaque. Le côté multi-threadé permet aussi de lancer plusieurs attaques en parallèle, avec des timing humains pour éviter la détection.

Alors pour se défendre contre ce genre d’outils, les méthodes classiques ne suffisent plus… Par exemple, compter les tentatives de connexion échouées, c’est un peu has been… Non, maintenant il vous faut des systèmes de détection comportementale qui analysent les patterns d’accès en temps réel, du type UEBA (User and Entity Behavior Analytics). Les entreprises qui n’ont pas encore intégré ce genre de solutions sont aujourd’hui des cibles faciles pour les cybercriminels.

En plus, PassGAN et d’autres outils similaires apprennent à partir des bases de données de mots de passe qui ont fuité…. Plus il y a de fuites, plus l’IA devient efficace pour prédire les prochains mots de passe. C’est un cercle vicieux où chaque fuite de données nourrit la machine qui causera les prochaines fuites de données…

Maintenant si vous voulez tester BruteForceAI (sur vos propres systèmes, hein), l’installation est simple :

clonez le repo, installez les dépendances avec pip, téléchargez un des navigateurs Playwright, et c’est parti. Les commandes de base ressemble à ça :

# Etape 1: Analyser le formulaire
python main.py analyze --urls targets.txt --llm-provider ollama --llm-model llama3.2:3b

# Etape 2: Attaquer avec 20 threads
python main.py attack --urls targets.txt --usernames users.txt --passwords passwords.txt --threads 20 --delay 5 --jitter 2

• lien nᵒ 1 : Journal à l’origine de la dépêche
• lien nᵒ 2 : Nautilus navigateur de fichiers de GNOME
• lien nᵒ 3 : GNOME HIG : bonnes pratiques pour l'interaction humain-machine (IHM)
• lien nᵒ 4 : GNOME Builder pour créer des applications

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -200,7 +201,7 @@
     </child>
     <child>
       <object class="AdwBreakpoint">
-        <condition>max-width: 682sp</condition>
+        <condition>max-width: 750sp</condition>
         <setter object="split_view" property="collapsed">True</setter>
         <setter object="split_view" property="enable-show-gesture">True</setter>
         <setter object="split_view" property="enable-hide-gesture">True</setter>

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -101,6 +56,7 @@
               <object class="AdwOverlaySplitView" id="split_view">
                 <property name="enable-show-gesture">False</property>
                 <property name="enable-hide-gesture">False</property>
+                <property name="show-sidebar">False</property>
                 <property name="max-sidebar-width">240</property>
                 <property name="sidebar-width-unit">px</property>
                 <property name="sidebar-width-fraction">0.2</property>

--- a/src/resources/style.css
+++ b/src/resources/style.css
@@ -149,7 +149,7 @@
   border-radius: 12px;
 }
 .nautilus-grid-view #NautilusViewCell {
-  padding: 6px;
+  padding: 0px;
   border-radius: 12px;
 }

    nautilus_application_set_accelerator (app, "win.toggle-sidebar", "F9");

#undef ACCELS

    action = g_action_map_lookup_action (G_ACTION_MAP (window), "toggle-sidebar");
    g_object_bind_property (window->content_flap, "folded",
                            action, "enabled", G_BINDING_SYNC_CREATE);

apt source nautilus

debuild -b -uc -us

10/20 nautilus:displayless / test-file-operations-trash-or-delete           FAIL             0.08s   killed by signal 5 SIGTRAP
 7/20 nautilus:displayless / test-file-operations-copy-files                FAIL             0.67s   killed by signal 5 SIGTRAP
 9/20 nautilus:displayless / test-file-operations-move-files                FAIL             1.53s   killed by signal 5 SIGTRAP

export DEB_BUILD_OPTIONS=nocheck
debuild -b -uc -us

#pour démarrer l'écriture d'un patch ()
dquilt new fix-nautilus-sidebar.patch

# pour indiquer les fichiers à surveiller :
dquilt add src/nautilus-window.c src/resources/style.css src/resources/ui/nautilus-window.ui

# pour récupérer les modifications des fichiers modifiés :
dquilt refresh

dch -n "Fix Nautilus Sidebar"

From: hugotrip 
Description: allow to hide the sidebar & more
--- a/src/nautilus-window.c
+++ b/src/nautilus-window.c
@@ -1135,11 +1135,6 @@

     nautilus_window_on_undo_changed (nautilus_file_undo_manager_get (), window);

-#undef ACCELS
-
-    action = g_action_map_lookup_action (G_ACTION_MAP (window), "toggle-sidebar");
-    g_object_bind_property (window->split_view, "collapsed",
-                            action, "enabled", G_BINDING_SYNC_CREATE);
 }

 static gboolean
--- a/src/resources/style.css
+++ b/src/resources/style.css
@@ -149,7 +149,7 @@
   border-radius: 12px;
 }
 .nautilus-grid-view #NautilusViewCell {
-  padding: 6px;
+  padding: 0px;
   border-radius: 12px;
 }

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -104,6 +104,7 @@
                 <property name="max-sidebar-width">240</property>
                 <property name="sidebar-width-unit">px</property>
                 <property name="sidebar-width-fraction">0.2</property>
+                <property name="show-sidebar">False</property>
                 <property name="sidebar">
                   <object class="AdwToolbarView">
                     <property name="reveal-bottom-bars"

#!/bin/bash

# récupération de la source des paquets Debian
apt source nautilus
#Application de mes modifications
cd nautilus-48.*
patch -p1 < ../fix-nautilus-sidebar.patch
# mise à jour du CHANGELOG, pour augmenter le numér de version :
dch -n "Fix Nautilus Sidebar"
# construction des paquets :
export DEB_BUILD_OPTIONS=nocheck
debuild -b -uc -us
# installation des paquets :
cd ..
rm *dbgsym*.deb & rm *dev*.deb
sudo apt install ./*.deb

windowhandle {
    background:#41495c; /* couleur d'arrière-plan */
    color:#e9ecf2; /* couleur de premier plan */
}

windowhandle {
    background:#41495c;
    color:#e9ecf2;
}

window{
    border-radius: 7px;
}

.sidebar-pane {
    background:#eaeef3;
}

windowcontrols > .close {
    background-image: radial-gradient(#bf616a, #bf616a 48%, transparent 48.5%);
}

Commentaires : voir le flux Atom ouvrir dans le navigateur

Si vous regardez les infos à forte dose, vous devez probablement penser que la fin du monde est proche. À un moment, on va tous se retrouver dans un RPG post-apocalyptique et notre personnage aura un niveau 2 en médecine, un niveau 3 en chimie et tombera forcement sur une quête secondaire du style : “Fabriquer des antibiotiques pour sauver le campement”.

Alors quelle est l’histoire de cette découverte scientifique qui a changé la médecine moderne ? Voici à titre purement éducatif, la science qui se cache derrière la pénicilline, un processus qui combine à la fois biologie, chimie et une bonne dose de patience.

Les grands modèles de langage (LLM), comme le célèbre GPT-4 d’OpenAI, font des prouesses en termes de génération de texte, de code et de résolution de problèmes. Perso, je ne peux plus m’en passer, surtout quand je code. Mais ces avancées spectaculaires de l’IA pourraient avoir un côté obscur : la capacité à exploiter des vulnérabilités critiques.

C’est ce que révèle une étude de chercheurs de l’Université d’Illinois à Urbana-Champaign, qui ont collecté un ensemble de 15 vulnérabilités 0day bien réelles, certaines classées comme critiques dans la base de données CVE et le constat est sans appel. Lorsqu’on lui fournit la description CVE, GPT-4 parvient à concevoir des attaques fonctionnelles pour 87% de ces failles ! En comparaison, GPT-3.5, les modèles open source (OpenHermes-2.5-Mistral-7B, Llama-2 Chat…) et même les scanners de vulnérabilités comme ZAP ou Metasploit échouent lamentablement avec un taux de 0%.

Heureusement, sans la description CVE, les performances de GPT-4 chutent à 7% de réussite. Il est donc bien meilleur pour exploiter des failles connues que pour les débusquer lui-même. Ouf !

Mais quand même, ça fait froid dans le dos… Imaginez ce qu’on pourrait faire avec un agent IA qui serait capable de se balader sur la toile pour mener des attaques complexes de manière autonome. Accès root à des serveurs, exécution de code arbitraire à distance, exfiltration de données confidentielles… Tout devient possible et à portée de n’importe quel script kiddie un peu motivé.

Et le pire, c’est que c’est déjà rentable puisque les chercheurs estiment qu’utiliser un agent LLM pour exploiter des failles coûterait 2,8 fois moins cher que de la main-d’œuvre cyber-criminelle. Sans parler de la scalabilité de ce type d’attaques par rapport à des humains qui ont des limites.

Alors concrètement, qu’est ce qu’on peut faire contre ça ? Et bien, rien de nouveau, c’est comme d’hab, à savoir :

• Patcher encore plus vite les vulnérabilités critiques, en priorité les « 0day » qui menacent les systèmes en prod
• Monitorer en continu l’émergence de nouvelles vulnérabilités et signatures d’attaques
• Mettre en place des mécanismes de détection et réponse aux incidents basés sur l’IA pour contrer le feu par le feu
• Sensibiliser les utilisateurs aux risques et aux bonnes pratiques de « cyber-hygiène »
• Repenser l’architecture de sécurité en adoptant une approche « zero trust » et en segmentant au maximum
• Investir dans la recherche et le développement en cybersécurité pour garder un coup d’avance

Les fournisseurs de LLM comme OpenAI ont aussi un rôle à jouer en mettant en place des garde-fous et des mécanismes de contrôle stricts sur leurs modèles. La bonne nouvelle, c’est que les auteurs de l’étude les ont avertis et ces derniers ont demandé de ne pas rendre publics les prompts utilisés dans l’étude, au moins le temps qu’ils « corrigent » leur IA.

Source

Si vous me lisez assidument, vous avez surement tout capté à la fameuse backdoor XZ découverte avec fracas la semaine dernière. Et là je viens de tomber sur un truc « rigolo » qui n’est ni plus ni moins qu’une implémentation de la technique d’exploitation de cette backdoor XZ, directement à l’intérieur d’un agent SSH.

Pour rappel, un agent SSH (comme ssh-agent) est un programme qui tourne en arrière-plan et qui garde en mémoire les clés privées déchiffrées durant votre session. Son rôle est donc de fournir ces clés aux clients SSH quand ils en ont besoin pour s’authentifier, sans que vous ayez à retaper votre phrase de passe à chaque fois.

Cet agent démoniaque s’appelle donc JiaTansSSHAgent, en hommage au cybercriminel qui a vérolé XZ, et ça implémente certaines fonctionnalités de la fameuse backdoor sshd XZ. En clair, ça vous permet de passer par cette backdoor en utilisant votre client SSH préféré.

Ce truc va donc d’abord générer sa propre clé privée ed448 avec OpenSSL puis, il faudra patcher la liblzma.so avec la clé publique ed448 correspondante. Là encore, rien de bien méchant, c’est juste un petit script Python et enfin, dernière étape, faudra patcher votre client SSH pour qu’il ignore la vérification du certificat.

Et voilà !

Une fois que vous avez fait tout ça, vous pouvez vous connecter à cœur joie avec n’importe quel mot de passe sur n’importe quel serveur qui dispose de cette faille. Bon après, faut quand même faire gaffe hein, c’est pas un truc à utiliser n’importe comment non plus. Vous devez respecter la loi, et expérimenter cela uniquement sur votre propre matériel ou avec l’autorisation de votre client si vous êtes par exemple dans le cadre d’une mission d’audit de sécurité. Tout autre utilisation vous enverra illico en prison, alors déconnez pas !

Voilà les amis, vous savez tout sur JiaTansSSHAgent maintenant. Pour en savoir plus, rendez-vous sur le repo GitHub de JiaTanSSHAgent.

Saviez vous que n’importe qui pouvait potentiellement ouvrir votre porte de chambre d’hotel en quelques secondes à peine, grâce à une simple faille de sécurité ? C’est ce qu’ont trouvé des chercheurs sur les serrures d’hôtel de la marque Saflok qui sont hyper répandues.

Ça ressemble à ça d’ailleurs, je suis certain que vous en avez déjà vu. Ce sont celles qui s’ouvrent avec une carte et malheureusement, il y en a des millions installées partout dans le monde.

Les chercheurs Ian Carroll, Lennert Wouters et leur équipe ont donc mis au point une technique baptisée « Unsaflok« , qui combine plusieurs vulnérabilités pour déverrouiller en un clin d’œil ces serrures présentes dans pas moins de 13 000 établissements à travers le monde. En analysant le chiffrement utilisé par le fabricant Dormakaba et le système RFID MIFARE Classic sur lequel reposent les cartes d’accès, ils ont ainsi trouvé le moyen de cloner n’importe quelle carte et d’ouvrir n’importe quelle porte.

Le procédé est d’une déconcertante simplicité : il suffit de récupérer une carte d’accès de l’hôtel ciblé (peu importe la chambre), d’en extraire un code spécifique grâce à un petit appareil à 300$, puis de générer deux nouvelles cartes ou de stocker les codes sur un Flipper Zero. Un premier badge réécrit une partie des données de la serrure, et le second l’ouvre dans la foulée. « Deux petits clics, et la porte s’ouvre« , résume Wouters. « Et ça marche sur absolument toutes les portes de l’hôtel.« 

Les détails techniques de cette faille ont été partagés avec Dormakaba en novembre dernier. Depuis, le fabricant s’efforce d’informer ses clients et de déployer des correctifs, qui ne nécessitent heureusement pas de remplacer physiquement toutes les serrures. Une mise à jour logicielle de la réception et une reprogrammation de chaque serrure suffisent dans la plupart des cas. Mais les chercheurs estiment que seuls 36% des verrous Saflok avaient été corrigés en juin, laissant encore des centaines d’établissements vulnérables.

Pour les clients, pas de panique. Carroll et Wouters conseillent de vérifier si votre hôtel est équipé de serrures Saflok (reconnaissables à leur lecteur RFID rond barré d’une ligne ondulée), et le cas échéant, de s’assurer que votre carte est bien au nouveau format MIFARE Plus ou Ultralight EV1 grâce à l’app NFC TagInfo dispo sur Android et iOS. Si ce n’est pas le cas, mieux vaut éviter de laisser des objets de valeur dans la chambre et bien tirer le verrou et la petite chaine lorsque vous y êtes.

Cette affaire rappelle d’ailleurs celle des serrures connectées Onity, dont une faille similaire révélée en 2012 est restée longtemps non corrigée, puisque le fabricant refusait d’assumer le coût du remplacement du matos. Cette brèche de sécurité a d’ailleurs été exploitée par un hacker pour dévaliser des chambres d’hôtel à travers tous les États-Unis…

Allez, si vous me lisez depuis votre chambre d’hôtel, bonne nuit quand même !

Source : Wired.

Depuis maintenant plusieurs années, les utilisateurs de Windows ont la possibilité de sécuriser leurs données avec Bitlocker, l’outil de chiffrement de Microsoft. C’est hyper simple à mettre en place et les constructeurs l’ont adopté depuis longtemps en intégrant à leurs ordinateurs la fameuse puce TPM (Trusted Platform Module).

Ce qui permet à Bitlocker d’y stocker toutes les informations critiques relatives à la configuration de l’ordinateur, mais surtout la Master Key, c’est-à-dire la clé qui permet de déchiffrer tout le contenu.

C’est là qu’entre en scène le chercheur en sécurité StackSmashing qui a mis au point un moyen d’extraire physiquement cette clé à l’air d’un Raspberry Pi Pico à moins de 10 balles, d’un peu de soft, et d’un petit PCB maison. Grâce aux pins de son PCB, il peut alors se brancher directement au bus LPC de la puce TPM qui se trouve au dos de la carte mère, ce qui permet d’intercepter les messages transmis (donc la master key) entre la puce TPM et le CPU de l’ordinateur.

Comme vous pouvez le voir sur la vidéo, son bricolage est spécifique à certains modèles de laptop Lenovo (Thinkpad), mais ça peut-être facilement adapté (ou alors en soudant des fils) à tout type d’ordinateur comme il le montre à la fin, avec la Surface Pro (et un petit trou dans sa carlingue)

Toutefois, n’allez pas croire que votre ordinateur est forcément sensible à cette attaque surtout s’il est récent puisqu’à présent, les fabricants de processeurs comme Intel ou AMD ont directement intégré le TPM au CPU, donc c’est plus la même partie de plaisir.

Source