Un truc franchement rageant remonte du côté de chez Google Cloud, et c'est The Register qui a mené l'enquête. Plusieurs développeurs ont vu leur facture Google Cloud exploser entre 3000 et 10000 dollars en quelques minutes, pour des services qu'ils n'ont jamais utilisés : génération vidéo Veo 3, tokens du modèle Gemini, le tout via leurs clés API Maps. Et le pire, c'est qu'ils avaient suivi à la lettre les recommandations officielles de Google.

La doc Google vous dit en effet de mettre votre clé Maps en clair côté client (dans le JavaScript de votre site, par exemple), parce qu'elle sert à afficher une carte dans un navigateur. Sauf que voilà, si vous activez sur votre projet Google Cloud d'autres APIs (comme Gemini ou Veo, l'outil de génération vidéo de Google), la même clé peut être utilisée pour appeler ces services.

Un bot malveillant trouve la clé sur n'importe quel site (le code source d'une page web est lisible par tout le monde), s'en sert pour générer des milliers de vidéos IA, et c'est le proprio du projet qui paie l'addition.

Le plus pénible, ce sont les spending caps, ces plafonds de dépenses que Google met en avant comme garde-fou. En pratique, ils ne déclenchent qu'une alerte par mail, pas une coupure réelle des services.

Vous recevez l'alerte alors que la facture grimpe déjà depuis dix minutes, et le temps de réagir, c'est déjà fini. Plusieurs devs disent avoir vu leur compte passer de quelques euros à plusieurs milliers en moins d'une heure. Ça pique.

Et Google ? La firme refuse les remboursements en parlant d'un problème "industrie-wide", autrement dit "tout le monde a ce souci, c'est pas notre faute". Pratique pour eux, moins pour les développeurs qui se retrouvent avec une note salée pour des services qu'ils n'ont jamais demandés.

Le vrai sujet, c'est le mélange clé Maps publique par design + accès Gemini activé par défaut sur le même projet. Ce n'est pas une faille au sens technique du terme, c'est une configuration que Google a choisie et qui transforme chaque clé Maps en bombe potentielle pour le portefeuille de celui qui l'utilise.

Si vous bossez sur Google Cloud, allez donc vérifier que Gemini et Veo ne sont pas activés sur les projets qui n'en ont pas besoin, et restreignez vos clés Maps à des domaines précis dans la console. C'est moche, mais visiblement c'est à vous de le faire.

Source : The Register

Le gang ransomware Nitrogen a balancé Foxconn sur son site de fuite avec 8 To de données et 11 millions de fichiers volés, selon The Register.

Schémas hardware, instructions d'assemblage, topologies de datacenters côté client. Et comme Foxconn assemble une bonne partie de ce que vous avez dans votre poche ou sur votre bureau (iPhones pour Apple, GPU pour Nvidia, serveurs pour Google, machines pour Intel et Dell), la liste des marques potentiellement exposées fait peur.

L'usine de Mount Pleasant dans le Wisconsin a été paralysée plusieurs jours. Foxconn a fini par confirmer l'incident après plusieurs semaines de silence, en assurant que la production avait été rétablie et que l'enquête se poursuivait avec les autorités.

Nitrogen, lui, est un gang ransomware connu depuis 2024. Un ransomware, pour les non-initiés, c'est un logiciel qui chiffre les fichiers d'une boîte puis demande une rançon pour les déchiffrer. Le mode opératoire classique de Nitrogen : voler les données avant de chiffrer, et menacer de tout publier si la victime refuse de payer.

Le détail croustillant qui devrait calmer toute envie de cracher au pot : Coveware, la société américaine spécialisée dans la négociation de ces affaires, a démontré dès février que le décrypteur de Nitrogen est buggé.

Pour dire ça plus simplement, vous payez la rançon, vous récupérez un outil censé déchiffrer vos fichiers, et il ne fonctionne pas correctement. Une bonne partie des données reste illisible après paiement. C'est documenté. Ce n'est pas la première fois qu'un gang livre un outil pourri, mais c'est rarement aussi évident.

Côté contenu dérobé, on parle de plans d'assemblage de cartes-mères et de schémas électroniques détaillés, mais surtout de topologies de datacenters. La topologie d'un datacenter, c'est en gros la carte qui montre comment toutes les machines, les baies et le réseau sont agencés.

C'est exactement le genre d'info qu'un attaquant cherche pour préparer une intrusion future. Apple et Nvidia n'ont pas commenté, ce qui ne veut pas dire grand-chose à ce stade, mais ça veut dire qu'il y a probablement quelques juristes qui n'ont pas beaucoup dormi cette semaine.

Source : The Register

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

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

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

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

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

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

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

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

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

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

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

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

Source : The Hacker News

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

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

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

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

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

Source

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

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

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

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

Alors comment ça marche ?

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

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

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

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

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

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

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

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

Tester avec Lima sur macOS

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

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

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

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

echo 3 > /proc/sys/vm/drop_caches

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

Alors que faire ?

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

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

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

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

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

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

Y'a des génies du crime, et puis y'a Peter Stokes, alias Bouquet, 19 ans, presque toutes ses dents, double nationalité américano-estonienne, et surtout membre de Scattered Spider, le collectif qui a déjà plumé MGM et Caesars.

Le mec a tellement bien réussi son coup qu'il est parti se payer des vacances à Tokyo, sauf que pour fêter ça, en bon teubé, il a posté sur Snapchat des selfies de sa grosse tête avec un tout nouveau bijou : un collier en diamants HACK THE PLANET. Comme dans le film de 1995 mais en plus bling bling !

Hé bien grâce à ça, le FBI a fini par le coffrer lors de son escale d'Helsinki.

Bouquet (oui, j'ai pas précisé mais c'est son pseudo) opérait donc dans le groupe Scattered Spider, ce collectif d'ados anglophones qui ne s'embête pas avec des failles zero-day parce que de toute façon, ils ne sauraient pas les utiliser.

À la place, ils ont leur propre méthode super technique vous allez voir... ils appellent le support IT de la cible et embobinent un pauvre mec pour qu'il reset le 2FA d'un admin.

Et voilà comment notre cher Bouquet a pu sortir 100 Go de données d'un revendeur de produits de luxe (la plainte désigne sobrement la "Company F", mais ça pue Harrods d'après la presse anglaise) en seulement quelques heures, réclamé 8 millions de rançon, et causé plus de 2 millions de dégâts.

Du coup, plainte fédérale à Chicago, 6 chefs (wire fraud, conspiracy, computer intrusion comme ils disent là-bas avec l'accent cowboy), + extradition vers les USA en cours. C'est le bouquet final pour lui ! (Oui, jeu de mots, roh roh roh).

Tyler Buchanan, 24 ans, autre membre du club, a de son côté déjà plaidé coupable d'avoir empoché 8 millions en crypto via du SMS phishing. Faut dire qu'en 2024, le groupe envoyait fièrement des messages genre "Fuck off, FBI" aux agents fédéraux qui enquêtaient sur eux.

Très rebelles nos kikoulool ! Enfin, comme vous le savez, qui fait le malin tombe dans le ravin, et qui fait le mariole avec un collier finit avec des bracelets ^^. (J'ai pas trouvé mieux, déso... lol)

Bref, Bouquet vient à lui seul d'écrire le chapitre 1 du manuel "Comment ne PAS être un cybercriminel à succès" et dont la règle n°1 est : "Si t'es recherché par le FBI, ne montre pas ton butin sur Snapchat"

Source

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

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

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

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

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

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

Source

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

Trois décennies que ReactOS essaie de devenir un clone open source de Windows, et le projet vient de mettre en place deux changements assez gros pour mériter un coup d'œil.

La 0.4.16 est entrée en phase finale cette semaine, avec des release candidates qui devraient suivre dans la foulée, et elle apporte une image d'installation unifiée plus un nouveau storage stack ATA. Deux gros morceaux qui devraient simplifier la vie de ceux qui veulent tester le truc sur de vraies machines.

Premier changement, fini les deux ISOs séparées. Avant, il fallait choisir entre l'image live (pour tester sans installer) et l'image d'installation. Maintenant tout est dans une seule image. Voilà.

Du coup, vous pouvez booter en live, voir si ça marche sur votre machine, et lancer l'installation directement depuis là si ça vous convient. Au passage, le vieil installeur en mode texte façon Windows 2000 risque d'être bientôt mis à la retraite au profit d'un parcours plus moderne.

Le deuxième changement est plus technique mais peut-être plus important. Le projet a remplacé son driver de stockage UniATA, qui datait de pas mal d'années, par un nouveau storage stack PnP-aware compatible NT6+.

Concrètement, ça veut dire un meilleur support des contrôleurs ATA et AHCI modernes, et donc une meilleure compatibilité avec le matos réel qu'on trouve dans les PC de 2026. C'était l'un des plus gros problèmes pour faire tourner ReactOS sur du hardware physique plutôt qu'en machine virtuelle.

ReactOS reste avant tout un projet pour les passionnés. La compatibilité avec les applications Windows modernes est encore très partielle, et quasi tout ce qui dépend de DirectX récent ou des frameworks .NET de dernière génération va planter.

Mais pour faire tourner un vieux logiciel pro orphelin, un jeu Win98 ou XP, ou simplement explorer comment fonctionne un OS de type Windows en open source, c'est tout indiqué.

Pour rappel, ReactOS n'est pas une distribution Linux qui imite Windows, c'est une réimplémentation complète et indépendante qui vise la compatibilité binaire avec les drivers et applications Windows NT.

L'objectif est de pouvoir lancer un .exe Windows directement, sans Wine ni couche d'émulation. Le projet est sur les rails depuis 1996, et même si ça avance lentement, chaque release apporte son lot d'améliorations concrètes.

Bref, si vous aviez ReactOS dans un coin de votre tête comme curiosité, la 0.4.16 sera sans doute le bon moment pour le retester sur une vieille machine.

Source : Hackaday

Quand j'achète un truc avec ma CB, c'est vrai que j'évite maintenant de demander le ticket de carte bancaire. Ça ne me sert à rien, et puis j'en fais quoi après ? Je le jette à la poubelle ?

Heureusement qu'il n'y a pas de données confidentielles dessus et que tous les chiffres de ma CB sont masqués avec des petites étoiles sauf une partie, généralement les 4 derniers, qui sont en clair évidemment.

Bref, tout roule, nan ? Hé bien noooon, parce que Metin Ozyildirim, un chercheur en sécurité, vient d'expliquer sur son site comment ces étoiles en fait c'est pas vraiment un secret.

En fait, quand vous effectuez un achat en ligne, le marchand pose une question à votre banque pour valider la carte, du genre "hey Crédit Agricole, est-ce que ce numéro existe ?" et la banque répond connement oui ou non.

Et le souci c'est que cette question, n'importe qui peut la poser depuis n'importe où dans le monde, en testant des numéros au pif jusqu'à tomber sur le bon. C'est ce qu'on appelle du brute force, et avec une bonne machine et une connexion correcte, ça permet de tourner tranquillement à la fréquence de 6 tentatives par seconde, soit environ 130 000 essais possibles étalés sur une nuit. C'est donc très largement assez pour reconstituer les chiffres manquants quand on n'en a que 6 à deviner.

Et surtout, il arrive parfois que le marchand soit un peu trop bavard. Par exemple si vous tapez un mauvais numéro, il vous répond "Cette carte de crédit n'est pas valide". Si la date d'expiration est fausse, il vous dit gentiment "Cette carte a expiré". Et si le CVV est faux ? "Le code CVV n'est pas correct".

Comme le dit Metin dans son post, ce genre d'indice aide carrément à bruteforcer les infos de la CB. Bah oui, si le marchand vous confirme noir sur blanc que vous êtes à 3 chiffres près du jackpot, pourquoi s'arrêter hein ? C'est un peu comme dans ces films où y'a un gars qui braque un coffre-fort qui fait "clic" à chaque bon chiffre.

Et comme ça donc que Metin Ozyildirim s'est fait piller son compte bancaire il y a environ 1 an. L'attaquant a fait tourner son bruteforce comme ça durant 6 heures, en répartissant ses requêtes sur plusieurs sites e-commerce différents pour passer sous les radars.

Et une fois la carte complète reconstituée, restait plus qu'à dépenser le pognon ! Et là pareil, certains marchands acceptent encore les paiements sans demander la double authentification 3D Secure. Ces marchands là, ce sont eux qui payent en cas de fraude, car ils prennent le risque. L'attaquant a juste eu à choisir un de ces marchands "hack-friendly", et a transféré l'argent vers un porte-monnaie électronique, qu'il a ensuite converti en cash.

Et voilà comment le plafond de la carte de Metin était à zéro avant qu'il ait terminé son premier café du matin !

La bonne nouvelle, c'est que la banque l'a remboursé. Par exemple en France, vous avez 13 mois pour contester une transaction frauduleuse via votre banque. C'est un droit et pas une faveur hein ! Mais si la banque considère que vous avez été négligent (carte prêtée, code partagé, phishing évident...etc), elle peut tout à fait refuser le remboursement, donc gardez des preuves et contestez vite !

Maintenant, la mauvaise nouvelle, c'est que ce qui est arrivé à Metin est de plus en plus fréquent. Visa a même documenté que ce genre d'attaques explose, et que la majorité des sites e-commerce sont mal protégés contre ce genre de bots qui font tourner ces scripts de bruteforcing.

Bref, y'a pas grand chose à faire de notre côté pour nous protéger de ça, si ce n'est d'activer les notifs de notre banque sur chaque transaction, configurer le plafond le plus bas possible (sans que ce soit gênant), et quand votre banque vous propose une carte virtuelle à usage unique pour les achats en ligne, n'hésitez pas à l'utiliser.

Et la prochaine fois que vous laisserez traîner un reçu de CB sur la table d'un resto, dites-vous que vous offrez peut-être un accès à votre compte au prochain margoulin qui passe !

Source

Le NCSC, l'agence de cybersécurité du Royaume-Uni rattachée au GCHQ (l'équivalent britannique de la NSA américaine, qui s'occupe du renseignement électronique pour l'État), a sorti un boîtier qui s'intercale entre un ordinateur et son écran pour bloquer les attaques transitant par le câble HDMI ou DisplayPort.

Le produit s'appelle SilentGlass, il se branche sans configuration, et il a été présenté à la conférence CYBERUK. Première mondiale, dit-elle.

Première surprise pour qui n'y a jamais pensé : le câble qui relie votre PC à votre écran ne sert pas qu'à faire passer l'image. Il transporte aussi des données dans les deux sens (réglages de l'écran, infos sur la résolution, anti-copie sur les contenus protégés), et il émet des ondes électromagnétiques qui peuvent fuiter loin du bureau.

En 2024, des chercheurs de l'Université de la République à Montevideo ont montré qu'on pouvait reconstituer à distance le texte affiché sur un écran rien qu'en captant le rayonnement émis par le câble HDMI, avec un peu d'IA derrière. C'est le principe de l'attaque TEMPEST, théorisée dans les années 80 par les agences de renseignement, mais qui devient aujourd'hui accessible à des attaquants disposant de moyens beaucoup plus modestes.

SilentGlass se branche en série sur le câble, comme un petit module qu'on intercale. Il regarde le trafic qui circule par le canal annexe du HDMI ou du DisplayPort (celui qui sert à dialoguer entre PC et moniteur, en plus de l'image), et il bloque tout ce qui ne ressemble pas à une communication d'écran normale.

L'idée, c'est de couper la route à des programmes malveillants qui passeraient leurs ordres en se faisant passer pour des commandes anodines de réglage. La logique est celle d'un pare-feu, sauf que c'est posé entre l'unité centrale et l'écran, là où personne ne pensait à en mettre un.

La fabrication est confiée à Goldilock Labs, une entreprise britannique de cybersécurité, en partenariat avec Sony UK Technology Centre, l'usine galloise de Pencoed que Sony exploite depuis longtemps. C'est la première fois que le NCSC met son nom sur un produit grand public.

Le dispositif est déjà installé sur des sites du gouvernement britannique, et l'agence vise désormais les opérateurs d'infrastructures critiques (énergie, transports, banques), les ministères, les entreprises de défense, et plus largement toutes les organisations qui pensent être dans la cible d'États étrangers. Le prix exact n'a pas été annoncé, mais le NCSC parle d'un produit abordable pour son marché.

Le produit règle une faille qui n'est pas anodine. La sécurité du câble vidéo est traitée depuis trente ans comme un sujet de niche réservé aux militaires, mais avec la multiplication des écrans connectés, des bureaux partagés et des chaînes d'approvisionnement où chaque câble a pu passer par dix mains avant d'arriver chez vous, le périmètre s'est élargi.

Pour un développeur dans une startup avec un MacBook et un écran 27 pouces, l'intérêt est faible. Pour une salle de marché bancaire ou un centre de surveillance vidéo, c'est tout autre chose.

Vous l'avez compris, le NCSC sort ici un produit étatique pour un risque que la plupart ignorent. Une agence de renseignement qui vend du matériel commercial, c'est quand même nouveau, mais ça va dans le bon sens.

Source : Security Affairs

La première release candidate de Linux 7.1 est sortie, avec un tout nouveau pilote NTFS écrit pour le noyau, qui annonce des écritures multi-thread deux fois plus rapides et un montage de disque jusqu'à quatre fois plus véloce que l'ancien.

La sortie stable est prévue pour la mi-juin selon le calendrier de Linus Torvalds. Au total, la fenêtre de merge a vu passer plus de 13 000 commits, ce qui en fait une release plutôt costaude.

Le pilote NTFS dans Linux a une longue histoire compliquée. Pendant des années, le kernel a embarqué deux pilotes : ntfs en lecture seule maintenu par Anton Altaparmakov, et ntfs3 contribué par Paragon Software puis pratiquement abandonné depuis 2024.

La version qui débarque dans 7.1 est une réécriture complète, optimisée pour les usages dual-boot et les disques externes formatés en NTFS, qui restent monnaie courante quand on échange des fichiers avec Windows.

L'autre nouveauté, c'est l'activation par défaut de FRED, le mécanisme Flexible Return and Event Delivery développé par Intel pour remplacer le vieux système d'IDT et d'interruptions hérité du x86. Cette activation doit simplifier la gestion des exceptions et des appels système, avec moins de cycles perdus à chaque commutation de contexte. Sur les puces Intel récentes qui le supportent, c'est un petit gain de performance qu'on récupère sans rien faire.

Côté ménage, on vous en a déjà parlé , Linux 7.1 retire le support du i486, processeur sorti en 1989, et abandonne plusieurs vieux pilotes réseau et SoC qui n'avaient plus d'utilisateurs réels. Personne ne regrettera. Le kernel garde son équilibre entre support legacy et code moderne, en évacuant les morceaux qui coûtent en maintenance pour zéro retour visible.

Pour les utilisateurs de tous les jours, le gros impact ça sera cette affaire d'NTFS. Avoir un pilote rapide, fiable et maintenu directement dans le kernel mainline change la vie de tous ceux qui jonglent entre Linux et Windows sur la même machine. Plus besoin de dépendre de ntfs-3g en userspace ou de monter en lecture seule pour éviter les corruptions, ce qui était le quotidien de pas mal de gens depuis bien trop longtemps.

C'est aussi un bon indicateur pour l'écosystème : du code propre, écrit en interne, sans dépendre d'un éditeur tiers qui peut se désengager du jour au lendemain.

Linux 7.1 fait donc un gros ménage et règle un problème bien relou. Pour ceux qui galèrent avec leurs disques NTFS depuis bien longtemps, c'est une libération.

Source : Phoronix

SentinelOne a publié une analyse qui peut redessiner la chronologie connue de la cyberguerre. Baptisé FAST16, ce framework de sabotage informatique a été compilé en 2005, soit cinq ans avant la découverte de Stuxnet. Si les analyses tiennent la route, ça en fait la plus ancienne cyberarme étatique documentée à ce jour.

Le principe est fourbe. FAST16 ne détruit rien, ne chiffre rien, ne vole rien. Il corrompt des calculs. Le driver kernel (fast16.sys) s'installe silencieusement sur la machine cible, se place dans le flux d'entrée/sortie du système de fichiers, et modifie le code exécutable de certains logiciels de calcul haute précision pendant leur chargement en mémoire.

Le logiciel tourne normalement, affiche des résultats cohérents en apparence, mais ils sont légèrement faux. Pendant des mois, voire des années, les ingénieurs prennent des décisions sur des données faussées sans jamais rien voir. Plutôt vertigineux.

Les logiciels visés sont très spécifiques : LS-DYNA 970 pour la simulation de crash et les calculs structurels, PKPM pour le BTP (utilisé essentiellement en Chine), et MOHID pour la modélisation hydrodynamique. LS-DYNA, justement, a des usages documentés dans la recherche nucléaire iranienne. Ce qui ramène toujours au même dossier.

L'architecture est aussi très sophistiquée : un module porteur avec une machine virtuelle Lua 5.0 embarquée qui exécute du bytecode chiffré, le driver de sabotage, et un module de reporting qui passe par les callbacks Windows RAS.

Pour rappel, l'usage d'une VM Lua embarquée précède de trois ans les plus anciens échantillons de Flame (2012). Ces gens étaient très en avance.

Autre signal intéressant, le nom "fast16" apparait dans la fuite ShadowBrokers de 2017, plus précisément dans les composants "Territorial Dispute" attribués à la NSA, accompagné d'une mention cryptique qui disait en substance "rien à voir ici, circulez".

Visiblement, il y avait quelque chose à voir. Le code contient aussi des traces SCCS/RCS, des conventions de versioning Unix des années 70-80, ce qui pointe vers des développeurs issus d'environnements d'ingénierie ancienne école, probablement étatiques.

Bref, SentinelOne n'accuse personne, mais les indices pointent vers les États-Unis ou un allié. Ça repousse de cinq ans la frontière connue de la cyberguerre offensive.

Source : The Register

Si vous avez installé Bitwarden CLI via npm entre 17h57 et 19h30 PM (heure de New York) ce 22 avril, faut faire le ménage sur votre machine de toute urgence !! En effet, le package @bitwarden/cli version 2026.4.0 a été compromis durant 93 minutes, et le malware qui s'y trouvait a fait des dégâts chez les 334 personnes qui l'ont téléchargé pendant cette fenêtre.

Mais alors c'est quoi cette histoire encore ?

Hé bien des attaquants ont réussi à piéger le pipeline GitHub Actions de Bitwarden, à y injecter un fichier bw1.js dans le package npm officiel, et à le publier sans qu'aucune alerte ne parte. Jusqu'à ce que l'équipe sécurité de Bitwarden capte le truc et retire le package une heure et demie plus tard.

Et y'a un truc qui fait tiquer dans cette histoire, c'est que le malware s'annonce fièrement comme "Shai-Hulud: The Third Coming". En fait c'est la troisième vague d'une campagne npm qu'on avait déjà croisée en septembre 2025 . Et les attaquants restent cohérents dans leur branding puisque les dépôts publics qu'ils créent chez les victimes portent des noms issu de Dune comme atreides, fremen, sardaukar ou harkonnen. Donc sachez le, si vous voyez ça apparaître sur votre GitHub, vous êtes cuit !

Le payload, lui, est propre dans son approche crasseuse, selon l'analyse de Socket . Il chope tout ce qui traîne sur votre machine : tokens GitHub (ghp_*), tokens npm, credentials AWS dans ~/.aws, tokens Azure, SSH keys, fichiers .npmrc, configs Claude et MCP.

Puis il chiffre le tout en AES-256-GCM avec une clé RSA éphémère, balance le paquet vers audit.checkmarx[.]cx/v1/telemetry (un domaine qui imite Checkmarx pour brouiller les pistes), puis injecte une backdoor dans vos .bashrc et .zshrc. Ah et le malware vérifie également votre localisation système et se barre en silence sans faire de dégâts si elle commence par "ru". Ohhh comme c'est bizarre ^^.

Bref, si vous êtes concerné, voici la liste des trucs à faire dans l'ordre :

• npm uninstall -g @bitwarden/cli puis npm cache clean --force
• Rotation complète de vos secrets : tokens GitHub, tokens npm, credentials AWS/Azure/GCP, clés SSH
• Vérifiez vos repos GitHub pour des créations suspectes avec des noms Dune
• Cherchez "LongLiveTheResistanceAgainstMachines" dans vos commits (c'est leur marker d'exfiltration)
• Virez les modifications suspectes dans vos ~/.bashrc et ~/.zshrc
• Installez la version 2026.4.1 qui est propre

Faut bien le reconnaître, Bitwarden a été hyper réactif dans cette histoire. Détection en interne, mise en quarantaine en 93 minutes, communication claire, et CVE émis dans la foulée. Et heureusement, aucune donnée utilisateur n'a fuité vu que les vaults restent chiffrés côté client de toute façon, et que seuls les développeurs qui ont installé le CLI pendant ce créneau sont touchés. Les extensions navigateur, l'app desktop, mobile, le package snap, rien de tout ça n'a bougé.

Mais ça reste quand même la preuve que npm est devenu LE cauchemar de la supply chain moderne. Après Axios le mois dernier et la campagne Shai-Hulud de septembre, on en est au point où chaque package JS avec un script d'install équivaut à une bonne vieille roulette russe. Donc si vous bossez dans un environnement CI/CD, soyez vigilant et jetez aussi un oeil à safe-npm pour mettre un peu de paranoïa automatisée dans votre workflow quotidien.

Voilà, si vous avez installé Bitwarden CLI avant-hier soir via npm, vous avez du boulot. Sinon, respirez car Bitwarden a tenu bon !

Source

Un logiciel malveillant destiné à effacer définitivement les données de postes informatiques vient de faire surface dans le secteur énergétique vénézuélien.

La bête a été baptisée "Lotus" par les chercheurs de Kaspersky qui l'ont analysé en premier, il a été mise en route en décembre 2025 depuis un ordinateur vénézuélien, et sa cible principale semble être PDVSA, la compagnie pétrolière d'État.

Côté technique, Lotus ne fait pas dans la dentelle. Deux scripts batch préparatoires, OhSyncNow.bat et notesreg.bat, désactivent toutes les défenses, coupent les comptes utilisateurs et ferment les interfaces réseau, histoire de bien tout bloquer.

Ensuite, le binaire principal passe en mode destruction avec diskpart, robocopy et fsutil pour manipuler le système de fichiers, puis descend au niveau IOCTL pour écraser directement des secteurs physiques du disque. Les points de restauration sont supprimés, le journal USN est effacé. Aucune récupération possible.

LKaspersky ne pointe personne, et aucun élément technique ne désigne un État ou un groupe criminel en particulier. Le timing est quand même troublant : fin 2025 et début 2026, le Venezuela a traversé une crise politique majeure avec la capture de l'ancien président Nicolás Maduro le 3 janvier, et les tensions toujours fortes autour des infrastructures énergétiques. Coïncidence ou coordination, on ne saura probablement pas avant longtemps.

En pratique, un wiper qui cible PDVSA, ça rappelle immédiatement les attaques contre les infrastructures critiques qu'on a vues en Ukraine avec Stryker ou contre des clusters Kubernetes avec la variante TeamPCP.

L'objectif n'est pas le chantage ni le vol, c'est la destruction pure. Les opérateurs ne cherchent pas à exfiltrer quelque chose, ils veulent rendre l'infrastructure inutilisable le plus vite possible, pour déstabiliser ou punir.

Un réseau d'alimentation électrique ou de distribution de carburant paralysé quelques jours, ça a des conséquences directes sur la vie quotidienne et sur la stabilité politique d'un régime.

Ce qui inquiète, c'est aussi la qualité du code. Lotus n'est pas un script amateur collé à la va-vite : il enchaîne plusieurs étapes de sabotage méthodique, de la désactivation des défenses à la destruction bas niveau du disque.

Pour un pays qui n'a déjà pas la réputation d'avoir la cybersécurité la plus pointue du continent, encaisser ce genre d'outil, ça fait mal. Et la probabilité que d'autres échantillons du même auteur circulent déjà ailleurs est loin d'être nulle.

Bref, un wiper bien fichu sur une compagnie pétrolière d'État dans un pays en crise, c'est rarement l'œuvre d'un adolescent dans son garage. Affaire à suivre donc.

Source : Bleeping Computer

Depuis la version 2.91.0 du CLI GitHub publiée mardi, chaque commande que vous tapez dans gh envoie des données de télémétrie vers GitHub par défaut. L'activation est silencieuse, sans message au premier lancement, sans consentement explicite, et il faut fouiller dans la doc pour tomber sur la page dédiée au sujet.

GitHub décrit la collecte comme pseudonyme côté client. Concrètement, le payload embarque le nom de la commande lancée, un identifiant d'invocation, un identifiant d'appareil, l'OS, l'architecture, l'agent et quelques drapeaux.

L'entreprise précise que le contenu exact peut varier d'un appel à l'autre. La justification officielle : les équipes produit ont besoin de voir comment le CLI est utilisé, avec la montée en puissance des agents IA qui le pilotent de plus en plus souvent en arrière-plan.

Côté sortie, il y a trois moyens de couper la télémétrie. Vous pouvez définir la variable d'environnement GH_TELEMETRY à false, ou DO_NOT_TRACK à true, ou lancer gh config set telemetry disabled. Simple en apparence.

Sauf que rien de tout ça n'est signalé à l'installation, et qu'un utilisateur qui n'est pas tombé sur le billet de Brandon Vigliarolo dans The Register ne saura probablement pas que c'est activé sur sa machine.

Le terme pseudonyme mérite aussi qu'on le regarde de près. Pseudonyme ne veut pas dire anonyme : il y a un identifiant d'appareil stable, il y a un identifiant d'invocation, et GitHub connaît déjà votre compte si vous êtes authentifié avec gh auth login.

Du coup, le recoupement entre votre activité CLI et votre identité GitHub n'a rien de théorique, même si GitHub ne promet pas de le faire.

En pratique, la télémétrie des outils de dev n'est pas une nouveauté. VS Code le fait depuis des années, npm aussi, et la plupart des éditeurs jouent le même jeu. Ce qui coince ici, c'est le choix de l'opt-out plutôt que de l'opt-in, et l'absence d'annonce claire sur le changelog principal.

Les utilisateurs reprochent surtout à GitHub d'avoir glissé l'info dans une page de doc au lieu d'un billet de blog dédié. Pour un outil qu'utilisent des gens très à cheval sur leur vie privée, c'est un drôle de calcul.

Bref, un outil CLI qui s'active en mode collecte par défaut sans prévenir, ça pique. Heureusement une variable d'environnement suffit à couper. Mais il faut savoir qu'elle existe.

Source : The Register

Une IA a rooté une télé Samsung tournant sous KantS2, la plateforme logicielle d'un ancien modèle de la marque. C'est Codex, le modèle de code d'OpenAI, qui a trouvé un driver laissé avec des droits d'écriture sur le firmware, mappé la mémoire physique, et est passé root en quelques étapes. Les chercheurs de califio lui ont juste fourni un accès shell et le code source du firmware. À partir de là, c'est Codex qui a enchaîné la chaîne d'exploitation tout seul.

Et ce qui est marquant dans cette histoire, je trouve, c'est pas tellement la faille mais le fait qu'un driver laissé en accès libre sur un firmware embarqué des années 2018-2020, ça se trouve à la pelle. Heureusement, Samsung a patché cette TV-là.

Ce qui est super fort, c'est que Codex a fait de l'énumération de surface d'attaque, a lu le code source, a testé ses hypothèses sur l'appareil en live, a pondu un PoC en 2 secondes, puis l'a exploité. 5 petites étapes que des chercheurs humains mettent typiquement des semaines à enchaîner.

Et Codex n'est pas un cas isolé puisque Anthropic a annoncé que son modèle Claude Mythos a trouvé des milliers de vulnérabilités sur Windows, macOS, Linux et les gros navigateurs, dont une partie en critique. De son côté, AISLE a sorti les douze vulnérabilités critiques patchées dans OpenSSL fin janvier de cette année, trouvées également par son système IA. Trend Micro de son côté fait tourner ÆSIR et revendique 21 CVEs sur NVIDIA, Tencent et MLflow depuis mi-2025. Bref, on a basculé dans autre chose niveau cybersec.

Du coup, la question qui me gratte, c'est pas "est-ce que l'IA peut trouver des failles". Pour ça, on connait la réponse. Non, c'est plutôt : Mais qui va tenir le putain de rythme côté défense ?. Parce que les fabricants, eux, patchent toujours à la vitesse d'un humain qui lit un rapport, teste, valide, et pousse quand ils ne sont pas en congés, alors que pendant ce temps, un système IA bien configuré peut passer au scanner le firmware d'un objet connecté en boucle, sans se fatiguer et sans pause café jusqu'à ce qu'il le déboite.

Côté utilisateur, honnêtement, y'a pas grand-chose à faire. La faille Samsung est corrigée par une mise à jour, encore faut-il avoir branché la TV au réseau et accepté les updates. Et pour une TV achetée il y a cinq ans et qu'on rallume uniquement pour Netflix le soir, c'est loin d'être garanti. Le bon réflexe, c'est donc de vérifier les mises à jour sur tout ce qui a un firmware et qui traîne en bout de course. Routeurs, caméras IP, domotique, et tous ces vieux trucs qu'on a oublié de patcher depuis trois ans.

En tout cas, je vous le dis direct, le sujet va revenir encore et encore, vous allez voir... Parce que si une IA de ce niveau peut trouver une escalade root sur une TV avec juste un shell et du code source, elle peut s'attaquer à pas mal d'autres appareils connectés qui partagent les mêmes mauvaises habitudes de permissions. Le hack de TV , en 2012, c'était un passe-temps de chercheur alors qu'en 2026, c'est devenu industrialisable.

Les IA accélèrent vraiment la découverte de 0-days, et l'écart avec les équipes humaines se creuse fortement. Donc si vous avez du matos connecté chez vous, un petit audit ce weekend, ça ne mangera pas de pain.

Source : Califio

Des utilisateurs de Claude Desktop sont en train de découvrir que l'application d'Anthropic se permet d'aller bidouiller les réglages de plusieurs navigateurs, y compris ceux qui ne sont pas installés sur la machine.

L'idée est simple, c'est pré-configurer l'accès pour que, le jour où vous installeriez Chrome, Firefox ou Edge, Claude puisse directement automatiser votre navigation sans avoir à redemander la permission.

Sur le papier, ça part d'une intention louable. Éviter de vous ennuyer avec un prompt de permission à chaque installation, pourquoi pas. Sauf que voilà, personne n'a demandé à ce que Claude Desktop touche aux navigateurs absents, et encore moins à ceux que l'utilisateur a délibérément choisi de ne pas avoir.

On a par exemple un chercheur en sécurité qui n'avait jamais installé la moindre extension Anthropic, qui s'est retrouvé avec toutes ces préconfigurations silencieuses, selon The Register.

Le problème devient plus sérieux quand on regarde comment ça marche. 

L'application pont qui fait le lien entre Claude et les navigateurs tourne hors du sandbox navigateur, avec les privilèges complets de l'utilisateur. Ce qui veut dire qu'elle peut lire vos pages, remplir vos formulaires, capturer l'écran sur des sessions authentifiées, bref agir comme vous, sans aucune boîte de dialogue qui vienne prévenir ou demander confirmation.

Côté Anthropic, silence radio. On imagine bien que l'argument défensif sera qu'il s'agit juste de préparer le terrain pour Computer Use, la fonctionnalité qui permet à Claude d'utiliser votre PC comme un humain.

Sauf qu'installer des hooks dans des navigateurs absents ressemble quand même plutôt du squatting de permissions qu'à une préparation technique légitime.

Ce qui est rageant dans cette histoire, c'est qu'Anthropic se positionne depuis des mois comme l'acteur "sérieux" de l'IA, celui qui fait des papiers d'alignement et parle éthique à longueur de blog posts. Voir leur app desktop se comporter comme un logiciel de 2005 qui colle Ask Toolbar sans prévenir, c'est un camouflet côté image.

Pour les entreprises qui regardent si elles peuvent déployer Claude Desktop en flotte, ce genre de comportement va clairement peser dans la balance sécurité, et pas dans le bon sens.

Bref, on est là sur une histoire de permissions qui n'aurait jamais dû exister sur un produit d'une boîte qui se présente comme le pro de la sécurité IA.

Source : The Register

Vercel, c'est la plateforme d'hébergement web utilisée par des milliers de développeurs et d'entreprises pour déployer leurs sites et applications (c'est eux qui font Next.js, entre autres).

Un de leurs employés s'est inscrit sur Context.ai, un assistant IA pour la bureautique, en utilisant son compte professionnel Google. Au moment de l'installation, l'app a demandé l'accès à ses emails, ses fichiers, son agenda, bref tout le Google Workspace de la boîte. Il a cliqué "autoriser tout". Erreur classique.

Sauf que Context.ai s'est fait pirater en février. Un de leurs propres employés a chopé un malware (Lumma, un voleur de mots de passe) en téléchargeant des scripts de triche pour Roblox. Le genre de bêtise qui ouvre la porte à tout le reste.

L'attaquant a récupéré l'accès que Context.ai avait sur le Google Workspace de Vercel, avec des permissions très larges : emails, fichiers internes, infrastructure de déploiement.

ShinyHunters, un groupe de pirates connu, a revendiqué le coup sur un forum et mis en vente des clés d'accès, du code source, des données de bases et des clés API de Vercel.

Le PDG de Vercel estime que le nombre de clients touchés est "assez limité", sans donner de chiffres. Mais côté crypto, plusieurs projets hébergés sur la plateforme ont quand même lancé en urgence un changement de tous leurs mots de passe et clés d'accès, ce qui donne une idée de l'ambiance.

Ce qui rend cette affaire intéressante, c'est le mécanisme. Personne chez Vercel n'a été directement attaqué. C'est un outil tiers, un outil IA installé par un employé, qui a servi de pont. L'employé donne un accès large à un service externe, le service se fait pirater trois mois plus tard, et tout le contenu professionnel de l'entreprise se retrouve exposé.

C'est exactement le scénario que les experts en sécurité décrivent depuis un an quand ils parlent des outils IA qui demandent des permissions tentaculaires sur vos comptes pro.

Bref, le vrai problème n'est pas Vercel. C'est le "autoriser tout" sur un outil IA qu'un employé a installé sans se poser de questions.

Source : SecurityWeek