Vue lecture

Telnetd - Une faille vieille de 11 ans offre un accès root

Telnet, ça vous dit quelque chose ?

C'est ce vieux protocole réseau non chiffré que nos arrières-arrières-arrières-grands-parents utilisaient pour se connecter à des serveurs distants. C'est un truc que vous pensiez peut-être enterré depuis belle lurette... Hé bien figurez-vous qu'une faille critique vieille de 11 ANS vient d'être découverte dans le serveur telnetd de GNU InetUtils. Et le pire c'est que des hackers l'exploitent déjà activement.

ARGH !

La vulnérabilité en question, baptisée CVE-2026-24061 , permet de contourner complètement l'authentification et d'obtenir un accès root. Sans putain de mot de passe (!!!!).

Bon ok, faut quand même que le service telnetd soit actif et exposé, mais après c'est open bar les amis ! En gros, le serveur telnetd passe la variable d'environnement USER directement à la commande login sans la nettoyer. Du coup, un attaquant n'a qu'à définir USER sur -f root et utiliser **telnet -a** pour se retrouver connecté en root.

C'est moche.

Concrètement, ça touche toutes les versions de GNU InetUtils de la 1.9.3 jusqu'à la 2.7. Ça touche donc des distributions Linux, de vieux routeurs, des capteurs industriels...etc. Après, les machines exposées sur Internet avec Telnet actif c'est quand même assez rare, donc faut pas non plus paniquer.

Cependant, les attaquants n'ont pas attendu. La société GreyNoise a documenté des exploitations actives entre le 21 et le 22 janvier, soit très rapidement après la divulgation du 20 janvier. Ils ont ainsi observé 18 adresses IP différentes lancer une soixantaine de sessions Telnet, avec 83% des tentatives ciblant directement le compte root. Du travail de pros.

Heureusement, un correctif existe \o/ : GNU InetUtils 2.8 colmate la brèche mais combien de ces vieux équipements IoT ou industriels vont vraiment être mis à jour ? On connaît tous la chanson par cœur !

Mais bon, si vous avez des machines exposées avec telnetd actif, vous avez trois options : mettre à jour vers la version 2.8, désactiver complètement le service telnetd, ou bloquer le port TCP 23 au niveau du firewall. Perso, je vous conseille carrément de virer Telnet et de passer à SSH si c'est pas déjà fait. En 2026, y'a vraiment plus aucune excuse pour utiliser un protocole qui n'est pas chiffré.

Bref, encore une vieille faille qui traînait depuis 2015 et qui refait surface au pire moment.

Merci à Arfy pour l'info !

Source

  •  

WinBoat - Une faille critique découverte dans l'outil de virtualisation

Si vous faites partie des curieux qui testent WinBoat (le projet open source de TibixDev pour lancer des applis Windows sous Linux via Docker), sachez qu'une vulnérabilité critique a été identifiée dans l'outil, et le scénario d'attaque est plutôt créatif.

Pour ceux qui ne connaissent pas, WinBoat est une appli Electron qui orchestre tout un petit monde (Docker / Podman, FreeRDP) pour rendre l'expérience Windows "seamless" sur votre bureau Linux. C'est ambitieux, c'est en beta, et forcément, il y a parfois des trous dans la raquette.

D'après le write-up technique publié sur hack.do , le problème venait de l'API locale exposée par WinBoat sur le port 7148. Cette API HTTP n'était pas authentifiée, ce qui est souvent le début des ennuis.

Le scénario décrit par le chercheur est le suivant : un attaquant héberge une page web malveillante et si vous visitez cette page avec votre navigateur (et sous réserve que les sécurités CORS/PNA ne bloquent pas la requête, ce qui dépend de votre config et du navigateur), elle peut envoyer des ordres à cette API locale localhost:7148.

L'API vulnérable (notamment le endpoint /update) permettrait alors de remplacer des composants internes du système invité. En gros, l'attaquant pourrait substituer le binaire guest_server légitime par une version malveillante.

Une fois que l'attaquant a compromis le conteneur Windows, il ne s'arrête pas là. Le chercheur explique que WinBoat permet au conteneur de communiquer des "entrées d'application" à l'hôte Linux. Si le conteneur compromis envoie un chemin forgé spécifiquement et que l'hôte tente de le lancer... c'est l'exécution de code arbitraire (RCE) sur votre machine Linux.

C'est un rappel assez violent que l'isolation, c'est compliqué à faire correctement, surtout quand on veut une intégration transparente entre deux systèmes.

La bonne nouvelle, c'est que le problème a été traité. La faille concernait les versions jusqu'à la v0.8.7. La version v0.9.0 introduit une authentification obligatoire pour cette API locale, avec un mot de passe aléatoire généré au lancement, ce qui coupe l'herbe sous le pied de ce type d'attaque web.

Si vous utilisez WinBoat, la mise à jour est donc plus que recommandée et si le sujet de l'isolation vous intéresse, jetez un œil à mon tuto sur l'installation de WSL 2 ou encore à cette autre faille RCE critique qui a secoué le monde Linux récemment.

Bref, prudence avec les outils en beta qui exposent des ports locaux !

Source

  •  
❌