Si vous utilisez MongoDB, accrochez-vous bien parce que là, c'est du lourd. Une faille critique baptisée MongoBLEED vient d'être découverte et elle touche à peu près toutes les versions de MongoDB sorties depuis 2017. Sept ans de versions vulnérables, c'est un chouette record, je trouve ^^.

Le problème avec cette CVE-2025-14847, c'est qu'elle exploite la compression zlib des messages. En gros, quand un attaquant envoie un message compressé mal formé avec des paramètres de longueur trafiqués, MongoDB se met à recracher des bouts de sa mémoire heap sans broncher. Et dans cette mémoire, on peut trouver des trucs sympa genre des mots de passe, des tokens d'authentification, des clés de chiffrement... Bref, le jackpot pour un attaquant.

Le pire dans tout ça c'est que y'a pas besoin d'être authentifié pour exploiter la faille. Si votre instance MongoDB est accessible depuis le réseau, n'importe qui peut s'y connecter et commencer à siphonner votre mémoire. C'est exactement le même genre de cauchemar que Heartbleed en 2014, d'où le petit surnom affectueux.

Du coup, qui est concerné ?

Hé bien à peu près tout le monde... Les versions 3.6.0 jusqu'à 8.0.16 sont touchées, ce qui représente selon les chercheurs de Wiz environ 42% des environnements cloud. Il y aurait donc plus de 87 000 instances MongoDB exposées sur Internet et le problème, c'est que depuis le 26 décembre 2025, des exploitations actives ont été détectées dans la nature. Joyeux Noël !!

La bonne nouvelle, c'est que le fix est simple. Soit vous mettez à jour vers une version patchée (8.2.3+, 8.0.17+, 7.0.28+, 6.0.27+, 5.0.32+ ou 4.4.30+), soit vous désactivez la compression zlib en attendant. Pour ça, c'est dans la config réseau de MongoDB, paramètre compressors qu'il faut virer le zlib.

Pour vérifier si vous êtes vulnérable, un petit nmap sur le port 27017 avec le script mongodb-info vous dira quelle version tourne. Vous pouvez aussi regarder les logs réseau pour détecter des connexions suspectes avec des messages compressés anormalement petits suivis de réponses anormalement grandes. C'est le signe qu'un petit malin est en train de vous pomper la mémoire.

Bref, si vous avez du MongoDB qui traîne quelque part, c'est le moment de faire un petit tour dans vos infras. Parce que là, c'est quand même d'une faille qui permet à n'importe qui d'aspirer vos données sensibles sans même avoir besoin d'un mot de passe. Ubisoft en a fait les frais et ça pique !

Source

Vous jouez à Rainbow Six Siege ? Hé bien félicitations, vous êtes maintenant virtuellement millionnaire ! Enfin... l'étiez, parce que tout ça va être annulé.

Rainbow Six Siege X, le jeu d'Ubisoft victime d'un hack massif

Ce week-end, Ubisoft s'est fait pirater comme des jambons et pas qu'un peu. Des hackers ont réussi à distribuer 2 milliards de R6 Credits à TOUS les joueurs du jeu. Au tarif Ubisoft (15 000 crédits pour 99,99 dollars), ça représente environ 13,33 millions de dollars de monnaie virtuelle offerte gracieusement. Sympa les pirates ^^

Mais attendez, c'est pas tout ! Les attaquants ont également débloqué absolument tous les cosmétiques du jeu pour tout le monde, y compris les skins réservés aux développeurs que personne n'était censé avoir. Et pour couronner le tout, ils se sont amusés avec le système de bannissement du jeu. Résultat, des milliers de joueurs se sont retrouvés bannis puis débannis au hasard, pendant que le fil d'actualité des bans affichait des messages satiriques visant Ubisoft et ses dirigeants.

Les messages de ban détournés par les hackers formaient des phrases trop "golri", arf arf... ( Source )

Du coup, le streamer KingGeorge a immédiatement lancé l'alerte : "Ne vous connectez pas au jeu, ne dépensez pas de Renown, ne dépensez pas de Rainbow Credits". Sage conseil, parce que par le passé, Ubisoft a déjà banni des joueurs pour leurs propres erreurs. Pas cool.

Peu après le début du bordel, Ubisoft a donc coupé les serveurs et la marketplace pour tenter de contenir les dégâts. Les serveurs de Rainbow Six Siege sont toujours hors ligne au moment où j'écris ces lignes, sans ETA de retour. La bonne nouvelle, c'est qu'Ubisoft a confirmé qu'aucun joueur ne sera banni pour avoir dépensé les crédits reçus pendant l'incident, et qu'un rollback de toutes les transactions depuis 11h UTC est en cours.

Maintenant, le truc vraiment chaud c'est la méthode utilisée car selon le groupe de recherche en sécurité VX-Underground, plusieurs groupes de hackers auraient exploité Ubisoft en même temps. L'un d'eux aurait utilisé une faille MongoDB récemment découverte, baptisée MongoBleed (CVE-2025-14847). Cette vulnérabilité permet à n'importe qui de siphonner la mémoire des serveurs MongoDB exposés, récupérant au passage des credentials, des tokens d'authentification et des clés. Un PoC public circule depuis le 26 décembre et environ 87 000 instances MongoDB seraient vulnérables dans le monde (mettez à jour, hein !!).

Un autre groupe prétend avoir aussi utilisé cette faille pour se balader dans les dépôts Git internes d'Ubisoft et voler des archives de code source remontant jusqu'aux années 90. Ces affirmations restent non vérifiées pour l'instant, mais si c'est vrai, c'est du lourd...

Bref, si vous avez un compte Ubisoft, je vous conseille vivement de changer votre mot de passe et de retirer vos moyens de paiement enregistrés, au cas où. Et pour Rainbow Six Siege, patience, ça va revenir... probablement avec un rollback qui effacera tous ces beaux cadeaux empoisonnés.

Source

Vous vous souvenez de ces robots chiens et humanoïdes Unitree qu'on voit partout sur les réseaux depuis quelques mois ? Hé bien des chercheurs en sécurité viennent de découvrir qu'on pouvait les pirater en moins d'une minute, sans même avoir besoin d'un accès internet. Et le pire, c'est que la faille est tellement débile qu'elle en devient presque comique.

Lors de la conférence GEEKCon à Shanghai, l'équipe de DARKNAVY a fait une démonstration qui fait froid dans le dos. L'expert Ku Shipei a pris le contrôle d'un robot humanoïde Unitree G1 (quand même 100 000 yuans, soit environ 14 000 balles) en utilisant uniquement des commandes vocales et une connexion Bluetooth. Après environ une minute de manipulation, l'indicateur lumineux sur la tête du robot est passé du bleu au rouge, il a alors cessé de répondre à son contrôleur officiel, puis sous les ordres de Ku, il s'est précipité vers un journaliste en balançant son poing.

Sympa l'ambiance.

En fait, le problème vient de la façon dont ces robots gèrent leur configuration Wi-Fi via Bluetooth Low Energy (BLE). Quand vous configurez le réseau sur un robot Unitree, il utilise le BLE pour recevoir le nom du réseau et le mot de passe, sauf que ce canal ne filtre absolument pas ce que vous lui envoyez. Vous pouvez donc injecter des commandes directement dans les champs SSID ou mot de passe avec le pattern « ;$(cmd);# », et hop, exécution de code en tant que root.

Et le truc encore plus dingue, c'est que tous les robots Unitree partagent la même clé AES codée en dur pour chiffrer les paquets de contrôle BLE, donc si vous avez cracké un G1, vous avez cracké tous les G1, H1, Go2 et B2 de la planète. Et là vous allez me dire : Et la sécurité du handshake ? Hé bien elle vérifie juste si la chaîne contient « unitree » comme secret. Bravo les gars ^^.

Du coup, la vulnérabilité devient wormable, c'est à dire qu'un robot infecté peut scanner les autres robots Unitree à portée Bluetooth et les compromettre automatiquement à son tour, créant ainsi un botnet de robots qui se propage sans intervention humaine. Imaginez ça dans un entrepôt avec 50 robots !! Le bordel que ça serait...

Moi ce qui m'inquiète avec ces robots, c'est l'architecture d'exfiltration de données car le G1 est équipé de caméras Intel RealSense D435i, de 4 microphones et de systèmes de positionnement qui peuvent capturer des réunions confidentielles, photographier des documents sensibles ou cartographier des locaux sécurisés. Et tout ça peut être streamé vers des serveurs externes sans que vous le sachiez surtout que la télémétrie est transmise en continu vers des serveurs en Chine... Vous voyez le tableau.

En avril 2025 déjà, des chercheurs avaient trouvé une backdoor non documentée dans le robot chien Go1 qui permettait un contrôle à distance via un tunnel réseau et l'accès aux caméras, donc c'est pas vraiment une surprise que les modèles plus récents aient des problèmes similaires, hein ?

J'imagine que certains d'entre vous bidouillent des robots avec Raspberry Pi ou Arduino, alors si vous voulez pas finir avec un robot qui part en freestyle, y'a quelques trucs à faire. Déjà, pour la config Wi-Fi via BLE, ne passez jamais le SSID et le mot de passe en clair mais utilisez un protocole de dérivation de clé comme ECDH pour établir un secret partagé. Et surtout validez et sanitisez toutes les entrées utilisateur avant de les balancer dans un shell.

Et puis changez les clés par défaut, car ça paraît con mais c'est le problème numéro un. Générez des clés uniques par appareil au premier boot ou lors de l'appairage. Vous pouvez stocker ça dans l'EEPROM de l'Arduino ou dans un fichier protégé sur le Pi.

Pensez aussi à isoler vos robots sur un réseau dédié... Si vous utilisez un Pi, créez un VLAN séparé et bloquez tout trafic sortant non autorisé avec iptables. Comme ça, même si un robot est compromis, il ne pourra pas exfiltrer de données ni attaquer d'autres machines.

Ah et désactivez aussi le Bluetooth quand vous n'en avez pas besoin ! Sur un Pi, ajoutez « dtoverlay=disable-bt » dans /boot/config.txt et sur Arduino, c'est encore plus simple, si vous utilisez pas le BLE, ne l'incluez pas dans votre projet.

Bref, ces robots sont de vrais chevaux de Troie ambulants. Ils ont des capteurs, des caméras, des micros, et maintenant ils peuvent être compromis par n'importe qui à portée de Bluetooth... Donc si vous bossez sur des projets robotiques, prenez le temps de sécuriser vos communications sans fil avant de vous retrouver avec un robot qui décide de vous tuer !! Et bookmarkez ce lien car c'est là où je mets toutes mes meilleures news robotiques !

Et si vous êtes encore en train de lire mes articles à cette heure-ci, je vous souhaite un excellent Noël !

Source

Si vous utilisez GitHub Copilot ou ChatGPT pour coder plus vite, voici une nouvelle qui va peut-être vous refroidir un peu. Une fintech a découvert que des attaquants avaient extrait des données clients via un endpoint API qui n'était documenté nulle part. Personne dans l'équipe ne se souvenait l'avoir créé et après 3 semaines d'enquête, le verdict est tombé : c'est Copilot qui l'avait généré pendant une session de code nocturne.

Bienvenue dans l'ère des "phantom APIs" les amis !

J'avoue que le concept m'a fait marrer car on parle quand même d'endpoints qui existent en production mais dont personne n'a connaissance. Ahahaha... y'a pas de documentation, pas de tests, pas de validation de sécurité. C'est juste un peu de code généré par une IA qui a trouvé ça "logique" de créer un /api/v2/admin/debug-metrics qui balance du PII à quiconque tombe dessus par hasard.

J'ai vu le dernier rapport Veracode GenAI Code Security et les chiffres font un peu flipper c'est vrai ! Ils ont testé plus de 100 LLM sur 80 tâches de codage différentes, et le résultat fait mal puisque 45% du code généré par IA contient des vulnérabilités classées OWASP Top 10. En gros, presque une fois sur deux, votre assistant IA vous pond du code troué comme une passoire. Java est le grand gagnant avec 72% de taux d'échec, suivi par Python, JavaScript et C# qui tournent autour de 38-45%.

En effet, l'IA ne pense pas comme un dev qui s'est déjà fait hacker. Par exemple, quand un dev crée un endpoint, il réfléchit authentification, rate limiting, exposition de données, documentation. Alors que l'IA, elle, génère juste ce qui lui semble statistiquement logique vu son dataset d'entraînement, sans comprendre les implications sécurité ou les politiques de l'organisation.

D'ailleurs une autre étude Apiiro montre que les assistants IA ont multiplié par 10 les vulnérabilités introduites en seulement 6 mois dans les dépôts étudiés. Les chemins d'escalade de privilèges ont explosé tout comme les défauts architecturaux. Et le pire c'est que les développeurs qui utilisent l'IA exposent leurs credentials cloud (clés Azure, Storage Access Keys) deux fois plus souvent que les autres.

Y'a aussi le problème du "slopsquatting". Oui, encore un gros mot, je sais... En fait, l'IA peut vous recommander d'installer un package qui n'existe tout simplement pas. Genre elle hallucine un nom de librairie et un attaquant un peu moins con que les autres, peut enregistrer ce nom sur npm ou PyPI et y foutre du code malveillant.

Et là que ça devient vraiment problématique, c'est que les outils de sécurité traditionnels ne voient rien. L'analyse statique compare votre code à des specs documentées, sauf que les phantom APIs n'existent dans aucune spec. Les API gateways protègent les endpoints enregistrés mais laissent passer des routes non déclarées sans authentification.

Pour s'en sortir, certaines boîtes commencent donc à analyser le trafic en temps réel pour détecter les endpoints qui traînent. Y'a aussi l'audit de code spécifique IA pour repérer les patterns de génération algorithmique, et la comparaison continue entre les specs et ce qui tourne vraiment en production.

Bref, relisez votre code généré par IA comme si c'était un stagiaire collégien de 3e qui l'avait écrit, et si vous découvrez un endpoint bizarre dans votre base de code dont personne ne se souvient, y'a des chances que ce soit un "fantôme" laissé par votre copilote préféré...

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.

Source

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 !

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.

Vous voyez cette liseuse Kindle qui traîne sur votre table de chevet depuis des années ? Mais si, ce truc que vous avez oublié dans un coin parce que vous n'aimez pas lire, qui est toujours connecté au Wi-Fi, et qui contient votre numéro de carte bleue pour acheter des bouquins en un clic ?

Hé bien un chercheur en sécu vient de découvrir qu'un simple ebook vérolé pouvait lui permettre de prendre le contrôle total de votre compte Amazon.

Valentino Ricotta, un hacker éthique qui bosse chez Thalium (la division recherche de Thales à Rennes), a présenté ses trouvailles à la conférence Black Hat Europe à Londres avec un titre qui résume bien le délire : "Don't Judge an Audiobook by Its Cover".

Histoire de rentrer un peu plus dans les détails, sachez que cette faille exploite du code qui n'a rien à faire sur une Kindle de base. Ricotta s'est attaqué au système qui parse les fichiers audiobooks Audible, un format multimédia proche du MP4. Ainsi, même sur les Kindle qui ne peuvent pas lire d'audio, le système scanne quand même ces fichiers pour en extraire les métadonnées comme le titre, l'auteur et la couverture.

En analysant le code de parsing proprio d'Amazon, il a alors découvert une erreur de calcul classique dans l'estimation de la mémoire nécessaire par le logiciel. Du coup, en bricolant un faux fichier audiobook avec des valeurs bien choisies, il a pu déclencher un heap overflow qui lui permet d'écrire des données là où il ne devrait pas.

L'exploit tourne silencieusement en arrière-plan sans que la victime ne s'en aperçoive. Ricotta a ensuite enchaîné avec une deuxième vulnérabilité dans le service interne qui gère le clavier virtuel de la Kindle. Ce service tournait avec des privilèges élevés mais sans contrôle d'accès correct, ce qui lui a permis de charger du code malveillant et de prendre le contrôle complet de l'appareil. À partir de là, il a pu voler les cookies de session Amazon, ces fameux tokens qui vous maintiennent connecté à votre compte.

Bref, une fois qu'un attaquant a mis la main sur une Kindle et ces tokens, les possibilités sont plutôt larges : accès aux données perso, infos de carte bancaire, et même pivot vers votre réseau local ou d'autres appareils liés à votre compte Amazon. Les victimes potentielles sont donc tous ceux qui font du "side-loading", c'est-à-dire qui téléchargent des ebooks sur des sites tiers et les balancent sur leur Kindle via USB. Avec ça, même sans avoir de connexion internet, le mal est vite fait.

C'est pas la première fois que quelqu'un découvre une faille sur les Kindle via des ebooks vérolés, puisque des chercheurs de Realmode Labs et Check Point avaient déjà fait le coup en 2021 et là aussi les deux failles ont été jugées "critiques" par Amazon et corrigées depuis... Et Ricotta a empoché 20 000 dollars de bug bounty que Thales a reversé à une asso caritative.

Bravo à lui !

Source

Je ne connaissais pas le NanoKVM mais c’est un petit boîtier KVM chinois vendu entre 30 et 70€ qui permet de contrôler un PC à distance. Sauf qu’un chercheur en sécurité slovène a découvert qu’il embarquait un micro planqué capable d’enregistrer tout ce qui se dit autour. Ça craint !

En effet, Matej Kovačič a ouvert son NanoKVM et y a trouvé un minuscule composant de 2x1 mm dissimulé sous le connecteur. Un truc tellement petit qu’il faut une loupe ou un microscope pour le dessouder proprement. Et pourtant, ce micro MEMS est capable d’enregistrer de l’audio de “qualité surprenamment élevée” comme il le dit et le pire c’est que l’appareil est fourni avec tous les outils nécessaires (amixer, arecord) pour l’activer via SSH et même streamer le son en temps réel sur le réseau.

Alors comment c’est arrivé là ?

En fait le NanoKVM est basé sur un module LicheeRV Nano qui est prévu pour plein d’usages embarqués différents, dont certains nécessitent de l’audio. Quand Sipeed l’a transformé en KVM grand public, ils ont juste… gardé le micro. Sans le documenter. Sans le désactiver. Sympa hein ?

Et le chercheur a aussi trouvé que les premières versions arrivaient avec un mot de passe par défaut et SSH grand ouvert. L’interface web n’avait aucune protection CSRF, et la clé de chiffrement des mots de passe était codée en dur et identique sur TOUS les appareils vendus. En bonus, le bidule communiquait avec des serveurs chinois pour les mises à jour, sans aucune vérification d’intégrité du firmware téléchargé. Et cerise sur le gâteau, y’avait des outils de hacking préinstallés comme tcpdump et aircrack. Aïe aïe aïe…

Depuis la publication du rapport, Sipeed a quand même bougé et ils ont corrigé pas mal de failles, mis à jour la documentation pour mentionner (enfin) la présence du micro, et annoncé que les futures versions n’auraient plus ces composants audio. Les firmwares récents désactivent aussi les drivers correspondants.

Et comme le projet est à la base open source, des membres de la communauté ont commencé à porter dessus des distributions Linux alternatives (Debian, Ubuntu). Faut ouvrir le boîtier et reflasher la carte microSD, mais au moins vous savez exactement ce qui tourne dessus…

Bref, comme quoi ça vaut toujours le coup de démonter ses appareils et de jeter un œil à ce qu’il y a dedans. Merci à Letsar pour l’info !

Source

En 2016, je vous parlais de Gogs , ce petit serveur Git auto-hébergé super léger qui s’installe en 10 secondes et c’est encore aujourd’hui une alternative sympa à GitHub pour ceux qui voulaient garder leur code chez eux. Mais attention, si vous l’utilisez, il va falloir agir vite parce que là, c’est la catastrophe.

Des chercheurs de Wiz viennent de découvrir que plus de 700 instances Gogs exposées sur Internet ont été compromises via une faille zero-day baptisée CVE-2025-8110. Et le pire, c’est que cette faille est activement exploitée depuis juillet 2025 et qu’il n’existe toujours pas de patch.

L’attaque est vicieuse car un attaquant n’a besoin que d’un compte utilisateur standard pour compromettre votre serveur. Il crée un dépôt, y ajoute un lien symbolique pointant vers un fichier sensible, puis utilise l’API PutContents pour écrire à travers ce lien et modifier le fichier .git/config. Ensuite, en bidouillant la directive sshCommand, il peut alors exécuter n’importe quelle commande sur votre serveur. Voilà, c’est plié !

Cette faille est en fait un contournement d’un ancien correctif (CVE-2024-55947). Les développeurs avaient patché le problème mais avaient oublié de gérer le cas des liens symboliques. Et ce n’est même pas la première fois que Gogs se retrouve dans cette situation puisqu’en juillet 2024, quatre failles critiques avaient été publiées (CVE-2024-39930, CVE-2024-39931, CVE-2024-39932, CVE-2024-39933), toutes avec des scores CVSS de 9.9 sur 10, et au final, les mainteneurs avaient tout simplement… cessé de répondre aux chercheurs. C’est moche !

Sur les 1400 instances Gogs exposées sur Internet identifiées par Wiz, plus de 700 ont donc été compromises. Les attaquants utilisent le framework C2 Supershell pour garder le contrôle des machines et les chercheurs soupçonnent des cybercriminels basés en Asie vu l’usage de cet outil très particulier.

Donc si vous avez un serveur Gogs qui tourne, voici ce qu’il faut faire immédiatement : Vous devez désactiver l’inscription ouverte si vous n’en avez pas besoin (c’est activé par défaut) et mettre votre instance derrière un VPN. Après pour savoir si vous êtes déjà compromis, cherchez des dépôts créés le 10 juillet avec des noms bizarres de 8 caractères.

Après à ce stade, je vous conseille de migrer vers Gitea , le fork de Gogs qui est activement (et mieux) maintenu et qui n’est pas affecté par ces failles. Gogs semble être devenu un projet abandonné niveau sécurité, et c’est vraiment dommage parce que le concept était génial.

Source