Bon, alors là, Google a fait encore trèèèès fort.

Mercredi matin, la firme de Mountain View a carrément publié sur son propre bug tracker Chromium le code d'exploitation d'une faille... qui n'est toujours pas corrigée ! Et pas une petite vulnérabilité oubliée dans un coin, hein, mais une vraie faille de la mort qui tue que la chercheuse indépendante Lyra Rebane leur avait remontée gentiment et en privé . Ça fait 29 mois (2 ans et demi, les matheux ^^) et elle attend toujours un patch !

Le truc vise la Browser Fetch API, un mécanisme qui permet à un site de télécharger de gros fichiers en arrière-plan, genre une longue vidéo. Sauf qu'en la détournant, le code ouvre un service worker qui reste actif en permanence. Du coup, un site malveillant que vous visitez peut glisser un bout de JavaScript qui transforme votre navigateur en relais, tout cela à votre insu.

Parfait donc pour devenir un proxy anonyme pour des inconnus, un nœud de botnet pour des attaques DDoS, ou se faire surveiller quand on surfe sur le net... Et le plus vicelard, c'est que la connexion se rouvre ou reste ouverte même après avoir redémarré le navigateur, voire la machine entière.

Côté victimes, on parle de Chrome, de Microsoft Edge et de quasiment tous les navigateurs basés sur Chromium. Et que vous soyez sur Windows, macOS ou Linux, le bug s'en moque royalement. Rebane a confirmé que Brave, Opera, Vivaldi et Arc sont vulnérables eux aussi.

Bien sûr, Firefox et Safari, eux, passent clairement au travers, parce qu'ils ne supportent pas ce fameux téléchargement en arrière-plan. Bref, encore une fois, ne pas suivre le troupeau de mouton team-Chromium, ça paye !! Si vous cherchiez une raison de plus de larguer Google , la voilà servie sur un plateau.

Perso, ce qui me sidère, c'est que la faille a été classée S1, le deuxième niveau de gravité le plus élevé chez Google et il ne s'est toujours rien passé 29 mois après. C'est ouf quand même... Le post sur le tracker Chromium a bien été supprimé mais on le trouve toujours sur quelques archives / miroirs...

Après l'impact de cette faille, reste quand même limité car elle ne franchit aucune frontière... par exemple, elle ne donne pas accès à vos mails ni au reste de votre ordinateur, mais juste à ce qu'un navigateur sait déjà faire (ce qui est déjà énorme !!). Mais elle pourrait permettre à des cybercriminels de se constituer une flotte de milliers, voire de millions de navigateurs détournés, et le jour où une autre faille tombe, vous avez déjà l'armée prête à dégainer !! La bombe est là, il manque juste la mèche en fait !

Et pour se protéger ?

Bah franchement, pas grand-chose à faire côté utilisateur tant qu'il n'y a pas de patch. Si vous voulez mon avis bancal, le seul signal visible que vous pouvez guetter, c'est un menu de téléchargement qui s'ouvre tout seul sans raison, donc méfiez-vous donc si ça arrive. Maintenant si le sujet vous angoisse vraiment, basculer sur un navigateur pour les adultes ^^, genre Firefox ou Safari règlera la question d'un coup !

Faut pas oublier que Google passe son temps à pointer du doigt les éditeurs trop lents à patcher, alors j'comprends vraiment pas comment ils ont pu merder à ce point.

Source

Bon, accrochez vous les amis, car ça enchaine sec sur le kernel Linux en ce moment... Le chercheur William Bowling de l'équipe V12 security vient de lâcher Fragnesia (CVE-2026-46300, CVSS 7.8), un nouvel exploit kernel Linux qui permet d'obtenir un accès root sur toutes les distros majeures, et ce, 8 jours seulement après le patch de Dirty Frag.

Et la mauvaise nouvelle, en fait, c'est que Fragnesia tape dans la même surface d'attaque que Dirty Frag , mais via un bug logique différent qui n'est pas fixé par le patch initial. Donc si vous aviez sagement mis à jour votre noyau le 8 mai dernier en pensant être tranquille, hé bah désolé, vous êtes toujours à poil !

La lignée "Dirty" continue donc tout simplement de s'allonger... Dirty COW en 2016, Dirty Pipe en 2022, Copy Fail le 1er mai 2026, Dirty Frag le 8 mai, et maintenant Fragnesia le 14 mai. Quatre LPE (local privilege escalation) kernel Linux en deux semaines, c'est un record je crois !

Alors comment ça marche ?

Le bug se planque dans la partie du kernel qui gère le chiffrement réseau IPsec. C'est le truc qu'on utilise pour faire du VPN d'entreprise et l'attaque détourne le moteur de chiffrement pour qu'il écrive là où il ne devrait surtout pas écrire.

Le déroulé ensuite est assez simple à comprendre. Il prend un fichier sensible déjà ouvert en lecture (genre /usr/bin/su, le programme qui fait passer en root), il le balance dans une connexion réseau, et il dit au kernel "tiens, chiffre-moi tout ça en IPsec". Le kernel obéit gentiment, sauf qu'au lieu d'envoyer le résultat chiffré sur le réseau, il vient écraser la version du fichier qui est en mémoire avec les octets chiffrés. Du coup /usr/bin/su contient maintenant du code choisi par l'attaquant. Suffit ensuite de taper su pour devenir root.

Et là c'est le drame !

Le pire, c'est qu'il n'y a aucun "tirage au sort" dans tout ça. Pas besoin de gagner une condition de course une fois sur mille comme à l'époque de Dirty COW. Là, c'est 100% reproductible à chaque exécution, ça marche du premier coup.

La cause profonde, c'est une fonction kernel qui assemble des morceaux de paquets réseau et qui oublie au passage que certains morceaux pointent vers de la mémoire qui ne lui appartient pas vraiment (genre la mémoire d'un fichier qu'un autre process est en train de lire). Bowling appelle ça la "famille Dirty Frag" parce que c'est exactement le même genre d'amnésie qui avait permis Dirty Frag la semaine dernière.

Et le patch du 8 mai n'a pas suffi parce qu'il a juste rebouché un trou particulier, sans toucher à la fonction d'origine. D'où la sortie immédiate du PoC le 14 mai, parce qu'autant prévenir tout le monde, plutôt que de laisser un 0-day silencieux circuler dans les milieux moins recommandables d'Internet.

Testez sur votre Linux

Si vous voulez reproduire ça dans un environnement isolé (genre une VM Ubuntu 24.04 avec un kernel 6.8.0-111-generic), c'est simple :

git clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c && ./exp

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

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

echo 3 > /proc/sys/vm/drop_caches

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

Vous pensiez que BitLocker était votre ami ? Celui qui protège gentiment vos données avec son chiffrement intégral du disque ?

Eh bien, Fabian Mosch vient de prouver lors de la conférence Troopers 2025 qu’on pouvait le transformer en complice involontaire pour des attaques plutôt vicieuses. Le principe, c’est qu’au lieu d’attaquer BitLocker frontalement (ce qui serait suicidaire vu la robustesse du chiffrement), la technique consiste à détourner ses mécanismes internes pour exécuter du code malveillant.

Comment ?

Et bien en exploitant le fait que BitLocker cherche à charger des objets COM qui n’existent pas. C’est le fameux CLSID A7A63E5C-3877-4840-8727-C1EA9D7A4D50 que le processus BaaUpdate.exe essaie désespérément de trouver à chaque fois qu’il se lance.

L’astuce ici, c’est donc d’utiliser WMI (Windows Management Instrumentation) pour créer à distance cette clé de registre manquante et y glisser le chemin vers une DLL malveillante.

Comme ça, quand BitLocker démarre, il charge gentiment votre code en pensant que c’est un composant légitime. Et le plus magique c’est que tout s’exécute sous l’identité de l’utilisateur connecté.

Alors si c’est un admin du domaine, je vous raconte pas le jackpot ! Pour prouver que ce n’est pas que de la théorie, l’équipe de r-tec Cyber Security a développé BitLockMove, un outil qui automatise toute l’attaque.

Le mode énumération permet d’abord de scanner les sessions actives sur une machine distante grâce aux API non documentées de winsta.dll et une fois qu’on a repéré un utilisateur intéressant (genre DOMAINE\Administrateur), on passe en mode attaque.

La séquence d’attaque est assez cool d’ailleurs :

1. Activation du service Remote Registry via WMI
2. Création de la clé de registre piégée
3. Déclenchement du processus BitLocker via l’interface BDEUILauncher
4. Exécution du code malveillant dans le contexte de l’utilisateur ciblé
5. Nettoyage des traces (suppression de la clé et de la DLL) Au fait, .

Ce qui rend cette technique particulièrement sournoise, c’est qu’elle abuse de processus Microsoft signés et légitimes. Par exemple, il y a BdeUISrv.exe, le processus qui finit par exécuter votre code, qui est un binaire officiel de Windows. Pour un EDR lambda, ça ressemble donc à du comportement normal de BitLocker.

Toutefois, ce n’est pas non plus la panacée pour les attaquants car il faut déjà avoir des privilèges d’administrateur local sur la machine cible. Ensuite, toute cette gymnastique laisse des traces exploitables. Le service Remote Registry qui passe de “désactivé” à “actif” puis retourne à “désactivé” en quelques secondes, c’est louche.

Les événements Windows 4657, 4660 et 4663 sur les clés de registre BitLocker, c’est donc un red flag énorme, sans parler des processus baaupdate.exe et BdeUISrv.exe qui apparaissent dans des contextes inhabituels.

Pour les défenseurs qui veulent mater leurs logs, voici les points de surveillance critiques :

• Event ID 7040 pour les changements d’état du service Remote Registry
• Surveillance des créations/suppressions sous HKEYCURRENTUSER\SOFTWARE\Classes\CLSID{A7A63E5C-3877-4840-8727-C1EA9D7A4D50}
• Processus BdeUISrv.exe lancé par svchost.exe (au lieu du comportement normal)
• Chargement des DLL winsta.dll ou wtsapi32.dll par des processus non standards

L’article original propose même des règles SIGMA toutes prêtes et des requêtes KQL pour Microsoft Defender for Endpoint. C’est du clé en main pour les équipes SOC qui veulent détecter cette technique.

Comme d’hab, la sécurité Windows reste un casse-tête car chaque fonctionnalité légitime introduit de nouvelles surfaces d’attaque. BitLocker protège vos données au repos, mais ses mécanismes internes deviennent des vecteurs d’attaque pour du “mouvement latéral” (c’est comme ça qu’on dit).

Pour ceux qui veulent creuser le sujet, le code de BitLockMove est disponible sur GitHub. Mais comme toujours avec ce genre d’outils, utilisez-le uniquement dans un cadre légal (tests d’intrusion autorisés, labos de recherche, etc.) sinon, vous allez finir en prison !!

Maintenant, reste à voir combien de temps il faudra à Microsoft pour patcher ce comportement… s’ils considèrent ça comme un bug, hein, et pas juste comme une “fonctionnalité” du système COM. On verra bien…

Source

On est là en train de chiller dans une bonne journée bien normale quand SOUDAIN alerte rouge internationale, on apprend qu’il y a une faille critique CVSS 10 dans Apache Parquet, et que tout le monde panique bien évidemment !!

Vous, admin système ou développeur, vous vous précipitez sur votre téléphone qui n’arrête pas de sonner pendant que les experts du CERT vous bombardent de mails d’alerte… et au milieu de ce chaos, vous vous grattez la tête (ou autre chose) en vous demandant : “Mais est-ce que je suis vraiment concerné, ou c’est encore une tempête dans un verre d’eau ?”

Les ransomwares, ces programmes nuisibles qui prennent vos précieux fichiers en otage contre une rançon, font trembler pas mal de monde, même les plus expérimentés. Mais c’était sans compter sur RansomLord qui pourrait peut-être bien vous sauver la mise si vous avez été infecté.

Cet outil open source, conçu par John Page (alias hyp3rlinx), a pour mission de mettre des bâtons dans les roues des cybercriminels en exploitant les failles de sécurité présentes dans le code de ces virus modernes. Et on parle quand même de ransomwares assez balaises comme Conti, REvil ou LockBit, mais aussi de nouveaux venus comme StopCrypt, RisePro, RuRansom, MoneyMessage, CryptoFortress et Onyx.

Pour réussir cet exploit (sans mauvais jeu de mot), RansomLord génère des fichiers « DLL » qui se font passer pour des fichiers légitimes dont les rançongiciels ont besoin. En réalité, ces DLL sont remplis de code malicieux qui court-circuite le processus de chiffrement et met fin à la carrière du malware avant même qu’il n’ait pu crier « Bitcoin » !

Le plus impressionnant, c’est que RansomLord est capable de cibler spécifiquement les rançongiciels qui menacent votre entreprise ou votre secteur d’activité grâce à sa base de données de plus de 49 familles de ransomwares. Comme ça, il vous concocte le DLL parfait pour mettre hors d’état de nuire ces logiciels du démon.

Cette dernière version 3 de RansomLord intègre également une fonction de journalisation qui enregistre le hash SHA256 et le chemin d’accès complet du malware intercepté. Comme ça, vous pouvez garder une trace de l’attaque et communiquer ces détails à des experts cyber qui viendraient mener l’enquête ensuite.

Respect à hyp3rlinx pour cette trouvaille ingénieuse ! Et pour télécharger RansomLord v3 c’est par ici.

Source

Vous pensiez que votre Bluetooth était safe ? Détrompez-vous ! Un chercheur en sécurité vient de dénicher une faille bien vicieuse qui permet d’exécuter du code à distance sur tout un tas d’appareils : smartphones Android, Chromecast, casques VR, TV connectées…

Le principe est diabolique : il suffit de se faire passer pour un clavier Bluetooth et hop, on peut envoyer des frappes de touches à la victime sans même qu’elle ait besoin d’accepter l’appairage. Pas besoin d’être à portée de main, quelques mètres suffisent. C’est ballot hein ?

Mais attendez, ça devient encore plus fort (ou pire, c’est selon). Des petits malins ont créé un outil baptisé BlueDucky qui automatise complètement l’exploitation de cette faille. Ça scanne les appareils vulnérables à proximité, ça les enregistre dans un fichier et ça balance un script Ducky bien sournois pour prendre le contrôle à distance. Le tout depuis un Raspberry Pi ou un smartphone Android !

Autant vous dire qu’ils se sont éclatés à tester ça sur tout ce qui passait : des smartphones, des objets connectés, des ordinateurs… Si c’est pas patché et que ça a du Bluetooth, ça tombe comme des mouches. Ils ont même réussi à ouvrir un navigateur et à envoyer la victime sur une page bien flippante, juste pour le fun.

Bon, vous allez me dire : « OK, mais comment on se protège de ce truc ?« . Eh bien c’est là que ça se gâte. Si vous avez un appareil récent, foncez installer les dernières mises à jour de sécurité. Mais pour les vieux machins sous Android 10 ou moins, c’est cuit, ça ne sera jamais patché. La seule solution : désactiver carrément le Bluetooth. Sinon, vous pouvez dire adieu à votre intimité numérique !

Mais ne cédons pas à la panique pour autant. Les chercheurs en sécurité font un boulot remarquable pour dénicher ces failles et alerter les fabricants. Maintenant, c’est à ces derniers de réagir en proposant des correctifs. Et à nous d’être vigilants en mettant à jour régulièrement nos appareils.

En attendant, si vous voulez jouer avec le feu dans la limite de ce que la loi permet, évidemment, le code de BlueDucky est disponible sur GitHub. Mais attention, c’est à vos risques et périls ! Ne venez pas vous plaindre si votre grille-pain se met à afficher des messages d’insulte au petit-déjeuner.

Pour l’installer :

# update apt
sudo apt-get update
sudo apt-get -y upgrade

# install dependencies from apt
sudo apt install -y bluez-tools bluez-hcidump libbluetooth-dev \
                    git gcc python3-pip python3-setuptools \
                    python3-pydbus

# install pybluez from source
git clone https://github.com/pybluez/pybluez.git
cd pybluez
sudo python3 setup.py install

# build bdaddr from the bluez source
cd ~/
git clone --depth=1 https://github.com/bluez/bluez.git
gcc -o bdaddr ~/bluez/tools/bdaddr.c ~/bluez/src/oui.c -I ~/bluez -lbluetooth
sudo cp bdaddr /usr/local/bin/

Et pour le lancer :

git clone https://github.com/pentestfunctions/BlueDucky.git
cd BlueDucky
sudo hciconfig hci0 up
python3 BlueDucky.py

Comme dirait l’autre, « le Bluetooth c’est comme le nucléaire, c’est génial tant que ça reste dans les mains des gentils« . Alors, soyez sympa et patchez-moi tout ça fissa ! Et si vous avez un appareil trop ancien qui traîne, coupez le Bluetooth et on n’en parle plus.

Pour en savoir plus sur cette faille et son exploitation, je vous invite à lire l’article ici.

Je sais pas si vous avez vu passer ça, mais dernièrement, il y a eu un peu de grabuge entre George Hotz (Geohot) et AMD, puisque ce dernier a essayé de faire tourner son framework IA Tiny Grad sur des GPU AMD.

Sauf que voilà, AMD lui a donné du fil à retordre avec ses firmwares propriétaires. Le driver open-source d’AMD se révélant être une jolie mascarade puisque tout les morceaux de code critiques sont bien protégés et sous licence.

Pourtant, Geohot n’a pas lésiné. Des mois à éplucher le code, à bypasser la stack logicielle, à discuter avec les pontes d’AMD. Mais rien à faire, les mecs veulent pas cracher leurs précieux blobs binaires. « Trop risqué, pas assez de ROI, faut voir avec les avocats. » Bref, c’est mort.

Pendant ce temps, Nvidia se frotte les mains avec son écosystème IA bien huilé. Des pilotes certifiés, des perfs au rendez-vous, une bonne communauté de devs… Tout roule pour eux, alors qu’AMD continue de s’enfoncer dans sa logique propriétaire, au détriment de ses utilisateurs.

La goutte d’eau pour Geohot ? Un « conseil » de trop de la part d’AMD qui l’a incité à « lâcher l’affaire« . Résultat, geohot est passé en mode « je vais vous montrer qui c’est le patron« . Si AMD ne veut pas jouer le jeu de l’open-source, alors il va leur exposer leurs bugs de sécu à la face du monde !

Et c’est ce qu’il a fait puisque durant un live de plus de 8h, il s’est attaché à trouver plusieurs exploit dans le firmware des GPU AMD. Il est fort !

Dans l’IA, l’aspect hardware compte évidemment mais le software c’est le nerf de la guerre. Les boîtes noires, les firmwares buggés, le code legacy, c’est plus possible et les sociétés qui tournent le dos à la communauté des développeurs et des hackers font, selon moi, le mauvais choix.

Et ce qui arrive à AMD n’est qu’un exemple de plus.

Bref, comme d’habitude, gros respect à Geohot pour son combat de vouloir encore et toujours que la technologie profite au plus grand nombre. En attendant, suite à sa mésaventure avec AMD, il a annoncé qu’il switchait tout son labo sur du matos Nvidia et qu’il bazardait ses 72 Radeon 7900 XTX sur eBay. Si vous voulez des GPU d’occase pour pas cher (et apprendre à les faire planter ^^), c’est le moment !

Et si le code source de ses exploits vous intéresse, tout est sur Github.

Merci George !