Planète Warez

En bref :
(Résumé généré automatiquement par IA )

– 13 ans que cette bombe à retardement dormait dans Redis : 330 000 serveurs exposés sur Internet dont 60 000 sans même un mot de passe.

– Quand 5 développeurs maintiennent l’infrastructure de 75% du cloud mondial : bienvenue dans la fragilité d’Internet.

– RediShell : la faille 10/10 qui transforme votre cache Redis en porte d’entrée VIP pour les pirates.

Comme vous le savez, Redis c’est un peu le champion du cache mémoire. C’est rapide, c’est efficace, tout le monde l’utilise mais surtout, ça tourne dans 75% des environnements cloud. En gros, 3 serveurs sur 4 dans le cloud l’utilise…

Cool ? Oui sauf quand une faille critique de sécurité pointe le bout de son nez ! Et pas une petite faille, mes amis ! Une faille notée 10 sur 10 en gravité, qui permet d’exécuter du code à distance sur les serveurs.

Estampillée CVE-2025-49844, et joliment baptisée RediShell, cette faille en elle-même est assez technique puiqu’elle repose sur un bug Use-After-Free dans l’interpréteur Lua intégré à Redis. En gros, un attaquant authentifié peut envoyer un script Lua malveillant qui vient manipuler le garbage collector, provoque un accès mémoire après libération, et permet ainsi d’exécuter du code arbitraire sur le serveur.

C’est de la RCE complète salade tomates oignons, avec sauce système compromis !

Le truc, c’est que ce bug dormait dans le code depuis 13 ans dès que Redis a intégré Lua en 2012 dans la version 2.6.0. Donc pendant tout ce temps, des millions de serveurs Redis dans le monde entier avaient cette vulnérabilité activée par défaut.

Et les chiffres donnent le vertige car d’après les scans de Wiz Research, environ 330 000 instances Redis sont exposées directement sur Internet. Et sur ces 330 000, au moins 60 000 n’ont même pas d’authentification activée. Donc autant dire qu’elles sont ouvertes à tous les vents et que les serveurs qui se cachent derrière aussi…

Toute l’infrastructure cloud moderne repose sur une poignée de briques open source critiques, et ça marche tellement bien qu’on en met partout et on finit souvent par oublier à quel point c’est fragile… On l’a déjà vu par exemple avec Log4Shell qui a touché des millions de serveurs Java en 2021, puis avec Heartbleed dans OpenSSL en 2014. Et on a failli le voir avec la backdoor XZ Utils découverte in extremis en 2024.

À chaque fois, c’est le même schéma où un composant open source critique, utilisé partout, et maintenu par une équipe minuscule (souvent 1 à 5 personnes), se retrouve avec un bug qui expose des pans entiers de l’infrastructure mondiale d’Internet… Argh !

Maintenant, la bonne nouvelle , c’est que Redis a publié des patchs pour toutes les versions maintenues : 6.2.20, 7.2.11, 7.4.6, 8.0.4 et 8.2.2. Donc si vous utilisez Redis, c’est le moment de mettre à jour !! Et pendant que vous y êtes, activez aussi l’authentification avec la directive requirepass, et désactivez les commandes Lua si vous ne les utilisez pas. Vous pouvez faire ça via les ACL Redis ou simplement en révoquant les permissions de scripting.

La découverte de RediShell a été faite par Wiz Research lors du Pwn2Own de Berlin en mai 2025. Alerté, Redis a publié son bulletin de sécurité le 3 octobre dernier, et Wiz a rendu public les détails le 6 octobre. Une Timeline propre, une divulgation responsable, bref tout s’est bien passé de ce côté-là…

Maintenant pour réduire ce genre de risque à terme, je pense que ce serait cool si les géants d’Internet finançaient un peu plus directement les mainteneurs de ces briques logiciels essentielle, ainsi que des audits de l’ OpenSSF car pour le moment, on est loin du compte ! Redis est patché, heureusement, mais on sait aussi que la prochaine faille critique dans un de ces composants critiques, c’est une nouvelle fois, juste une question de temps…

– Sources : wiz.io

https://korben.info/redis-quand-75-du-cloud-repose-sur-le-meme-maillon.html

Si vous bossez dans la sécu ou que vous êtes juste curieux de comprendre comment fonctionnent les vulnérabilités, je vais vous parler d’un outil qui va vous changer la vie : Sploitus. C’est comme Google mais pour trouver des exploits sécu et avec un crâne-pieuvre en logo.

Créé par Anton “Bo0om” Lopanitsyn, un chercheur en sécurité web basé à Moscou, Sploitus est devenu LA référence pour trouver rapidement des exploits, des proof-of-concepts et des outils de hacking. Le site indexe en temps réel tout ce qui sort dans le domaine de la sécurité offensive et ça, c’est vraiment pratique quand vous devez vérifier si un système est vulnérable.

Sur sploitus.com, vous avez une barre de recherche toute simple dans laquelle vous pouvez chercher par nom de logiciel, par CVE (Common Vulnerabilities and Exposures), par type d’exploit ou même par auteur. Et le moteur va alors fouiller dans sa base de données massive et vous sortir tous les exploits pertinents.

Ce qui est cool avec Sploitus, c’est qu’il agrège plusieurs sources. On y trouve des exploits venant d’Exploit-DB, de GitHub, de Packet Storm, et plein d’autres plateformes. Comme ça au lieu de perdre du temps à chercher sur 15 sites différents, vous avez tout centralisé au même endroit et cerise sur le gâteau, les résultats sont triables par date ou par score de pertinence.

Pour chaque exploit, vous avez donc accès à pas mal d’infos utiles : la description détaillée, le code source (quand il est dispo), les plateformes affectées, et surtout un lien vers la source originale. C’est super important ça, parce que vous pouvez vérifier l’authenticité de l’exploit et voir s’il y a des mises à jour ou des commentaires de la communauté.

Le site propose aussi des flux RSS et Atom si vous voulez suivre en temps réel les nouveaux exploits qui sortent. C’est donc super pratique si comme moi, vous faites de la veille techno ou pour surveiller les vulnérabilités qui touchent vos systèmes. Y’a même un mode sombre pour ceux qui préfèrent coder la nuit (ou qui veulent juste faire plus hacker ^^).

Ah et petit détail sympa, des développeurs ont créé des scripts Python pour interroger Sploitus en ligne de commande. Le projet sploitus-search sur GitHub permet par exemple d’intégrer les recherches Sploitus directement dans vos outils de pentest. C’est super pratique par exemple pendant les CTF ou les audits de sécurité.

Maintenant, parlons un peu de l’aspect légal et éthique, parce que c’est aussi très important. Sploitus a eu par le passé quelques soucis avec des plaintes DMCA, notamment concernant un exploit WordPress, mais globalement, le site reste dans la légalité en tant que moteur de recherche qui indexe du contenu public.

CEPENDANT, les exploits référencés sur Sploitus sont des outils puissants qui peuvent causer des dégâts considérables s’ils sont mal utilisés. L’utilisation de ces exploits sur des systèmes dont vous n’êtes pas propriétaire ou sans autorisation explicite est illégale et peut vous valoir de sérieux problèmes judiciaires. Et ne comptez pas sur moi pour vous apporter des oranges en prison !

– Ces outils sont donc destinés aux professionnels de la sécurité pour :

Tester la sécurité de leurs propres systèmes Effectuer des audits autorisés Comprendre les vulnérabilités pour mieux s’en protéger Faire de la recherche en sécurité informatique

Voilà, donc si vous débutez dans le domaine, je vous conseille fortement de vous former d’abord aux bases de la sécurité informatique et de toujours travailler dans un environnement de test isolé.

D’ailleurs, Sploitus n’est pas le seul dans son genre. Vous avez aussi Exploit-DB qui propose SearchSploit en ligne de commande pour les recherches hors ligne, ou encore la base de données CVE officielle du MITRE. Mais l’avantage de Sploitus, c’est vraiment cette agrégation de sources multiples et cette interface web simple et efficace.

Voilà… Et n’oubliez jamais que le but de ce genre d’outils, c’est de sécuriser les systèmes, pas de les compromettre.

– Source :

https://korben.info/sploitus-google-exploits-outils-hacking.html

lol vive Windaube 😉

Le programme CVE (Common Vulnerabilities and Exposures), essentiel pour l’identification et le suivi des vulnérabilités informatiques à l’échelle mondiale, a frôlé l’interruption en avril 2025 en raison de l’expiration imminente de son financement fédéral. Géré par la fondation à but non lucratif MITRE et financé par la CISA (Cybersecurity and Infrastructure Security Agency), le programme risquait de cesser ses activités le 16 avril 2025.​

Face à cette menace, la CISA a prolongé le contrat de MITRE de 11 mois, évitant ainsi une interruption brutale des services critiques fournis par le programme CVE . Cette décision de dernière minute souligne la dépendance du programme à un financement gouvernemental stable et met en lumière la nécessité d’une solution pérenne pour assurer sa continuité.​

En réponse à cette situation, des discussions ont été engagées pour transférer la gestion du programme à une entité indépendante, la CVE Foundation, afin de garantir sa durabilité et son impartialité à long terme .​

Le programme CVE joue un rôle central dans la cybersécurité mondiale, permettant aux entreprises et aux gouvernements de prioriser les correctifs de sécurité et de coordonner les réponses aux menaces. Sa stabilité est donc cruciale pour la protection des infrastructures numériques à l’échelle internationale.​

– Source :

https://www.lemondeinformatique.fr/actualites/lire-faute-de-financement-le-programme-cve-de-mitre-s-arrete-96626.html

Windows 10 et 11 intègrent le client OpenSSH (Super+R, powershell, ssh.exe)
Il existe aussi Bitvise SSH Client qui est gratuit.

La majeure partie des distributions Linux ont le client OpenSSH à disposition et macos l’a aussi.

Je recommande d’y jeter un coup d’œil et laisser PuTTY pour le passé.

Une nouvelle faille de sécurité critique a été découverte dans une bibliothèque très populaire puisque présente dans de nombreuses distributions Linux : GNUC C (glibc). En l’exploitant, un attaquant peut obtenir un accès root sur la machine. Voici ce qu’il faut savoir.

Les chercheurs en sécurité de chez Qualys ont mis en ligne un nouveau rapport dans lequel ils évoquent la découverte de 4 vulnérabilités dans la bibliothèque GNU C.

Celle qui est particulièrement dangereuse, c’est la faille de sécurité associée à la référence CVE-2023-6246 est présente dans la fonction “__vsyslog_internal()” de la bibliothèque glibc. Cette fonction est très utilisée par les distributions Linux par l’intermédiaire de syslog et vsyslog afin d’écrire des messages dans les journaux.

Cette vulnérabilité de type “heap-based buffer overflow” permet une élévation de privilèges sur une machine locale sur laquelle un attaquant à déjà accès avec un compte utilisateur standard. Ainsi, il peut élever ses privilèges pour devenir root (“super administrateur”) sur cette machine. De nombreuses distributions populaires sont vulnérables, comme le précise le rapport de Qualys :

Les principales distributions Linux telles que Debian (versions 12 et 13), Ubuntu (23.04 et 23.10) et Fedora (37 à 39) sont confirmées comme étant vulnérables.

Pour Debian, rendez-vous sur cette page pour obtenir la liste des versions où cette vulnérabilité a été corrigée.

Il est à noter que cette vulnérabilité a été introduite dans la bibliothèque GNU C en août 2022, au sein de glibc 2.37. Par ailleurs, elle a été accidentellement intégrée dans la version 2.36 de glibc lorsque les développeurs ont intégré un correctif pour une autre vulnérabilité : CVE-2022-39046. Par ailleurs, la fonction “qsort()” de glibc contient une vulnérabilité qui affecte toutes les versions de la 1.04 (septembre 1992) à la version 2.38, qui est la plus récente.

L’occasion pour Qualys de rappeler l’importance de la sécurité des bibliothèques populaires :

Ces failles soulignent le besoin critique de mesures de sécurité strictes dans le développement de logiciels, en particulier pour les bibliothèques de base largement utilisées dans de nombreux systèmes et applications.

Ces dernières années, Qualys a fait la découverte de plusieurs failles de sécurité importantes au sein de Linux, notamment Looney Tunables et PwnKit.

– Sources

https://www.it-connect.fr/linux-acces-root-faille-critique-glibc-cve-2023-6246/

https://www.bleepingcomputer.com/news/security/new-linux-glibc-flaw-lets-attackers-get-root-on-major-distros/

Les chercheurs en sécurité de Google sont tombé sur une vulnérabilité qui avait déjà été signalée en 2016 sans être corrigée. Quelques années plus tard, elle s’est retrouvée dans l’arsenal d’un éditeur de logiciels espion pour pirater des smartphones Android.

La chasse aux failles zero-day n’est pas un long fleuve tranquille. Parfois, il y a des choses qui se perdent dans les méandres. Le dernier exemple en date vient d’être livré par les chercheurs en sécurité de Google. À l’occasion de la conférence Black Hat 2022, ces derniers ont présenté une palanquée de failles zero-day utilisées par des éditeurs de logiciels de surveillance dans le but de pirater des terminaux Android.

L’une de ces failles (CVE-2021-0920) est particulièrement remarquable, car elle a fait partie d’un enchaînement de vulnérabilités très sophistiqué qui permettait d’avoir un contrôle à distance du terminal avec les privilèges d’administrateur. Cette faille se trouvait dans le module « kernel garbage collection » et été patchée en septembre 2021. Mais des recherches presque archéologiques ont montré qu’elle était déjà connue depuis au moins 2016.

Une occasion manquée

Comme le relate Gizmodo, Google a pu retrouver des échanges à ce sujet dans la liste de diffusion Linux Kernel Mailing List. Un patch avait même été proposé, mais il a été refusé faute d’accord général sur la question. L’un des développeurs du noyau de Linux écrivait ainsi :

« Pourquoi est-ce que je devrais appliquer un patch qui n’est qu’un RFC [Request For Comment, un document qui décrit une technologie en vue d’une adoption future, ndlr], qui ne dispose pas d’un message de commit convenable, où il manque une véritable signature, et qui ne bénéficie pas de validations ou de retours de la part de développeurs connus ?».

Après cela, tout le monde a oublié, sauf un éditeur de logiciels espions qui l’a intégré ni vu ni connu dans son produit. Il a fallu attendre que les attaques qui en ont découlé soient analysées par les chercheurs de Google pour que cette faille revienne sur le tapis et soit enfin colmatée. Un processus finalement assez tortueux qui laisse aux pirates trop de marges de manœuvre.

Une trentaine d’acteurs suivis à la culotte

Chez Google, le risque provenant de ces éditeurs est devenu majeur. « Auparavant, nous n’avions qu’à nous concentrer sur des menaces comme celles venant de la Chine, de la Russie ou de la Corée du Nord. Désormais, notre groupe d’analyse de la menace (Threat Analysis Group, TAG) dispose d’une équipe dédiée aux fournisseurs et aux opérateurs commerciaux (…) TAG suit activement plus de 30 fournisseurs avec différents niveaux de sophistication et d’exposition publique, vendant des exploits ou des capacités de surveillance à des acteurs étatiques », a déclaré il y a quelques semaines Shane Huntley, directrice du TAG, auprès de la Chambre des représentants des États-Unis. Et ce suivi est d’autant plus difficile que les techniques utilisées par ces acteurs sont de haut niveau, comparable à celles utilisées par les États.

Source : Gizmodo - 01.net