Vue lecture
Faille UEFI critique - Votre carte mère ASUS, Gigabyte, MSI ou ASRock est peut-être vulnérable
Vous pensiez que votre PC était blindé avec toutes vos protections activées ? Et bien ça c'était avant que des chercheurs de Riot Games (oui, les mêmes mecs derrière League of Legends et Valorant) ne découvrent une bonne grosse faille UEFI qui touche les cartes mères des quatre plus gros fabricants du marché, à savoir ASUS, Gigabyte, MSI et ASRock.
La faille se décline en plusieurs CVE selon les constructeurs (CVE-2025-11901 pour ASUS, CVE-2025-14302 pour Gigabyte, CVE-2025-14303 pour MSI, CVE-2025-14304 pour ASRock) et concerne les protections DMA au démarrage. En gros, le firmware UEFI prétend activer l' IOMMU (un mécanisme matériel d'isolation mémoire destiné à bloquer les attaques DMA), sauf que dans les faits, il ne le configure pas correctement. Votre système pense être protégé alors qu'il ne l'est pas du tout... Bref ça craint !
Du coup, un attaquant qui branche un périphérique PCIe malveillant sur votre machine (notamment via Thunderbolt ou USB4, qui exposent du PCIe) peut lire ou modifier la mémoire système avant même que Windows ou Linux ne démarre. Donc bien avant que vos protections système n'aient eu le temps de se mettre en place quoi... Et comme l'attaque se déroule avant le chargement de l'OS, les antivirus et outils de sécurité logiciels classiques n'ont pas encore démarré et ne peuvent donc pas intervenir. Seule une mise à jour du firmware UEFI peut corriger le problème.
Côté chipsets touchés, accrochez-vous parce que la liste est longue. Chez Gigabyte, les bulletins de sécurité mentionnent notamment des cartes basées sur les séries Intel Z890, W880, Q870, B860, H810, Z790, B760, Z690, Q670, B660, H610, W790, et côté AMD des X870E, X870, B850, B840, X670, B650, A620, A620A et TRX50.
Chez ASUS, les chipsets concernés incluent les séries B460, B560, B660, B760, H410, H510, H610, H470, Z590, Z690, Z790, W480 et W680.
Et de son côté, ASRock indique que ses cartes mères Intel des séries 500, 600, 700 et 800 sont également affectées. Bref, si vous avez une carte mère relativement récente, il y a de bonnes chances qu'elle soit dans le lot, même si cela dépend du modèle précis et de la version de firmware installée.
Bien sûr, comme souvent avec ce type de faille, son exploitation nécessite un accès physique à la machine, puisqu'il faut connecter un périphérique PCIe capable de mener une attaque DMA (par exemple un dongle Thunderbolt ou une carte PCIe spécialement conçue).
Ce n'est donc pas le genre d'attaque qui se propage via Internet, mais c'est quand même problématique, notamment dans les entreprises qui ont des postes de travail accessibles au public, dans les bibliothèques, ou tout autre environnement partagé. Sans parler de quelqu'un qui aurait un accès temporaire à votre machine genre un réparateur, un collègue malveillant, votre ex un peu trop curieux(se)… Ou encore le marché de l'occasion, où personne ne sait vraiment ce qui a pu être branché sur la carte mère avant.
Petite anecdote au passage, les chercheurs de Riot Games sont tombés sur cette faille parce que Valorant refusait de se lancer sur certains systèmes. Leur anti-cheat Vanguard vérifie que les protections DMA sont bien actives au démarrage, et il a détecté que sur certaines machines, ce n'était pas le cas. De fil en aiguille, ils ont creusé et fini par identifier ce problème côté firmware UEFI.
Bref, les quatre constructeurs ont publié (ou sont en train de publier) des mises à jour de firmware pour corriger le problème. Attention toutefois, chez Gigabyte, le correctif pour TRX50 est prévu pour le premier trimestre 2026, et chez ASRock, les BIOS pour les séries 600/700/800 sont disponibles mais ceux de la série 500 sont encore en cours de développement.
Donc allez faire un tour sur le site support de votre fabricant, vérifiez si votre modèle est concerné, et installez le patch si c'est le cas.

Quand une caméra de surveillance TP-Link laisse traîner ses clés HTTPS partout...
Vous avez peut-être une caméra Tapo C200 qui tourne chez vous pour surveiller le chat, le bébé ou l'entrée. C'est mon cas et j'adore cette caméra mais j'ai une mauvaise nouvelle à vous annoncer... Le chercheur en sécurité Simone Margaritelli (alias evilsocket) vient de passer 150 jours à la disséquer et le résultat n'est pas glorieux pour TP-Link.
Alors déjà, commençons par le plus gros WTF qu'il a découvert... la clé privée HTTPS de la caméra, ce truc censé être ultra-secret qui permet de chiffrer les communications. Et bien elle est hardcodée dans le firmware. C'est donc la même clé pour TOUTES les caméras du même modèle. Du coup, n'importe qui peut faire un Man-in-the-Middle et intercepter ce que vous voyez sur votre caméra. Ah on se met bien déjà là, hein ? ^^
Et attendez, ça ne s'arrête pas là puisque Margaritelli a trouvé un bucket S3 chez Amazon, totalement ouvert au public, qui contient TOUS les firmwares de TOUS les produits TP-Link. C'est open bar, sans authentification, Noël avant l'heure pour les chercheurs en sécu... et les hackers.
En fouillant le firmware avec Ghidra et Claude (oui, l'IA a aidé au reverse engineering), le chercheur a découvert quatre failles critiques. La première, c'est un buffer overflow dans le parser SOAP XML utilisé par le protocole ONVIF. En gros, si vous envoyez un message trop long, la caméra plante. Pas besoin d'être authentifié pour ça, une requête HTTP suffit.
La deuxième faille est du même genre mais dans le header Content-Length. Envoyez 4294967295 (le max d'un entier 32 bits) et boum, integer overflow. Et la troisième, c'est la cerise sur le gâteau puisque l'endpoint connectAp reste accessible sans authentification même après le setup initial. Du coup, un attaquant peut forcer votre caméra à se connecter à son propre réseau WiFi malveillant et intercepter tout le flux vidéo. Vous ne vous y attendiez pas à celle-là, si ?
Et la quatrième faille, oubliée nulle part ailleurs c'est l'API scanApList qui balance la liste de tous les réseaux WiFi autour de la caméra, sans auth. Avec les BSSID récupérés et un outil comme apple_bssid_locator, on peut géolocaliser physiquement la caméra à quelques mètres près. Sur les 25 000 caméras exposées sur le net, ça fait froid dans le dos.
Le plus frustrant dans cette histoire, c'est que Margaritelli a signalé tout ça en juillet 2025 et TP-Link a demandé des rallonges de délai, encore et encore, durant plus de 150 jours. Et au final, les failles ont été corrigées mais pas de patch sur les pages publiques des CVE. Ah et petit détail rigolo, comme TP-Link est sa propre autorité de numérotation CVE, ils s'auto-évaluent sur leurs propres failles. Donc y'a pas de conflit d'intérêt du tout... ahem ahem...
Le chercheur estime qu'environ 25 000 de ces caméras sont exposées directement sur Internet donc si comme moi, vous en avez une, vérifiez que le firmware est bien à jour et surtout, ne l'exposez JAMAIS directement sur le net. Mettez-la derrière un VPN ou un réseau isolé.
Je trouve ça cool que Margaritelli ait utilisé de l'IA pour accélérer la phase de reverse engineering. Avec Claude Opus et Sonnet avec GhidraMCP, il a pu analyser le code assembleur et c'est comme ça que l'IA a identifié rapidement les fonctions vulnérables et expliqué le fonctionnement du code. Bref, l'IA comme outil de hacking, c'est assez ouf...
Voilà, donc si vous avez du matos TP-Link chez vous, gardez un œil sur les mises à jour et réfléchissez à deux fois avant de l'exposer sur le net. Et si vous aimez la lecture, l'analyse complète est dispo sur le blog d'evilsocket .
Beau boulot !

Mods Minecraft : gare aux malwares qui mènent au Game Over !
Docker offre ses images blindées à tout le monde - Enfin un peu de sécu sans vendre un rein
Si vous utilisez des conteneurs Docker au quotidien, vous allez sauter de joie car Docker vient d'annoncer que ses Docker Hardened Images (DHI), ces fameuses images ultra-sécurisées qui étaient réservées aux entreprises prêtes à cracher le pognon, sont maintenant gratuites pour tout le monde. Et c'est pas encore un truc limité avec des restrictions à la noix, non non... C'est du vrai open source sous licence Apache 2.0.
Ils proposent donc plus de 1 000 images conteneur prêtes à l'emploi, construites sur Debian et Alpine et ces images sont "durcies", c'est-à-dire qu'elles ont été débarrassées de tous les composants inutiles qui traînent habituellement dans les images de base et qui ne servent qu'à augmenter la surface d'attaque. Du coup, ça leur permet d'annoncer une réduction des vulnérabilités de plus de 95% par rapport aux images classiques. C'est pas maaaal, hein ?
Et ce qui est top c'est que chaque image embarque un SBOM complet (le fameux Software Bill of Materials), des données CVE transparentes accessibles publiquement, une preuve cryptographique d'authenticité et une provenance SLSA Level 3. Bref, c'est plutôt sérieux de ce que je capte.
Car faut dire que les attaques sur la supply chain logicielle, c'est devenu le cauchemar numéro un des développeurs. En 2025, ces attaques auraient causé plus de 60 milliards de dollars de dommages selon les estimations, soit le triple d'il y a quatre ans, du coup, avoir des images béton dès le départ, sans devoir se prendre la tête à tout vérifier soi-même, ça fait la diff.
Maintenant, si vous êtes une grosse boîte avec des besoins spécifiques, Docker propose aussi une version Enterprise payante avec des SLA garantis sur la remédiation des CVE, des images compatibles FIPS, des options de personnalisation et même un support étendu de 5 ans après la fin du support officiel. Des entreprises comme Adobe et Qualcomm ont déjà fait le saut mais pour nous, utilisateurs lambdas et autres développeurs qui bossons sur nos projets perso ou des startups incroyables du futur, la version gratuite devrait largement suffire.
Et en cadeau bonux, sachez que l'assistant IA de Docker peut maintenant scanner vos conteneurs existants et vous recommander automatiquement les images durcies équivalentes. Y'a même des Hardened Helm Charts pour Kubernetes et des serveurs MCP durcis (MongoDB, Grafana, GitHub...). Que demande le peuple ?
Voilà, si vous voulez vous y mettre, tout est dispo sur le Docker Hub sans aucune restriction d'usage ni abonnement requis. Foncez !

LibrePods - Le hack qui libère vos AirPods de la prison Apple
Vous avez des AirPods Pro que vous avez payés 300 balles et quand vous les branchez sur votre téléphone Android ou votre PC Linux, la moitié des fonctionnalités disparaissent. C'est pas parce que le matériel ne peut pas les faire mais juste parce qu'Apple a décidé que vous n'aviez pas le droit de les utiliser si vous n'êtes pas dans leur écosystème. Snif !
Et là, LibrePods débarque et règle ce problème. Ils s'agit d'un projet open source qui déverrouille toutes les fonctionnalités exclusives des AirPods sur les appareils non-Apple, et c'est compatible avec les AirPods Pro 2, AirPods Pro 3 (sauf le monitoring cardiaque), les AirPods 4, et même les AirPods Max en mode complet. Les autres modèles AirPods ont également un support basique (batterie et détection d'oreilles).
Mais alors qu'est-ce que vous récupérez avec LibrePods ?
Hé bien tout ce qu'Apple vous a vendu mais que vous ne pouviez pas utiliser ailleurs que sous iOS. Par exemple, le contrôle du bruit actif et la transparence adaptative, la détection d'oreille qui met en pause quand vous retirez un écouteur, les gestes de la tête pour répondre aux appels, le statut de batterie précis, les paramètres d'aide auditive complets, la connexion à deux appareils simultanés, et la reconnaissance de conversation qui baisse automatiquement le volume.
La dernière version (v0.2.0-alpha) a ajouté pas mal de trucs sympas comme la possibilité de voir la batterie de vos AirPods même quand ils ne sont pas connectés à votre téléphone, la connexion automatique quand vous recevez un appel ou lancez de la musique, et la personnalisation complète du mode transparence (amplification, balance, tonalité, réduction du bruit ambiant).
Techniquement, LibrePods fonctionne en utilisant un hook sur le Bluetooth Device Identification. Ce DID Bluetooth, c'est ce qui permet aux appareils de s'identifier entre eux et Apple utilise ce système pour vérifier si l'appareil connecté est un produit Apple. Si oui, les fonctionnalités se débloquent, si non, elles restent cachées. LibrePods se fait donc passer pour un appareil Apple à ce niveau, du coup, les AirPods croient qu'ils sont connectés à un iPhone ou un Mac. Et là, hop, tout se débloque ! Chouette non ?
Et c'est pas un hack compliqué... Ça consiste juste à enlever un filtre logiciel qu'Apple a mis volontairement pour vous forcer à rester dans leur écosystème.
LibrePods fonctionne sur Android et Linux. Notez que pour Android, vous devez avoir un appareil rooté avec Xposed installé à cause d'un bug dans la stack Bluetooth d'Android. Par contre, bonne nouvelle si vous êtes sur un OnePlus ou un Oppo avec ColorOS ou OxygenOS 16, vous pouvez utiliser l'app sans root pour les fonctions de base comme l'ANC, la reconnaissance de conversation et la détection d'oreilles !
Sur Linux, une nouvelle version est en développement actif et promet d'apporter encore plus de fonctionnalités mais en attendant, l'ancienne version permet déjà de contrôler les modes de bruit, les paramètres d'aide auditive, et d'autres fonctions.
D'autres applis existent pour gérer les AirPods sur Android comme CAPod, AirPodsDesktop, MagicPods, EarX mais elles ne proposent pas grand chose par rapport à LibrePods.
C'est vrai que l'Union Européenne force les fabricants à déverrouiller le firmware de certains appareils pour permettre la réparation et l'interopérabilité sauf que les écouteurs Bluetooth ne sont pas couverts par ces lois, ce qui fait qu'Apple peut continuer à brider des fonctionnalités matérielles avec du logiciel sans aucun problème légal.
LibrePods prouve donc qu'on n'a pas besoin d'attendre des lois. Faut juste des hackers qui en ont marre de se faire entuber et un peu de code !
Voilà, si vous avez des AirPods et que vous utilisez Android ou Linux, franchement, allez voir. Y'a tout sur le repo GitHub : le code source, les instructions d'installation, la doc technique...etc
Merci à Kiyoshi pour l'info !

Obsidenc - Du chiffrement parano en Rust pour vos dossiers sensibles
Vous avez des dossiers sensibles que vous aimeriez chiffrer avant de les balancer sur un cloud ou un disque externe ? Ça tombe bien, je vous ai trouvé un petit outil en Rust qui va vous plaire.
Obsidenc , c'est son nom, est un utilitaire de chiffrement que son créateur qualifie de "paranoid-grade". Et après avoir jeté un œil au code source, je peux vous dire que c'est pas du marketing puisque ce truc archive votre répertoire en TAR et le chiffre avec XChaCha20-Poly1305, un algorithme AEAD moderne qui assure à la fois la confidentialité et l'intégrité de vos données.
Côté dérivation de clé, ça utilise Argon2id conforme à la RFC 9106. Pour les non-initiés, Argon2id c'est l'algo qui a gagné le Password Hashing Competition et qui est spécifiquement conçu pour résister aux attaques par GPU et circuits spécialisés (ASIC). L'outil adapte automatiquement les paramètres à votre machine en utilisant 85% de votre RAM disponible (entre 512 Mo minimum et 2 Go maximum) afin de rendre le brute-force astronomiquement coûteux. Et si vous avez moins de RAM dispo, il compense en augmentant le nombre d'itérations.
C'est du code Rust bien propre qui utilise les bibliothèques cryptographiques RustCrypto (bien auditées par la communauté) et le code implémente des bonnes pratiques de sécurité comme le memory locking (mlock sur Unix, VirtualLock sur Windows) pour éviter que vos clés se retrouvent dans le swap, et le zeroize pour effacer la mémoire sensible après utilisation.
Vous compilez ça avec cargo build --release, puis pour chiffrer un dossier :
obsidenc encrypt ~/mon-dossier ~/mon-dossier.oen
Pour déchiffrer :
obsidenc decrypt ~/mon-dossier.oen ~/mon-dossier-dechiffre
Le mot de passe doit faire minimum 20 caractères (pas de négociation possible, déso pas déso) et vous devez le confirmer deux fois. Vous pouvez aussi ajouter un fichier de clé en plus du mot de passe pour du 2FA old-school.
L'outil a aussi quelques protections défensives sympas. Par exemple, il refuse les symlinks (vecteur d'attaque classique), limite le nombre de fichiers à 1 million et la longueur des chemins à 4096 caractères pour éviter les zip bombs. Sur les systèmes Unix, il vérifie même que votre fichier de clé n'est pas lisible par tout le monde (chmod 600 obligatoire).
Cet outil part du principe qu'un attaquant peut avoir accès à votre fichier chiffré et dispose de temps illimité pour tenter de le casser, du coup, tout est conçu pour rendre l'attaque offline la plus douloureuse possible.
Bref, si vous cherchez un moyen de sauvegarder vos dossiers sensibles de manière vraiment sécurisée avant de les balancer sur un cloud ou un disque externe, obsidenc fait le taf et en plus c'est open source (MIT/Apache 2.0) !

Ces extensions VPN gratuites aspirent toutes vos conversations avec ChatGPT
Vous utilisez une extension VPN gratuite sous Chrome ou Edge pour "protéger votre vie privée" ? Cool story les bro, mais si je vous disais que cette même extension enregistre peut-être toutes vos conversations avec ChatGPT, Claude, Gemini et compagnie pour les revendre à des courtiers en données (les fameux data brokers) ?
Hé bien c'est exactement ce que viennent de découvrir les chercheurs en sécurité de Koi qui ont mis le doigt sur 4 extensions très populaires comptabilisant plus de 8 millions d'utilisateurs au total : Urban VPN Proxy (6 millions à elle seule), 1ClickVPN Proxy, Urban Browser Guard et Urban Ad Blocker qui aspirent silencieusement tout ce que vous tapez dans vos chat IA préférées.
Le truc vicieux, c'est que ces extensions ne se contentent pas de regarder votre historique de navigation comme les trackers classiques. Non non non, elles injectent du code JavaScript directement dans les pages des chatbots IA quand vous les visitez et ça modifie les fonctions de base du navigateur (fetch() et XMLHttpRequest pour les techos) pour intercepter absolument tout ce qui passe entre vous et l'IA.
Vos prompts, les réponses du chatbot, les métadonnées de conversation, tout est aspiré et envoyé vers les serveurs analytics.urban-vpn.com et stats.urban-vpn.com. Et le pire c'est que cette collecte continue en arrière plan même quand le VPN est désactivé. Bye bye tous vos secrets.
Derrière ces extensions se cache Urban Cyber Security Inc., une boîte affiliée à BiScience, un courtier en données bien connu des chercheurs en sécurité. Ces gens-là sont passés de la collecte d'historique de navigation à la collecte de conversations IA complètes, soit un niveau de sensibilité bien supérieur vu ce qu'on peut raconter à une IA (questions médicales, code propriétaire, problèmes personnels, données financières...).
Et devinez quoi ? Ces extensions arboraient fièrement le badge "Featured" sur le Chrome Web Store et le Microsoft Edge Add-ons, censé garantir que Google et Microsoft ont vérifié leur sécurité. Nos deux géants américains ont donc validé des extensions qui violent directement leur propre politique d'utilisation limitée des données utilisateurs.
Bref, si vous avez installé une de ces extensions et utilisé ChatGPT, Claude, Gemini, Copilot, Perplexity, DeepSeek, Grok ou Meta AI depuis juillet de cette année, partez du principe que toutes ces conversations sont maintenant sur les serveurs d'un data broker et potentiellement revendues à des annonceurs.
La morale de l'histoire, c'est que dans le cas des VPN gratuits, le produit c'est littéralement tout ce que vous faites en ligne. Donc si vous voulez vraiment protéger votre vie privée avec un VPN, mieux vaut payer quelques euros par mois pour un service sérieux comme NordVPN ou Surfshark qui n'a pas besoin de revendre vos données pour survivre.
🔒 VPN sérieux vs extensions gratuites douteuses
Pour protéger réellement vos conversations IA et votre vie privée sans finir dans une base de données de data broker, NordVPN fait le job :
- ✓ Politique stricte de non-conservation des logs (auditée par des tiers indépendants)
- ✓ Chiffrement AES-256 de tout votre trafic, y compris vos échanges avec ChatGPT & co
- ✓ Protection contre les fuites DNS et WebRTC
- ✓ Plus de 8000 serveurs dans 110+ pays
- ✓ Garantie satisfait ou remboursé 30 jours
Tester NordVPN sans risque → (lien affilié)
Et désinstallez moi ces merdes immédiatement si vous les avez.

Achats en ligne : la plateforme AliExpress est-elle sûre ?
120 000 caméras IP piratées en Corée du Sud
Si vous avez des caméras connectées chez vous et que vous vous baladez régulièrement, comme moi, en tenue d’Adam (ou d’Ève), j’ai une petite histoire qui va peut-être vous faire réfléchir. La police sud-coréenne vient d’arrêter 4 personnes qui auraient piraté plus de 120 000 caméras IP présentes dans des domiciles et des commerces pour en extraire des vidéos à caractère sexuel. Et oui, les gens filmés n’en savaient évidemment rien du tout.
Les lieux ciblés sont des maisons privées, des salles de karaoké, un studio de pilates et même… un cabinet de gynécologue. Gloups… Vous imaginez le truc ? Vous allez vous faire examiner chez le médecin et paf, y’a un mec de l’autre côté de la planète qui revend la vidéo sur un site louche. C’est moche.
D’après l’Agence nationale de police sud-coréenne, les quatre suspects agissaient indépendamment les uns des autres. L’un d’eux aurait piraté 63 000 caméras à lui seul et produit 545 vidéos qu’il a revendues pour environ 25 000 euros en cryptomonnaies. Un autre a compromis 70 000 caméras, extrayant 648 vidéos vendues une quinzaine de milliers d’euros au total. 3 acheteurs qui ont visionné ces vidéos ont également été arrêtés.
Mais comment ont-ils fait pour pirater autant de caméras ? Hé bien, la technique est d’une banalité affligeante. Ils ont tout simplement déviné les mots de passe trop simples ou par défaut des caméras . Vous savez, le fameux “admin/admin” ou “123456” que personne ne change jamais.
Bon, moi je vous rassure, je peux me balader tranquillement en calbut ou tout nu chez moi sans craindre de finir sur un site coréen douteux. J’ai une astuce toute bête : mes caméras sont branchées sur des prises connectées qui sont reliées à mon système d’alarme. Quand j’active l’alarme en partant, les caméras s’allument automatiquement. Et quand je suis chez moi et que l’alarme est désactivée, les caméras sont physiquement coupées de l’électricité.
Pas de jus, pas de vidéo, pas de risque.
Même le hacker le plus balèze du monde ne peut pas pirater une caméra éteinte. Après, si quelqu’un arrive à hacker mon système d’alarme, là on passe à un autre niveau… mais j’ai de la bonne came côté sécurité, je suis plutôt serein.
Les autorités sud-coréennes ont prévenu individuellement les victimes et leur ont conseillé de changer leurs mots de passe immédiatement. Elles rappellent aussi les bonnes pratiques telles que des mots de passe complexes avec majuscules, minuscules, chiffres et caractères spéciaux, et surtout du WPA2 ou WPA3 pour le WiFi (le vieux WEP c’est open bar pour les hackers).
Voilà, si vous avez des caméras IP chez vous, prenez deux minutes pour vérifier vos mots de passe et si vous êtes du genre pudique, pensez à la solution des prises connectées qui coupent l’alimentation quand vous êtes à la maison. C’est simple, c’est radical, et ça vous évitera de devenir la star involontaire d’un site de “sexploitation” à l’autre bout du monde.

UnMarker - Les watermarks IA ne servent à rien
Vous vous souvenez quand les géants de la tech ont promis à la Maison Blanche qu’ils allaient marquer toutes les images générées par IA avec des filigranes invisibles pour lutter contre les deepfakes ? Hé bien, des chercheurs de l’Université de Waterloo au Canada viennent de démontrer que c’était du pipeau avec un outil de leur cru baptisé UnMarker qui supprime n’importe quel watermark IA en quelques minutes, sans même avoir besoin de savoir comment le filigrane a été créé.
Andre Kassis et Urs Hengartner , les deux chercheurs derrière ce projet, ont publié leurs travaux lors du 46ème symposium IEEE sur la sécurité et la vie privée en mai 2025 et leurs résultats sont assez dévastateurs pour l’industrie.
En effet, ils ont testé leur attaque contre à peu près tous les systèmes de watermarking existants : Yu1, Yu2, HiDDeN, PTW, StegaStamp, TRW, Stable Signature… Et le meilleur taux de détection après passage dans UnMarker qu’ils ont obtenu c’est 43%. Et en dessous de 50%, c’est considéré comme inutile statistiquement parlant.
Ils ont aussi testé le tout nouveau, tout beau SynthID de Google, que Mountain View présente comme LA solution miracle. Et résultat le taux de détection est passe de 100% à environ 21% donc autant vous dire que c’est complètement pété.
Alors comment ça marche ce truc ?
Hé bien l’astuce d’UnMarker, c’est d’exploiter une faille fondamentale que tous les systèmes de watermarking partagent. Comme l’explique Kassis avec une analogie plutôt parlante, “Si vous gribouillez l’adresse sur une lettre, le facteur ne pourra plus la livrer.” et comme tous ces systèmes doivent stocker leur watermark dans les variations spectrales des pixels, UnMarker cible précisément ce canal pour le perturber, sans créer d’artefacts visuels. L’image reste ainsi identique à l’œil nu, mais le filigrane invisible est devenu illisible.
Unmarker.it est donc une version côté client de leur outil , qui tourne entièrement dans votre navigateur. Vous déposez une image, vous la “secouez, remuez et écrasez” comme ils disent, et hop, plus de watermark ! Par contre, si le watermark est aussi visuel comme la petite étoile de Gemini, pensez à mettre un petit coup de pinceau dessus pour la cacher.
Et c’est là que ça devient vraiment inquiétant pour la lutte contre les deepfakes car toute la stratégie des gouvernements et des plateformes repose sur l’idée qu’on peut marquer les contenus IA pour les identifier automatiquement. Donc si n’importe quel clampin peut supprimer ces marqueurs en quelques clics, tout le système s’effondre. Les chercheurs sont d’ailleurs assez cash dans leur conclusion, je cite : “Nos résultats montrent que le watermarking n’est pas une défense viable contre les deepfakes, et nous exhortons la communauté à explorer des alternatives.”
Voilà, si vous pensiez que les watermarks invisibles allaient nous sauver de la désinformation par l’IA, vous vous mettez le doigt dans l’œil !

Jeux vidéo ou jeux d’argent ? Ce que cachent les boîtes à butin dans les jeux vidéo
Génération ultra connectée, génération ultra ciblée ? Découvrez comment la Gen-Z peut améliorer sa sécurité en ligne
Movies for Hackers - Quand le cinéma programme la réalité
En 1983, le président américain de l’époque, Ronald Reagan a vu le film WarGames lors d’un séjour à Camp David et si vous ne l’avez pas vu, sachez que ce film raconte l’histoire d’un ado qui pirate accidentellement les systèmes de défense américains et manque de déclencher la Troisième Guerre mondiale. Et une semaine après la projection, Ronald a convoqué le Comité des chefs d’état-major interarmées pour leur poser cette simple question : “Est-ce que le scénario est techniquement possible ?”
Et la réponse a été, sans surprise été : “oui et c’est même bien pire”.
Alors 15 mois plus tard, Reagan signe la NSDD-145 , qui est la toute première directive présidentielle sur la cybersécurité. Dire que tout est parti d’un film de science-fiction… C’est dingue je trouve et cela illustre parfaitement ce qu’on trouve sur ce site baptisé Movies-for-hackers créé par k4m4. Il s’agit d’une archive “vivante” sur la façon dont Hollywood a façonné la culture tech / hacker durant ces 40 dernières années.
On y trouve donc des thrillers comme Hackers et Blackhat, de la SF comme Matrix et Her, des documentaires type Citizenfour, et même des séries comme Mr. Robot ou Black Mirror. Chaque entrée indique le titre, l’année, et la note IMDb.
C’est simple, clair et efficace. Maintenant si vous regardez chacun de ces films, vous verrez comment ils ont, pour pas mal d’entre eux, influencé fortement la réalité tech qu’ils prétendaient représenter.
Prenez par exemple The Social Network sorti en 2010. Avant ce film, le hacker classique c’était le mec en sweat noir à capuche dans un sous-sol. Mais après Fincher, c’est devenu le dev en hoodie gris qui crée des empires depuis son dortoir universitaire. Ce film a vraiment changé l’image du programmeur dans la tête des gens. Autre exemple, Her de Spike Jonze, sorti en 2013 raconte l’histoire d’un type qui tombe amoureux d’une intelligence artificielle dotée de personnalité et d’émotions. Le film remporte l’Oscar du meilleur scénario original et à l’époque, tout ça paraît totalement impossible. C’est de la science-fiction. Sauf que là, on est 10 ans plus tard, ChatGPT a débarqué et les gens développent maintenant des relations émotionnelles avec des chatbots.
Puis y’a Matrix aussi, sorti en 1999, et ça c’est un autre cas d’école. Le film popularise l’idée que notre réalité pourrait être une simulation. On pensait à l’époque que c’était juste du divertissement pseudo-philosophique, mais aujourd’hui, allez demander à Elon Musk, et à tous ceux qui parlent sérieusement de cette théorie où on serait tous dans une simulation…
The Island de Michael Bay sorti en 2005 est aussi l’un de mes films préférés. Le scénario tourne autour du clonage humain et du trafic d’organes. Scarlett Johansson y joue une clone destinée à être récoltée pour ses organes. En 2005, c’est totalement dystopique mais aujourd’hui, avec CRISPR et les débats sur l’édition génétique, toutes les questions éthiques soulevées par le film se retrouve dans l’actualité scientifique du monde réel.
Et je n’oublie pas non plus Mr. Robot lancé en 2015 qui mérite une mention spéciale. Tous les experts en sécurité informatique ont salué la série pour son réalisme technique, avec du vrai pentesting, des vraies vulnérabilités, des vraies techniques…etc. Et c’est aujourd’hui devenu un outil pédagogique pour toute une génération de pentesters.
Voilà, alors plutôt que de voir ce repo Github comme une simple liste de films à voir quand on aime la culture hacker, amusez-vous à raccrocher chacun d’entre eux avec le monde réel… WarGames et la cybersécurité gouvernementale, Hackers et la culture underground, Matrix et cette théorie de la simulation, Her et les relations humain-IA, The Social Network et la mythologie du fondateur tech…et j’en passe. Je pense que tous ces films ont vraiment façonné la manière dont nous pensons la tech. Cette boucle de rétroaction se poursuit car les dev actuel qui ont grandi en regardant ces films, créent aujourd’hui inconsciemment ce futur qu’ils ont vu à l’écran. Et ça c’est fou !
Bref, si vous cherchez de quoi occuper vos soirées et que vous voulez comprendre d’où vient la culture tech actuelle, Movies-for-hackers fait office de curriculum non-officiel où chaque film est une leçon d’histoire !
Merci à Lorenper pour l’info !

TwoFace - Quand les sandbox deviennent inutiles
TwoFace est un outil développé par Synacktiv qui permet de créer des binaires Linux ayant 2 comportements bien distincts. Un comportement parfaitement inoffensif qui s’active dans 99% des cas et un comportement malveillant qui ne se déclenche que sur une machine ciblée spécifiquement pour l’occasion.
Comme ça, votre sandbox verra toujours la version “propre” parce qu’elle n’aura pas le bon UUID de partition.
D’après la doc de Synacktiv, voici comment ça fonctionne : Vous avez deux binaires en fait… Y’en a un qui est inoffensif et un autre malveillant. TwoFace les fusionne alors en un seul exécutable. Ainsi, au moment du build, le binaire malveillant est chiffré avec une clé dérivée depuis l’UUID des partitions disque de la machine cible. Cet UUID est unique, difficile à deviner, et stable dans le temps ce qui est parfait pour identifier une machine spécifique.
Ensuite au lancement, quand le binaire s’exécute, il extrait l’UUID du disque de la machine. Pour ce faire, il utilise HKDF (Hash-based Key Derivation Function) pour générer une clé de déchiffrement depuis cet UUID et tente de déchiffrer le binaire malveillant caché. Si le déchiffrement réussit (parce que l’UUID match), il exécute le binaire malveillant. Par contre, si ça échoue (parce que l’UUID ne correspond pas), il exécute le binaire inoffensif.
Le projet est écrit en Rust et c’est open source ! Et c’est une belle démo (PoC) d’un problème que tous ceux qui font de l’analyse de binaires ont. En effet, d’ordinaire, pour révéler le vrai comportement d’un malware on l’exécute dans une sandbox et on peut ainsi observer en toute sécurité ce qu’il fait, les fichiers qu’il crées, les connexions réseau qu’il établit etc…
Mais avec TwoFace ça casse cette façon de faire. Et c’est pareil pour les antivirus qui verront toujours la version inoffensive tant que l’UUID ne correspond pas.
Techniquement, TwoFace utilise memfd_create() pour exécuter le binaire déchiffré en mémoire, sans toucher au disque, ce qui veut dire zéro trace sur le système de fichiers. Le binaire malveillant apparaît directement en RAM, s’exécute, puis disparaît. Et si vous utilisez io_uring pour l’écriture mémoire, il n’y a même pas de trace syscall visible via strace.
Et ça, c’est la version basique car le document de Synacktiv mentionne également d’autres techniques avancées possibles comme du déchiffrement dynamique page par page du binaire ELF, des mécanismes anti-debugging, des chained loaders multi-niveaux…etc…
Le parallèle avec la backdoor XZ Utils backdoor est très instructif car celle-ci a failli compromettre des millions de serveurs Linux parce qu’un seul mainteneur a poussé du code malveillant dans une lib compressée. Elle a alors été découverte parce qu’un dev a remarqué un ralentissement SSH bizarre et a creusé… Et TwoFace montre qu’on peut faire encore pire sans toucher à la supply chain.
Pas besoin de corrompre un mainteneur de projet, de pousser un commit suspect chez Github. Là suffit d’écrire du code parfaitement propre, de le compilez avec TwoFace pour une machine spécifique, et de le déployez. Le code source sera alors auditable ainsi que le binaire mais l’audit ne révèlera rien parce qu’il se fera dans un environnement qui n’aura pas le bon UUID.
Après, techniquement, une défense existe. Vous pouvez par exemple détecter les appels à memfd_create(), monitorer les exécutions en mémoire, tracer les déchiffrements crypto à la volée…etc., mais ça demande du monitoring profond, avec un coût performance non-négligeable. Et ça suppose aussi que vous savez ce que vous cherchez…
Bref, si ça vous intéresse, c’est dispo sur GitHub !

PROMPTFLUX - Le malware qui demande à Gemini comment échapper aux antivirus
Bon vous savez tous comment marche votre antivirus. Il détecte un malware, il le bloque, et tout revient à la normale.
Mais si je vous disais que maintenant, c’est parfaitement possible qu’une heure plus tard le même malware se repointe, sauf que c’est plus le même, parce que son code a changé. Car entre temps, il a demandé à Google Gemini de le réécrire…
Bien c’est pas de la science-fiction, hein, c’est ce que décrit un rapport du Google Threat Intelligence Group (GTIG) qui nous présente une nouvelle génération de malwares qui intègrent des LLM directement dans leur exécution.
Plus de génération statique du code, c’est le malware lui-même qui appelle une API LLM pendant qu’il tourne, demande des modifications, se réécrit, et repart faire sa besogne.
Les deux exemples les plus marquants s’appellent PROMPTFLUX et PROMPTSTEAL .
PROMPTFLUX, c’est un dropper en VBScript qui appelle l’API Gemini pour obfusquer son propre code. Il se réécrit dans la base de registre Windows pour persister au reboot, puis demande à Gemini de générer de nouvelles variantes d’obfuscation. Son module interne s’appelle “Thinking Robot” et il interroge Gemini régulièrement du genre “Comment contourner l’antivirus X ? Propose des variantes de mon code pour éviter la signature Y.”
Gemini lui répond, le malware applique le conseil, se modifie, et se relance.
Comme les antivirus détectent les malwares par signatures ou comportements connus, si le malware change toutes les heures, les signatures deviennent immédiatement obsolètes. L’antivirus a alors toujours un coup de retard. Et PROMPTFLUX n’a même pas besoin d’un serveur C2 pour télécharger de nouvelles variantes puisqu’il génère ses propres variantes localement en demandant à Gemini.
GTIG estime que PROMPTFLUX est encore en développement et les échantillons analysés ne montrent pas de capacité réelle à compromettre un réseau. Mais ça reste une preuve de concept active… En gros, quelqu’un, quelque part teste cette approche.
PROMPTSTEAL, lui par contre, est déjà opérationnel. GTIG l’attribue à APT28 (FROZENLAKE), un groupe lié au renseignement militaire russe (GRU). Le CERT-UA l’a documenté sous le nom LAMEHUG en juillet dernier et c’est la première observation d’un malware qui interroge un LLM en opération réelle.
PROMPTSTEAL de son côté est écrit en Python. Il utilise l’API Hugging Face pour accéder au modèle Qwen2.5-Coder-32B-Instruct . Le malware envoie des prompts encodés en Base64, genre “récupère les infos système” ou “trouve les documents sensibles” et le LLM génère des commandes Windows d’une ligne qui sont ensuite exécutées localement par le malware. Ensuite ce dernier collecte les données et les exfiltre tranquillement.
L’astuce donc, c’est que le malware ne contient plus de commandes en dur. Il les génère à la volée selon le contexte comme ça, si l’environnement change, il demande de nouvelles commandes adaptées. Plus de pattern fixe à détecter et chaque exécution est différente.
GTIG mentionne aussi d’autres exemples tels que FRUITSHELL, un reverse shell PowerShell public qui contient des prompts pour contourner les protections LLM ou encore PROMPTLOCK, un concept de ransomware en Go qui utilise un LLM pour générer des scripts Lua de chiffrement.
Il y a aussi QUIETVAULT, un voleur de tokens JavaScript qui cible GitHub et NPM, puis exfiltre les résultats via des repos publics.
Tous ces malwares partagent la même idée : intégrer un LLM dans la chaîne d’exécution. Génération, obfuscation, commandes dynamiques, recherche de secrets… Le LLM devient un composant actif du malware !
Le rapport décrit aussi comment les attaquants contournent les protections des LLM à base d’ingénierie sociale dans les prompts. L’attaquant se fait passer le plus souvent pour un étudiant en sécurité, un participant à un CTF, ou encore un chercheur parfaitement légitime. Le LLM, configuré pour aider, répond alors à toutes les demandes.
Dans un cas documenté par GTIG, une tentative a mal tourné pour les attaquants. On le sait car dans les logs de leurs échanges avec le LLM, GTIG a trouvé des domaines C2 et des clés de chiffrement en clair. Les attaquants avaient oublié de nettoyer leurs tests et c’est grâce à ça que GTIG a récupéré l’accès à leur infrastructure puis l’a neutralisée.
Le rapport liste aussi les groupes étatiques actifs comme UNC1069 (MASAN) , lié à la Corée du Nord, qui utilise les LLM pour générer des deepfakes et voler des cryptoactifs. Ou encore UNC4899 (PUKCHONG) , aussi nord-coréen, qui emploie les modèles pour développer des exploits et planifier des attaques sur les supply chains.
De son côté, APT41 , un groupe étatique chinois, s’en sert pour obfusquer du code. Et le groupe iranien APT42 , a même tenté de construire un agent SQL qui traduirait des requêtes en langage naturel vers des commandes d’extraction de données sensibles. GTIG les a bloqué en coupant les comptes qu’ils utilisaient.
Et sur le marché noire, ce genre d’outils et de services multi-fonctions ont le vent en poupe. Génération de campagne de phishing, création de deepfakes, génération automatique de malwares, abonnements avec accès API…etc.
Leur modèle commercial copie celui des services légitimes avec une version gratuite basique pour gouter et un abonnement payant pour les fonctions avancées, avec des communautés Discord pour le support. Ça permet d’abaisser la barrière d’entrée pour les attaquants les moins expérimentés.
Côté défense maintenant, les recommandations sont assez classiques. Pensez à surveiller l’activité anormale des clés API qui pourraient être volées. Détectez les appels inhabituels à des services LLM externes depuis les processus. Contrôlez l’intégrité des exécutables et protégez tout ce qui est “secrets” sur les hôtes.
N’oubliez pas non plus de ne jamais, ô grand jamais, exécuter aveuglément des commandes générées par un modèle IA (je vous l’ai assez répété).
Voilà, tous ces exemples actuels sont expérimentaux mais le signal est donné et il est plutôt limpide : l’IA est en train de rendre les malwares plus virulents en leur permettant de s’adapter !

Les poupées russes malveillantes de Curly COMrades
Si vous me lisez depuis longtemps, vous savez que les hackers russes ne manquent jamais d’imagination quand il s’agit de contourner les antivirus… Mais alors là, le groupe Curly COMrades vient de sortir un truc qui déboite du genou de gnome… Ces affreux planquent maintenant leurs malwares dans des machines virtuelles Linux cachées dans des Windows. Oui, des russes qui créent de véritables poupées russes numérique… qui aurait pu prévoir ^^ ?
Et c’est vicieux vous allez voir… les gars activent Hyper-V sur les machines Windows 10 compromises, puis ils y déploient une VM Alpine Linux ultra-minimaliste. 120 Mo d’espace disque et 256 Mo de RAM… C’est tellement léger que ça passe complètement sous les radars des EDR classiques.
Et la beauté du truc, c’est que tout le trafic malveillant qui sort de la VM passe par la pile réseau de Windows grâce au NAT d’Hyper-V. Du coup, pour l’antivirus, tout a l’air de venir de processus Windows parfaitement légitimes.
C’est bien joué non ?
À l’intérieur de cette VM Alpine, les hackers ont installé 2 malwares custom : CurlyShell et CurlCat. Le premier c’est un reverse shell qui communique en HTTPS pour exécuter des commandes à distance. Et le second, c’est un proxy SSH inversé qui encapsule le trafic SSH dans des requêtes HTTP et le fait transiter par un proxy SOCKS. Les deux partagent une grosse partie de leur code mais divergent sur le traitement des données reçues.
Les chercheurs de Bitdefender, en collaboration avec le CERT géorgien, ont documenté cette campagne qui cible principalement la Géorgie et la Moldavie depuis fin juillet 2025. Les attaquants visent surtout les secteurs gouvernementaux, judiciaires et énergétiques… Bref, les infrastructures critiques, comme d’habitude.
Une fois infiltrés, les hackers désactivent alors l’interface de gestion d’Hyper-V pour réduire le risque de se faire griller. Ensuite, ils configurent la VM pour utiliser le Default Switch d’Hyper-V et ajoutent même des mappages domaine-IP personnalisés. Et pour couronner le tout, ils déploient des scripts PowerShell pour l’injection de tickets Kerberos et la persistance via des comptes locaux.
Et les EDR traditionnels, qui se focalisent sur l’analyse des processus au niveau de l’hôte, ne peuvent pas détecter ce qui se passe à l’intérieur de la VM. En fait pour chopper ce genre de menace, il faut des capacités d’inspection réseau avancées… Autant vous dire que la plupart des boîtes n’en sont pas équipées…
Pour lutter contre ça, Bitdefender recommande de ne pas miser sur une seule solution de sécurité, mais d’en empiler plusieurs. D’abord mettre en place une protection du réseau pour bloquer les attaques avant qu’elles n’atteignent les ordinateurs. Y ajouter un système de détection avancé qui surveille en permanence ce qui se passe sur les machines. Et surtout une vraie politique de réduction des risques en fermant tous les services Windows dont on ne se sert pas.
Hé oui, si Hyper-V n’est pas activé d’origine sur les système, c’est bien parce que ça représente un risque supplémentaire, donc si vous ne vous en servez pas, désactivez le.

Rooter une caméra de sécurité avec un MP3
L’histoire du jour est signée Luke M, un hacker qui a découvert comment rooter une caméra avec… du son !
L’appareil en question est une caméra chinoise de la marque Yi qui utilise une fonctionnalité appelée “Sonic Pairing” pour faciliter la configuration WiFi. Comme ça, au lieu de galérer à taper votre mot de passe WiFi sur une interface minuscule avec vos gros doigts boudinés, vous jouez simplement un petit son depuis votre téléphone et c’est ce son qui contient votre clé WiFi encodés en modulation de fréquence. La caméra écoute, décode, et se connecte.
Magique, non ?
Sauf que cette fonctionnalité marquée en “beta” dans l’app Yi IoT contient deux bugs magnifiques : une stack overflow local et un global overflow. En gros, en fabriquant un fichier audio malveillant avec les bons patterns, Luke a pu injecter du code arbitraire dans la caméra, ce qui lui permet d’obtenir un shell root qui se lance via la commande telnetd avec les identifiants par défaut. Tout ça, sans accès physique… juste la lecture d’un wav ou d’un MP3.
Pour arriver à ses fins, Luke a utilisé Frida , un framework de hooking que j’adore, capable d’intercepter les fonctions natives de l’app. Cela lui a permis de remplacer les données légitimes attendues par l’app par son propre payload.
Le premier bug (stack overflow) n’étant pas suffisant seul, Luke a dû utiliser un autre bug (
un out-of-bounds read via DOOM
) pour leaker un pointeur et contourner l’
ASLR
. Mais le second bug (global overflow) est bien plus intéressant puisqu’il lui permet directement de faire une injection de commande via system() lors du pairing, sans avoir besoin d’autre chose.
Voici la waveform utilisée par le second exploit
Et comme la chaîne que vous pouvez envoyer via le son peut faire jusqu’à 128 bytes c’est largement suffisant pour un telnetd ou n’importe quelle commande shell. Notez que pour que l’exploit marche, le bind_key doit commencer par ‘CN’, ce qui force un path exploitable et, en bonus fait causer la caméra en chinois ^^.
Après faut savoir que ce hack amusant ne fonctionne que si la caméra n’est pas encore connectée au cloud. Donc c’est pas très utile pour attaquer des caméras déjà déployées mais ça illustre bien le problème de tout cet IoT pas cher avec des tas de features “pratiques” comme ce “Sonic Pairing” qui finissent par être catastrophique dans la pratique.
Voilà… si vous voulez les détails techniques complets avec les waveforms et le code d’exploit, foncez lire ça sur Paged Out! #7 .

Faille WSUS CVE-2025-59287 - Comment Microsoft s'est fait pirater par le code qu'il avait banni
Je vais vous raconter la meilleure de la semaine… Microsoft vient quand même de passer 5 ans à gueuler sur tous les toits que BinaryFormatter est dangereux (ça servait à sérialiser/desérialiser des objets en binaire ave .NET) et qu’il faut arrêter de l’utiliser… et pourtant, on vient d’apprendre qu’ils continuent secrètement de l’utiliser dans WSUS (Windows Server Update Services), leur système censé sécuriser les mises à jour Windows.
Et bien sûr, ce qui devait arriver, arriva… Une magnifique faille critique dans WSUS vient d’être rendue publique, ce qui met en danger environ 500 000 serveurs WSUS actuellement accessibles via le net.
L’histoire commence en réalité en 2020. A cette date, Microsoft déclare officiellement que BinaryFormatter est dangereux, ce qui ne les empêche pas de se faire poutrer Exchange, Azure DevOps, SharePoint en 2021/2021 justement à cause de ça. Du coup, en 2023, ils annoncent le bannissement total de BinaryFormatter en interne. En 2024, ils effectuent même une mise au rebus complète de .NET 9.
Mais c’était sans compter sur cette jolie CVE-2025-59287 d’octobre 2025 qui exploite à son tour BinaryFormatter dans WSUS !
Un oubli ? Pas si sûr, car Microsoft l’utilisait toujours pour déchiffrer les cookies d’authentification de WSUS, rendant ainsi ce système de mises à jour censé protéger Windows vulnérable. La faille, c’est donc une désérialisation non sécurisée. Un attaquant non authentifié envoie une requête SOAP craftée au endpoint GetCookie de WSUS, avec un cookie AuthorizationCookie contenant un payload malveillant. Et de son côté le serveur déchiffre ce truc avec AES-128-CBC, puis passe le résultat directement à BinaryFormatter pour désérialisation.
Et là, bim bam boum, une magnifique exécution de code arbitraire avec privilèges SYSTEM !
Techniquement, la vulnérabilité touche donc les Windows Server 2012 à 2025 qui ont le rôle WSUS activé. Le score CVSS de cette faille est quand même de 9,8 sur 10 ce qui est fait une faille super critique.
L’exploitation de cette faille débute le 24 octobre soit juste après la publication du patch d’urgence de Microsoft sortie la veille c’est à dire le 23 octobre, pour corriger lui-même un autre patch publié juste avant le 8 octobre. Bref un vrai bordel et il faut croire que les attaquants ont attendu la sortie de ce patch d’urgence pour comprendre comment fonctionnait la faille ( l’exploit est ici ).
De son côté, Google Threat Intelligence traque l’acteur cybercriminel UNC6512 qui a ciblé plusieurs organisations et les chiffres font pas plaisir puisque ce sont environ 100 000 tentatives d’exploitation en 7 jours qui ont eu lieues, et 500 000 serveurs WSUS exposés sur le net sur les ports par défaut (8530 HTTP, 8531 HTTPS).
Microsoft a dû sentir la douille arriver puisqu’ils ont déprécié WSUS en septembre de l’année dernière au profit d’autres solutions comme Intune ou WUfb, soit un an avant la sortie de la CVE. Mais bien sûr, comme l’outil reste dans Windows Server 2025 avec ses 10 ans de support réglementaire, des centaines de milliers d’entreprises l’utilisent encore…
Le chaos était garanti ! Maintenant vous me connaissez, je n’aime pas vous laisser sans solution, alors pour les admins sys qui lisent ça, sachez qu’il existe un script PowerShell baptisé Find-WSUS qui permet de détecter tous les serveurs WSUS configurés dans vos GPO. C’est pratique pour faire l’inventaire et vérifier que tout est patché. Et notez aussi que le patch d’urgence c’est le KB5070883. Et si vous ne pouvez pas patcher immédiatement parce que la vie est injuste, désactivez quand même le rôle WSUS de vos Windows Server, ou bloquez les ports 8530/8531 directement dans votre firewall.
Le vrai problème en fait, c’est que WSUS n’est qu’un symptôme car une grosse partie du code en entreprise est constitué de dette technique. C’est à dire du code “mort” qui continue de tourner car personne n’ose y toucher. Brrr… ça fait peur c’et sûr ! Surtout que même Microsoft n’arrive pas à tuer sa propre création 5 ans après l’annonce de sa mort officielle, donc autant dire qu’on a tous un sérieux problème.
Bref, patchez au plus vite !
