Des pirates ont caché un cheval de Troie dans du code partagé sur GitHub pour révéler des failles de sécurité. Une technique qui vise directement les chercheurs en cybersécurité.
Depuis plus d'un an, Apple serait en connaissance d'une vulnérabilité permettant à quiconque de retrouver l'adresse réelle derrière un alias généré par la fonction de confidentialité d'iCloud+. La marque ne l'a pas corrigé.
Si vous utilisez Hide My Email d'Apple pour éviter de balancer votre vraie adresse mail à tous les sites qui vous la réclament, j'ai une mauvaise nouvelle les amis ! Tyler Murphy, cofondateur d'EasyOptOuts a découvert une entourloupe qui permettrait de remonter jusqu'à votre vraie adresse email... Ça craint ! Et cette faille serait dans la nature depuis plus d'un an !
Argh !
Alors petit rappel pour ceux qui ne connaissent pas Hide My Email. C'est une fonction liée à iCloud+ qui vous permet de générer des adresses jetables en @icloud.com. Vous vous inscrivez quelque part avec un alias bidon, et ensuite les mails sont redirigés vers votre boîte réelle, et comme ça le site ne voit jamais votre adresse perso. Mais dans ses tests d'exploitation, Tyler Murphy a eu un taux de succès de 100% avec tous ces alias révélant leur vrai propriétaire. Donc si vous avez des alias Hide My Email en cours d'usage, partez du principe qu'ils sont peut-être grillés.
C'est 404 Media, qui a sorti l'info, et malheureusement, ils ne détaillent pas la technique parce que pour le moment, ça fonctionne encore et ce n'est pas patché. Faut dire qu'une fois votre vraie adresse récupérée par quelqu'un de mal intentionné, celui-ci peut la recouper du contenu trouvable en ligne ou sur le dark net pour retrouver votre nom, vos autres comptes, et tout ce que Hide My Email était censé empêcher.
Mais le plus gênant dans cette histoire, c'est la gestion merdique du problème par Apple. En effet, Murphy signale le bug en juin 2024 et Apple répond un mois plus tard qu'ils ont lancé une enquête en interne. Puis en mars de cette année, ils annoncent avoir corrigé le souci, sauf que non. Murphy vérifie et la faille est toujours là. Alors en mai, Apple change de disque et lui demande carrément de la fermer : "nous vous serions reconnaissants de ne pas divulguer ces informations tant que notre enquête n'est pas terminée". Bref, taisez-vous pendant qu'on ne corrige rien ^^.
Alors le gars en a eu marre. Il a estimé que les utilisateurs de Hide My Email méritaient de savoir alors il a décidé de parler et je pense que pour ça, on peut le remercier ! Apple va peut-être finir par se bouger le cul.
Et nous en attendant, on fait quoi alors ? Hé bien pas grand-chose parce que tant que côté Apple y'a pas de patch, y'a rien à faire. Mais sachez le, rien ne vous oblige à mettre tous vos œufs dans le même panier donc si vous voulez des alias sur lesquels vous gardez vraiment la main, il existe des solutions maison comme générer vos propres adresses jetables via Cloudflare avec votre nom de domaine ou encore passer par la crème de la crème des services d'emails jetables .
Source : 404 Media
Deux chercheurs allemands ont mis au jour six vulnérabilités dans les fonctionnalités de partage sans fil d'Apple et de Google/Samsung. De quoi faire planter des appareils à proximité, sans aucune interaction de la victime.
Amazon Q, l'assistant de programmation dopé à l'IA que propose Amazon, pouvait se faire piéger d'une manière aussi simple qu'embarrassante.
Petit rappel pour situer. Amazon Q se greffe dans Visual Studio Code, l'éditeur de code de Microsoft que les développeurs utilisent au quotidien, et sert à écrire ou corriger du code à votre place.
Des chercheurs de Wiz, une société spécialisée dans la sécurité du cloud, ont découvert que cet assistant exécutait des commandes cachées à la simple ouverture d'un projet. La faille a reçu un identifiant officiel, CVE-2026-12957, et une note de gravité de 8,5 sur 10, ce qui est sérieux.
Le problème venait d'un fichier de configuration un peu particulier. Pour fonctionner, Amazon Q lit un fichier nommé .amazonq/mcp.json, qui s'appuie sur le MCP, pour Model Context Protocol, une sorte de prise standardisée qui permet de brancher une IA sur des outils extérieurs.
Sauf qu'il suffisait d'ouvrir un dépôt de code et d'activer Amazon Q pour que l'extension aille lire ce fichier et exécute son contenu. Sans fenêtre de confirmation, sans demander votre avis, et sans vérifier si vous faisiez confiance au dossier que vous veniez d'ouvrir.
Et c'est là que ça devient vraiment fourbe. Ces commandes héritaient de tout votre environnement de travail. Du coup, elles pouvaient récupérer au passage vos clés d'accès au cloud d'Amazon, vos jetons de connexion, vos secrets d'API et même l'accès à votre agent SSH, ce trousseau qui garde en mémoire vos connexions aux serveurs distants. En clair, tout ce qu'un développeur laisse ouvert pendant qu'il travaille.
Le plus gênant, c'est que Visual Studio Code possède justement une sécurité prévue pour ça, la confiance d'espace de travail, qui vous demande si vous validez un dossier avant de le laisser agir. L'extension d'Amazon passait tout bonnement par-dessus.
Pour un pirate, le piège était facile à tendre. Il suffisait de glisser ce fichier dans un projet open source d'apparence anodine, ou dans un bout de code partagé sur un forum, et d'attendre qu'un développeur qui récupère un projet l'ouvre pour voir comment il fonctionne.
Amazon a corrigé le tir dans la version 1.65.0 de son serveur de langage et a confirmé la correction. Wiz note d'ailleurs que des failles très proches ont déjà touché d'autres outils de code boostés à l'IA.
Donner autant de pouvoir à une IA sans le moindre garde-fou, et laisser filer les clés du cloud avec, ça reste une erreur de débutant pour un géant comme Amazon.
Source : The Register
Une faille très bien planquée dans le code depuis 1997, vient seulement d'être corrigée. Elle s'appelle Squidbleed, référencée comme CVE-2026-47729, et elle touche Squid, un serveur proxy open source que des entreprises, des écoles et des fournisseurs d'accès utilisent depuis des lustres pour mettre en cache, filtrer et surveiller le trafic réseau qui transite chez chez eux.
Et ça fuite fort en fait. Un individu malveillant, qui serait déjà autorisé à passer par le même proxy, peut récupérer la requête HTTP en clair d'un autre utilisateur, avec tout ce qu'elle transporte au passage : mots de passe, clés d'API, cookies de session, et j'en passe. De quoi se faire passer pour la victime sans jamais avoir eu à connaître son mot de passe. Les chercheurs parlent d'un cousin de Heartbleed, la grande fuite mémoire de 2014, sauf que celle-ci vise spécifiquement le trafic non chiffré, l'HTTPS restant à l'abri dans son tunnel.
Comment un bug pareil a-t-il pu survivre presque trente ans de relectures ? Tout part d'une rustine ajoutée en 1997 pour gérer de vieux serveurs FTP NetWare qui bourraient leurs listings d'espaces en trop. Le code de Squid saute ces espaces dans une boucle. Sauf que voilà, quand le serveur d'en face ne renvoie aucun nom de fichier après l'horodatage, la fonction strchr, censée signaler la fin de la chaîne de caractères, renvoie en fait un pointeur valide au lieu du NULL que tout le monde attendait. La boucle continue, déborde du tampon mémoire et recrache au passage des morceaux de mémoire voisine, là où dormait justement la requête d'un autre internaute.
L'ironie, c'est que cette zone n'est jamais remise à zéro avant d'être réutilisée. Un tampon de 4 Ko qui contenait il y a un instant la requête d'une victime en garde donc l'essentiel, prêt à repartir vers l'attaquant comme s'il s'agissait d'un banal nom de fichier.
La découverte, elle, dit quelque chose de l'époque. Lam Jun Rong, chercheur chez Calif.io, n'a pas trouvé la faille tout seul : il bossait lui aussi avec Claude Mythos Preview, l'outil d'IA d'Anthropic qui a fini par être désactivé. En lui demandant d'explorer le comportement complet de la machine à états FTP, l'IA a mis le doigt sur ce cas tordu de strchr, en citant de mémoire la norme du langage C. Comme elle a avalé tout le standard, ce piège pourtant connu n'était pour elle qu'un fait parmi d'autres. Peu de développeurs humains auraient parié là-dessus, ce qui explique sans doute comment un bug d'une seule ligne a traversé trente ans de revue de code.
Côté correctif, Squid 7.6 est sorti le 8 juin et ajoute la vérification qui manquait. Vous pouvez aussi tout simplement couper le support FTP, dont plus personne ne se sert vraiment depuis que les navigateurs l'ont abandonné. Le bug avait été signalé dès avril.
Bref, encore une faille prise en charge par une IA, ça devient une habitude.
Source : https://blog.calif.io/p/squidbleed-cve-2026-47729
Environ 75 000 pare-feu Fortinet ont vu leurs identifiants de connexion volés puis vérifiés un par un, des FortiGate, ces boîtiers qui filtrent l'accès au réseau des entreprises et servent très souvent de porte d'entrée VPN pour les salariés en télétravail.
Baptisée FortiBleed par les chercheurs qui l'ont mise au jour, la campagne couvre 194 pays et plus de 21 000 domaines, soit à peu près la moitié des pare-feu Fortinet exposés sur Internet à l'heure actuelle.
Parmi les organisations dont les accès se sont retrouvés dans la nature, on relève des noms qui n'ont rien d'amateur en matière de sécurité : Foxconn, Samsung, Comcast, Siemens, Lenovo, FedEx, Accenture ou encore Oracle.
Toute l'ironie de l'affaire tient là : le pare-feu, l'appareil précisément chargé de tenir les intrus à l'écart du réseau, s'est transformé en point d'entrée qui leur a ouvert la porte en grand.
Sur le plan technique, les attaquants interceptaient l'authentification du SSL VPN, cet accès distant chiffré qui permet de rejoindre le réseau interne d'une entreprise depuis l'extérieur, récupéraient l'empreinte chiffrée des mots de passe et la cassaient sur une grappe de 45 cartes graphiques pilotée par l'outil Hashtopolis, avant de basculer vers l'Active Directory, l'annuaire qui gère l'ensemble des comptes Windows de l'organisation.
Les volumes traités donnent la mesure de l'opération : 1,16 milliard de tentatives de connexion lancées contre 320 000 équipements FortiGate, et 2,1 milliards d'autres dirigées en parallèle vers 160 000 serveurs de bases de données Microsoft.
Au moins quatre organisations ont été entièrement compromises, avec déplacement des attaquants d'une machine à l'autre à l'intérieur du réseau, au Japon, à Taïwan, au Vietnam, en Irak et en Turquie. Le cas le plus sérieux touche un sous-traitant turc de la défense, membre de l'OTAN, chez qui des documents classifiés ont été volés. Tout ça est attribué à un groupe cybercriminel russophone à plusieurs opérateurs.
C'est le chercheur Bob Diachenko qui a repéré les intrusions, avant que Hudson Rock (une société spécialisée dans l'analyse des données aspirées par les logiciels espions) ne décortique le tout et que Kevin Beaumont confirme que les identifiants étaient bien valides.
Hudson Rock a d'ailleurs mis en ligne une liste des domaines concernés, histoire que chaque entreprise vérifie si elle figure au tableau de chasse.
Fortinet, de son côté, minimise et parle d'un recyclage de données issues d'incidents passés et de simples attaques par force brute, pas d'une nouvelle faille dans ses produits.
Sauf que voilà : la plupart des boîtiers concernés sont toujours en ligne. Recyclées ou pas, ces données ouvrent une porte bien réelle tant que les mots de passe VPN et administrateur n'ont pas été changés, et changer tous les accès d'un pare-feu dans une grande organisation ne se fait pas en claquant des doigts.
Bref, faille ou vieux stock recyclé, ça ne change rien pour les boîtes touchées : on change les mots de passe VPN tout de suite, et on active la double authentification.
Source : The Register
Une seule petite ligne de code envoyée au mauvais endroit pouvait transformer un Surface Laptop en bloc de métal inutilisable. C'est sur cette faille que Microsoft a discrètement travaillé pendant trois mois, avant qu'elle ne soit rendue publique le 12 juin.
L'histoire commence de façon assez improbable. Jack Darcy, un chercheur en sécurité australien, a demandé à Microsoft Copilot (l'assistant IA intégré à Windows) de régler le rétroéclairage de son écran, rien de dingue donc. Bien gentil, Copilot écrit tout seul un script Python, l'exécute, et la paf, il rend l'ordinateur totalement inopérant. Plus de démarrage, plus d'accès au BIOS, rien, queudalle.
En creusant, Darcy comprend ce qui vient de se passer. Le script a écrit n'importe quoi dans le firmware du SAM, le Surface Aggregator Microcontroller, cette petite puce qui coordonne le matériel sur les Surface : alimentation, ventilateurs, clavier, capteurs. Une fois sa mémoire corrompue, la machine ne sait tout simplement plus démarrer.
Le problème de fond, c'est que cette puce n'avait aucun garde-fou. Elle acceptait n'importe quelle valeur en écriture sans vérifier si elle avait le moindre sens. Pire, les commandes de lecture et celles d'écriture partageaient la même numérotation, ce qui rendait toute exploration prudente impossible. "Vous ne pouvez littéralement pas scanner deux commandes qui se suivent sans une chance sur deux de tomber sur une commande d'écriture", résume Darcy.
Du coup, un seul paquet expédié pouvait griller la carte mère pour de bon. Aucune réparation logicielle, aucune réinitialisation d'usine, aucun accès USB de secours : direction le remplacement complet de la carte mère, soit plusieurs centaines d'euros.
Tout n'est pas si noir quand même. Pour déclencher la catastrophe, il fallait déjà disposer des droits administrateur sur la machine et avoir désactivé Secure Boot et Secure Core, les deux protections activées par défaut sur les Surface. Autrement dit, un parc d'entreprise géré normalement ne risquait rien, et les seules machines réellement exposées étaient celles des bidouilleurs tournant sous Linux, en configuration gaming allégée ou avec des pilotes maison.
Les modèles concernés vont du Surface Laptop 3 au Surface Laptop 6 et du Surface Book 1 au Surface Book 3. Les Surface Go semblent épargnés, et les versions ARM n'ont pas été testées.
Côté correctif, Microsoft a plutôt bien joué le jeu. Prévenu le 10 mars, l'éditeur a reconnu le défaut puis déployé des mises à jour de firmware via Windows Update dès le mois de mars, si bien que la grande majorité des appareils touchés sont désormais protégés. Darcy a récupéré un Surface tout neuf pour le dédommager.
Un point chiffonne quand même. Microsoft a refusé d'attribuer un CVE, l'identifiant officiel qui répertorie une faille de sécurité, estimant que le bug "n'atteignait pas le seuil" requis. Pour un défaut capable de tuer une machine de façon irréversible, l'argument laisse songeur.
Pour la suite, Redmond mise sur le langage Rust, réputé pour empêcher ce genre de débordements mémoire. Le firmware embarqué est en cours de réécriture intégrale, baptisée "Secure EC", tout comme une partie de l'UEFI sous le nom de "Project Patina".
Bref, un Copilot qui brique tout seul le PC sur lequel il tourne, voilà une démo involontaire dont Microsoft se serait bien passé.
Source : The Register
BitLocker, je le rappelle c'est quand même le truc censé protéger vos données en cas de vol de votre bécane. Sauf que voilà, la théorie et Redmond, ça fait parfois deux... Le chercheur en sécurité Chaotic Eclipse (déjà à l'origine de BlueHammer ) vient de balancer une nouvelle vulnérabilité zero-day baptisée GreatXML , qui réduit cette promesse en miettes.
Le truc tourne autour de la façon dont Windows Recovery Environment (WinRE) traite les fichiers de configuration lors du démarrage. Plus précisément, la faille exploite des résidus laissés par l'outil d'analyse hors ligne de Microsoft Defender.
Cela signifie que si vous avez déjà lancé un scan Defender Offline, votre machine conserve des artefacts sur la partition de récupération. C'est là que le piège se referme car en manipulant des fichiers XML de configuration (notamment unattend.xml) sur la partition de récupération, un attaquant peut forcer le système à ouvrir un terminal avec les privilèges SYSTEM lors du passage en mode WinRE. Le tout sans avoir besoin de se connecter à la session, bien sûr...
Le résultat ?
Un accès complet et sans restriction au volume protégé par BitLocker. Pas besoin de fer à souder ou de bidouiller la carte mère avec un Raspberry Pi comme pour d'autres exploits TPM, là c'est une simple faiblesse logique logicielle qui permet de tout déverrouiller.
Alors oui, l'attaque nécessite un accès physique à la machine (ou un autre accès permettant de modifier la partition de récupération). Mais comme le rôle même de BitLocker est de protéger un appareil volé physiquement, c'est une sacrée épine dans le pied des administrateurs système ! D'autant plus qu'aucun correctif officiel n'a encore été publié par Microsoft.
Cette divulgation publique intervient dans un contexte tendu puisque Chaotic Eclipse multiplie les dumps de zero-days Windows suite à un différend avec le programme de bug bounty MSRC de Microsoft. On a déjà eu le droit à YellowKey et RoguePlanet ces dernières semaines et y'a peu de chances que ça s'arrête.
Bref, c'est la guerre ouverte !
Maintenant, même s'il n'y a pas encore de recommandations officielles de Microsoft pour cette faille spécifique, quelques mesures de bon sens permettent de limiter la casse. D'abord, configurer un mot de passe UEFI pour bloquer le boot externe. Ensuite, activer le mode TPM + PIN pour BitLocker car sans ce code pré-boot, la clé de déchiffrement n'est pas libérée, même si l'attaquant arrive à faire pop son shell.
Et si vous voulez couper court à toute exploitation de ce type, il reste l'option de désactiver complètement WinRE via la commande reagentc /disable.
Bref, en attendant que Microsoft sorte un patch, vous savez ce qu'il vous reste à faire.
Le Catalyst SD-WAN Manager de Cisco, anciennement appelé vManage, c'est la salle de contrôle depuis laquelle une grande entreprise règle, surveille et met à jour à distance le réseau entier qui relie ses dizaines d'agences, usines ou boutiques entre elles, et c'est ce logiciel très sensible qui se retrouve aujourd'hui troué par une faille déjà exploitée dans la nature.
Le pire ? Aucun correctif.
Référencée CVE-2026-20245 et notée 7,8 sur 10 sur l'échelle CVSS, le barème qui classe la dangerosité des failles de zéro à dix, la vulnérabilité permet à un attaquant déjà titulaire d'un compte d'administrateur réseau, le profil baptisé netadmin chez Cisco, de téléverser un fichier piégé que le logiciel contrôle mal, puis d'exécuter ses propres commandes en root, c'est-à-dire avec les pleins pouvoirs sur la machine.
Et toutes les versions sont concernées.
Peu importe que la console tourne sur les serveurs de l'entreprise, dans les offres Cloud et Cloud-Pro hébergées par Cisco, ou dans la déclinaison FedRAMP réservée aux administrations américaines, le trou est exactement le même partout.
Il y a plus inquiétant, car dans plusieurs cas bien réels observés par Cisco, l'attaque ne s'est pas arrêtée à la console : elle a poussé une modification de configuration jusqu'aux routeurs et boîtiers installés dans chaque site distant, ce qui revient, quand on tient la salle de contrôle, à tenir d'un coup l'ensemble du réseau de la boîte.
Une nuance, quand même.
Il faut déjà être authentifié pour déclencher la faille, sauf que Cisco conseille du coup d'installer en priorité les correctifs sortis le 14 mai pour deux autres vulnérabilités, CVE-2026-20182 et CVE-2026-20127, dont l'enchaînement offre justement à un assaillant les fameux droits netadmin qui ouvrent ensuite la porte au reste.
En attendant un vrai patch, dont la date n'est pas connue, l'éditeur se contente de publier des indicateurs de compromission, en clair des traces à repérer dans les journaux du serveur pour savoir si on s'est déjà fait avoir.
Et ce n'est pas la première. C'est même la sixième faille SD-WAN exploitée chez Cisco depuis janvier, et le deuxième zero-day, une faille attaquée avant l'arrivée du moindre correctif, en à peine deux mois.
Bref, un accès root activement exploité sur un équipement aussi central, et toujours pas de rustine, ça commence à faire vraiment beaucoup.
Source : The Register
Un chercheur en sécurité a réussi à prendre le contrôle d'un ordinateur en passant par une simple enceinte branchée en USB, à distance, et sans jamais s'approcher de la machine.
L'appareil en question est la Sound Blaster Katana V2X, une barre de son vendue autour de 280 euros par Creative Technologies, le fabricant singapourien d'accessoires audio bien connu des joueurs. Elle se branche aussi bien sur un PC, un Mac ou un Linux, en USB comme en Bluetooth. Je la connais d'ailleurs plutôt bien, puisque je l'ai testée sur Mac4ever .
Rasmus Moorats, un chercheur, est tombé sur la faille un peu par hasard. Il voulait juste écrire un petit logiciel Linux pour piloter son enceinte, et il a découvert un protocole maison de Creative qui permet d'envoyer des commandes à l'appareil, comme changer la couleur des LED ou régler l'égaliseur.
Sauf que voilà : son téléphone en Bluetooth a pu se connecter à l'enceinte, elle-même reliée à un PC en USB, sans aucune authentification et sans même avoir été appairé au préalable. Et parmi les commandes disponibles, il y en avait une intitulée "envoyer un nouveau micrologiciel à l'appareil".
Le micrologiciel, c'est le programme interne qui fait tourner l'enceinte. Normalement, un appareil refuse d'installer un programme qui n'est pas signé par son fabricant, un peu comme un coffre qui n'accepterait que la clé d'origine. Là, rien de tout ça : Moorats a pu remplacer le firmware officiel par le sien, sans la moindre vérification.
Sa première démonstration est assez simple, avec le mot "patched" affiché sur l'écran LED de l'enceinte. Puis il s'est demandé jusqu'où on pouvait pousser le bouchon.
Et la réponse fait un peu froid dans le dos. L'enceinte sait se présenter à l'ordinateur comme un périphérique d'interface humaine, la catégorie qui regroupe les claviers, les souris et les webcams. Moorats a modifié cette carte d'identité USB pour que l'enceinte se déclare aussi comme un clavier, puis lui a fait taper des touches toute seule.
En enchaînant le tout, il a pu, totalement à distance et par les airs, envoyer son firmware piégé à une enceinte qu'il n'avait jamais appairée, la faire redémarrer, puis lui faire taper une commande et l'exécuter sur le PC. Dans un vrai scénario d'attaque, ce serait l'ouverture du terminal de commandes de Windows et le collage d'une ligne malveillante.
Pire encore : un attaquant pourrait au passage désactiver la mise à jour du micrologiciel, ce qui rendrait son code impossible à effacer. Et le Bluetooth de l'enceinte reste allumé en permanence, même en veille, sans aucun moyen de le couper.
Il y a quand même une limite de taille. L'attaquant doit se trouver à portée Bluetooth de l'enceinte. On parle donc d'un voisin, d'un colocataire ou d'un bureau mitoyen, pas d'un pirate à l'autre bout du monde.
Moorats a prévenu Creative, sans réponse, puis a fait intervenir le CERT de Singapour, l'agence publique qui gère les alertes de sécurité. Le fabricant a fini par répondre que ses ingénieurs ne considèrent pas ce comportement comme une faille. Aucun correctif n'est donc prévu.
Le seul vrai garde-fou aujourd'hui, c'est un correctif publié par des bidouilleurs de la communauté. Quand un fabricant vous explique qu'un clavier fantôme piloté par le voisin n'est pas un problème, c'est quand même un peu gênant.
Source : ARS Technica
La bibliothèque libinput est passée en version 1.31.2, et pas pour ajouter des fonctions, mais pour boucher un trou de sécurité plutôt vilain. C'est elle qui gère vos périphériques d'entrée (clavier, souris, pavé tactile, manette) sur la quasi-totalité des Linux modernes, aussi bien sous Wayland que sous l'ancien serveur graphique X.Org.
Autant dire qu'elle tourne sur presque toutes les machines de bureau sous Linux, des plus grand public aux plus pointues.
Le problème permettait d'exécuter du code arbitraire avec les droits root, c'est-à-dire les pleins pouvoirs sur le système. Et tout ça en passant par un détail qu'on n'imagine pas dangereux, le nom physique d'un faux périphérique.
Sur Linux, n'importe quel logiciel peut fabriquer un périphérique virtuel via deux interfaces du noyau, uinput et uhid. Pour les regrouper, libinput s'appuie sur udev, le composant qui détecte et configure tout ce qu'on branche sur la machine.
Et c'est là que ça coince. Un attaquant pouvait créer un appareil bidon dont l'attribut PHYS, le chemin physique du matériel, contenait un simple retour à la ligne. Du coup, udev lisait cette unique valeur comme deux lignes séparées, donc deux paires clé-valeur, dont une totalement injectée par l'attaquant.
Cette ligne injectée suffisait à détourner le comportement de udev et, au bout de la chaîne, à faire tourner la commande de son choix en root. Une injection par saut de ligne. Bête, mais redoutable.
Reste une nuance importante. Fabriquer un tel périphérique demande normalement les droits root, ce qui limite déjà beaucoup le danger. Sauf que certaines règles udev personnalisées ouvrent la porte aux utilisateurs normaux.
L'exemple cité est parlant. Installer le paquet "steam-devices" sur Fedora, ce que fait n'importe quel joueur pour que ses manettes soient correctement reconnues, suffit à exposer la faille à toute personne connectée à la session. Un geste parfaitement banal, donc.
La faille a été repérée par un chercheur surnommé Csome, et Peter Hutterer, le mainteneur historique de libinput, a publié le correctif dans la 1.31.2. La marche à suivre tient en une ligne, mettre à jour dès que votre distribution pousse le paquet.
Une faille root planquée dans le nom d'une fausse manette, déclenchée par un paquet aussi anodin que celui de Steam, ça a quand même quelque chose de franchement pénible.
Source : Phoronix
Tout se joue dans une conversation polie avec l'assistant IA du support de Meta, le robot conversationnel censé dépanner les utilisateurs quand ils ont un souci avec leur compte.
Le principe tient en quelques étapes. Le pirate se connecte d'abord via un VPN, un outil qui maquille sa localisation, pour faire croire qu'il se trouve dans la ville de sa victime et ne pas déclencher les protections automatiques d'Instagram.
Ensuite, il ouvre une discussion avec le Meta AI Support Assistant et lui demande tout bonnement d'ajouter une nouvelle adresse e-mail au compte ciblé.
Le robot envoie alors un code de vérification vers l'adresse fournie par le pirate. Celui-ci renvoie le code au chatbot, qui affiche aussitôt un bouton pour réinitialiser le mot de passe. Nouveau mot de passe, et le compte change de mains.
Le plus dingue, c'est qu'à aucun moment l'attaquant n'a eu besoin de toucher à la vraie boîte mail de la victime. Pas de phishing élaboré, pas de faux site à monter, pas de malware à glisser. Le support officiel faisait tout le travail à sa place.
Côté victimes, ça pique. Le compte de la Maison-Blanche de l'ère Obama, inactif depuis 2017, celui du sergent-chef de l'US Space Force John Bentivegna, ou encore celui de la chercheuse en sécurité Jane Wong, qui a raconté s'être fait voler le sien. S'ajoutent plusieurs comptes aux pseudos très courts, ceux qui se revendent cher au marché noir, dont la valeur cumulée dépasserait le demi-million de dollars.
L'attaque a été mise en scène dans une vidéo de démonstration, publiée fin mai sur Telegram par un groupe de pirates pro-iraniens, avec un mode d'emploi qui a tranquillement circulé sur plusieurs canaux.
Heureusement, il y a un garde-fou. L'exploit ne marche pas contre les comptes protégés par une authentification à deux facteurs, ce deuxième code demandé en plus du mot de passe, souvent reçu par SMS. Même la version la plus basique de cette protection suffisait à bloquer les pirates net.
Chez Meta, le porte-parole Andy Stone affirme que le problème est réglé et que les comptes touchés sont en train d'être sécurisés. Un correctif d'urgence a été déployé , et l'entreprise précise qu'aucune base de données interne n'a été piratée. Le trou était dans le chatbot, pas dans les serveurs.
Reste le fond du problème. Pour Ian Goldin, chercheur en cybersécurité chez Black Lotus Labs, ces assistants IA ouvrent une toute nouvelle surface d'attaque, et on va sûrement en voir beaucoup d'autres du même genre dans les mois qui viennent.
Bref, un chatbot conçu pour rendre service qui finit par surtout servir les pirates, c'est le genre de bug qu'on n'avait pas avec un bon vieux formulaire.
Source : ARS Technica
Le support de Meta, quand vous contactez Instagram pour un souci de compte, c'est 100% IA maintenant. Je l'ai fait y'a pas longtemps et c'est assez surprenant, même s'il faut le reconnaître, ça fonctionne bien. Et si je vous parle de ça ce matin, c'est que pendant des semaines, ce chatbot a refilé l'accès à des comptes à qui savait lui raconter la bonne histoire.
Et c'est pas un exploit de génie ni une faille bien planquée mais juste un bot de support trop serviable à qui on explique qu'on s'est fait pirater, et qui envoie le code de réinitialisation... sur l'adresse mail de l'attaquant. Oui, il est aussi précautionneux de vos accès que votre gardien d'immeuble ^^.
En gros l'attaquant écrit au support IA, prétend être le proprio d'un compte "piraté", demande à recevoir les codes sur son email et l'IA accepte l'adresse sans sourciller. Hop, un petit lien de reset, un nouveau mot de passe, et le vrai propriétaire ne voit rien venir !
Bon, ce n'était pas magique non plus, mais une fois le bot embobiné, il lâchait l'accès.
Le truc à retenir surtout, c'est que la double authentification , elle, a bien fait barrage. Les comptes qui l'avaient activée n'ont pas été pris, donc si vous traînez sur Insta sans, allez l'activer tout de suite !
Parce que les dégâts ont été bien réels. Des comptes à grosse visibilité y sont passés, dont le compte dormant @obamawhitehouse et ses millions d'abonnés, qui s'est remis à publier n'importe quoi avant d'être nettoyé.
Des groupes Telegram s'étaient montés autour de ces prises de contrôle, des chercheurs comme ZachXBT ont suivi le mouvement, et les pseudos courts comme @hey valant une petite fortune se sont retrouvés sur le marché noir. En gros, un vrai business du vol de compte a été monté sur le dos du chatbot !
Y'a 10 ans, c'était déjà la récupération de compte qui faisait tomber des comptes Facebook encore aujourd'hui le maillon faible n'a pas changé...
Meta a corrigé le problème en urgence et dit avoir sécurisé les comptes touchés.
Si vous pensez être victime, direction "Mot de passe oublié" puis "Mon compte a été piraté", et une fois récupéré, vérifiez bien que l'email et le numéro liés au compte sont les vôtres (l'attaquant a pu les remplacer) avant de dégager les sessions inconnues. Pour le reste, un petit tour par les bons réflexes de sécurité ne fait jamais de mal.
Bref, activez la double authentification et j'espère qu'un jour, les grosses boites arrêteront d'utiliser l'IA pour garder leurs clés.
Connexion