Un logiciel malveillant développé par un groupe lié au renseignement russe a été détecté en Estonie. Ce programme informatique ciblerait également l'Ukraine et d'autres pays d'Europe de l'Est.

Un logiciel malveillant développé par un groupe lié au renseignement russe a été détecté en Estonie. Ce programme informatique ciblerait également l'Ukraine et d'autres pays d'Europe de l'Est.

Si vous me lisez assidument, vous avez surement tout capté à la fameuse backdoor XZ découverte avec fracas la semaine dernière. Et là je viens de tomber sur un truc « rigolo » qui n’est ni plus ni moins qu’une implémentation de la technique d’exploitation de cette backdoor XZ, directement à l’intérieur d’un agent SSH.

Pour rappel, un agent SSH (comme ssh-agent) est un programme qui tourne en arrière-plan et qui garde en mémoire les clés privées déchiffrées durant votre session. Son rôle est donc de fournir ces clés aux clients SSH quand ils en ont besoin pour s’authentifier, sans que vous ayez à retaper votre phrase de passe à chaque fois.

Cet agent démoniaque s’appelle donc JiaTansSSHAgent, en hommage au cybercriminel qui a vérolé XZ, et ça implémente certaines fonctionnalités de la fameuse backdoor sshd XZ. En clair, ça vous permet de passer par cette backdoor en utilisant votre client SSH préféré.

Ce truc va donc d’abord générer sa propre clé privée ed448 avec OpenSSL puis, il faudra patcher la liblzma.so avec la clé publique ed448 correspondante. Là encore, rien de bien méchant, c’est juste un petit script Python et enfin, dernière étape, faudra patcher votre client SSH pour qu’il ignore la vérification du certificat.

Et voilà !

Une fois que vous avez fait tout ça, vous pouvez vous connecter à cœur joie avec n’importe quel mot de passe sur n’importe quel serveur qui dispose de cette faille. Bon après, faut quand même faire gaffe hein, c’est pas un truc à utiliser n’importe comment non plus. Vous devez respecter la loi, et expérimenter cela uniquement sur votre propre matériel ou avec l’autorisation de votre client si vous êtes par exemple dans le cadre d’une mission d’audit de sécurité. Tout autre utilisation vous enverra illico en prison, alors déconnez pas !

Voilà les amis, vous savez tout sur JiaTansSSHAgent maintenant. Pour en savoir plus, rendez-vous sur le repo GitHub de JiaTanSSHAgent.

Mauvaise nouvelle ! Un chercheur en sécurité du nom de « Netsecfish » vient de dénicher une faille bien vicieuse dans les NAS D-Link. C’est pas un petit bug de rien du tout puisque c’est une backdoor (porte dérobée) qui permet carrément d’exécuter des commandes à distance sur votre NAS ! Ce qui est flippant, c’est qu’il y aurait plus de 92 000 appareils exposés sur Internet qui seraient vulnérables à cette RCE.

D’après Netsecfish, la faille se planque dans le script « /cgi-bin/nas_sharing.cgi », qui gère les requêtes HTTP GET et qui autorise un compte caché avec le nom d’utilisateur « messagebus » et un mot de passe vide. Et en plus de cette porte dérobée, il y a également une faille d’injection de commande via le paramètre « system » qui permet d’exécuter tout et n’importe quoi sur le NAS. Une vraie passoire donc !

Quand on sait que sur nos NAS, on stocke à peu près tout, de nos photos perso à nos backups, je pense que là, on peut dire que ça craint. Bien sûr, vous vous dites sûrement : « Pas de panique, D-Link va corriger ça vite fait bien fait« .

Ah ah, que vous êtes drôles vous. Bah oui, parce que les modèles concernés sont en fin de vie, obsolètes, has been (comme vos t-shirts), donc D-Link ne compte pas développer de patch. Bouuuh les affreux ! La seule solution, c’est donc remplacer votre vieux NAS par un modèle plus récent. Ouin… Cela dit, je pense que les clients D-Link passeront à la concurrence… Au hasard Synology ????

92 000 appareils exposés, ça fait une belle brochette et même si c’est du vieux matos, ça doit trainer chez pas mal de monde et d’entreprises qui doivent encore l’utiliser et qui ne seront même pas au courant de ce problème, sauf s’ils lisent mon site évidemment ^^.

Bref, si vous avez un vieux NAS D-Link qui traîne dans un coin, éteignez-moi ça vite fait. Et par pitié, ne le laissez pas exposé sur Internet, sauf si vous aimez vivre dangereusement.

Source

Aïe aïe aïe, ça sent le roussi ! Une vilaine backdoor a été dénichée dans l’utilitaire xz Utils, un outil de compression présent dans un paquet de distributions Linux. Et attention, c’est du lourd : cette saloperie est capable de contourner l’authentification SSH et donc de permettre un accès non autorisé aux systèmes. Autant vous dire que c’est la panique générale !

La faille a été découverte le 29 mars 2024 par un dénommé Andres Freund, un développeur qui a flairé l’embrouille dans les versions 5.6.0 et 5.6.1 de xz Utils dont la liblzma. La backdoor se planque dans les fichiers de test bad-3-corrupt_lzma2.xz et good-large_compressed.lzma, et utilise un script appelé par build-to-host.m4 pour s’incruster dans le processus de build. Cerise sur le gâteau, elle exploite le mécanisme IFUNC de la glibc pour détourner l’authentification d’OpenSSH à l’exécution. Machiavélique !

En fait, le code malveillant ne se trouve pas directement dans le dépôt mais uniquement dans les archives de release 5.6.0 et 5.6.1. Un examen du code source ne révèle donc rien de suspect, il faut télécharger les tarballs pour chopper la version vérolée. Vicieux !

Mais le plus dingue dans l’histoire, c’est que cette backdoor a été commitée par un certain JiaT75, aka Jia Tan, l’un des deux principaux développeurs de xz Utils, qui bosse sur le projet depuis 2022 ! En fait, ce type a commencé par introduire une vulnérabilité dans libarchive en 2021 avant de s’attaquer à xz.

Quand des problèmes sont apparus avec Valgrind sur la liblzma juste après la release 5.6.0 en février, ce cher Jia Tan a suggéré qu’il s’agissait d’un bug de GCC. Il a même poussé un commit bidouillant le code pour contourner les erreurs Valgrind, en pointant vers un rapport de bug GCC n’ayant rien à voir. À ce stade, il n’y a plus de doute possible : le compte JiaT75 est contrôlé par un acteur malveillant, point barre. Reste à savoir si Jia Tan a toujours été un méchant ou si son compte a été compromis.

Depuis son entrée en scène, JiaT75 n’a pas chômé. Infrastructure de test vérolée, prise de contrôle progressive du projet, jusqu’à tenter de refiler la version backdoorée à Debian, Fedora et Ubuntu. Et dire que GitHub a attendu le dernier moment pour lui mettre le grappin dessus et bloquer l’accès au dépôt, bien joué les gars. Heureusement qu’Andres veillait au grain, sinon on n’imagine même pas le bordel.

Parce que oui, ces versions 5.6.0 et 5.6.1 ont failli se faufiler dans les releases stables des principales distribs. Par chance, elles ne se sont glissées que dans quelques bêtas, notamment Fedora 40, Fedora Rawhide et les distribs testing, unstable et experimental de Debian. Même Arch Linux y a eu droit dans une release stable. Bref, ça a failli faire très mal !

Comme le souligne Will Dormann, un analyste en sécu chez Analygence, si la backdoor n’avait pas été repérée à temps, ça aurait pu être une véritable hécatombe. Les systèmes les plus à risque sont ceux qui tournent avec glibc et xz 5.6.0 ou 5.6.1, surtout s’ils exposent un serveur SSH public. Là c’est défcon 1, faut mettre à jour TOUT DE SUITE MAINTENANT ! Pour les autres, pas de panique, mais mieux vaut jouer la prudence et updater fissa. Plus d’infos sur les systèmes touchés et comment les patcher dans cet article.

Mais qu’est-ce que SSH vient faire dans cette galère ? En fait, beaucoup de distribs Linux patchent sshd pour ajouter des fonctionnalités systemd, et libsystemd utilise la liblzma. Résultat, le code d’initialisation de liblzma est exécuté au démarrage de sshd. Et devinez quoi ? La backdoor vérifie si le programme lancé est /usr/bin/sshd et remplace des fonctions comme RSA_public_decrypt, utilisée pour valider les clés SSH. On vous laisse imaginer la suite… Une analyse complète est en cours, attendez-vous à d’autres révélations dans les prochains jours.

Depuis, c’est le branle-bas de combat. Les mainteneurs de Fedora et Debian se sont empressés de retirer les versions vérolées et de revenir à une release clean de xz Utils. Et les utilisateurs sont appelés à vérifier s’ils sont affectés en utilisant un script de détection mis à dispo par Andres himself. Mais le mal est fait et la confiance est ébranlée.

L’avenir du projet xz est incertain et il faut s’attendre à un ou plusieurs hard forks et à un gros nettoyage. Pour plus d’infos, jetez un œil aux alertes de sécurité de Redhat et Debian, ainsi qu’au thread oss-security sur le sujet.

Cet épisode rappelle cruellement qu’en matière de sécurité, la vigilance est mère de sûreté, même au sein des projets open source. Il met aussi en lumière la fragilité de notre écosystème, où des pans entiers reposent sur les épaules fatiguées de quelques mainteneurs débordés. Il est grand temps d’avoir une prise de conscience collective et de mieux soutenir ces projets critiques. Parce que mine de rien, on parle quand même des fondations qui font tourner une bonne partie d’Internet et des infrastructures critiques.