Le PDG de Binance, Changpeng Zhao (CZ), a tiré la sonnette d’alarme au sujet d’un bogue d’authentification OpenSSH présent depuis longtemps, qui pourrait permettre à des attaquants de se connecter à certains serveurs sans connaître le mot de passe — et qui se cache dans les systèmes depuis près de dix ans. Ce qui s’est passé - Le 5 novembre, OpenSSH et Alpine Linux ont publié des correctifs pour une faille de contournement de l’authentification qui, selon les chercheurs, remonte à des modifications apportées entre 2012 et 2016. CZ a relayé l’avertissement sur X le lendemain, exhortant les administrateurs à appliquer les correctifs immédiatement. Il n’a pas indiqué que Binance avait été touchée ; les avis ne faisaient état d’aucune preuve de compromission. Fonctionnement du bogue (en bref) - La faille concerne OpenSSH sur les systèmes qui utilisent musl libc (notamment de nombreuses versions d’Alpine Linux) lorsque : - PAM n’est pas utilisé pour vérifier les mots de passe, - L’authentification par mot de passe est toujours activée, et - Certaines configurations de compte sont présentes. - Un attaquant peut contourner l’authentification en envoyant un seul mot de passe trop long (entre 257 et 1 024 octets). Si le champ de mot de passe enregistré pour le compte visé contient un astérisque (*) — ce qui signifie « aucun mot de passe » dans la fonction de hachage de musl — et qu’un autre compte local possède un hachage SHA-256 ou SHA-512 compatible, le serveur peut accepter par erreur le mot de passe trop long et accorder l’accès. - Cela peut permettre d’accéder à des comptes que les administrateurs pensaient configurés pour n’accepter que les connexions par clé SSH. Qui est concerné ? - Potentiellement vulnérables : les systèmes Alpine Linux exécutant OpenSSH sans PAM et avec l’authentification par mot de passe activée ; certaines images cloud/« tiny-cloud » Alpine, lorsque des conditions spécifiques sont ensuite réunies. - Non concernés : les systèmes qui utilisent PAM pour vérifier les mots de passe, les serveurs où l’authentification par mot de passe est désactivée et les conteneurs ne disposant pas d’un serveur SSH actif. - Le problème peut également toucher d’autres distributions Linux utilisant musl libc (certaines configurations OpenWrt, Buildroot et Yocto). Le serveur SSH Dropbear fourni par défaut avec OpenWrt n’est pas touché par ce bogue. Découverte et contexte technique - Le chercheur en sécurité Özgün Kültekin (Wakefield) a découvert et baptisé la faille « *sshole ». Il l’a reliée au comportement de musl lors du hachage des mots de passe : musl renvoie un astérisque lorsqu’un mot de passe dépasse sa limite de traitement de 256 octets. Une modification d’OpenSSH datant de juillet 2016 (destinée à corriger les fuites d’informations permettant de découvrir des noms d’utilisateur) peut amener sshd à emprunter le sel d’un autre compte lorsqu’il vérifie un compte dépourvu de hachage valide. Combinés, ces comportements permettent à un astérisque renvoyé de correspondre à un astérisque enregistré, ce qui entraîne une authentification réussie. - L’équipe d’OpenSSH a reconnu la vulnérabilité, mais affirme que la cause première se trouve en dehors de sshd ; sa version du 5 novembre (OpenSSH 10.6p2) met en œuvre une solution de contournement pour bloquer l’erreur d’authentification. Pourquoi cela concerne les opérateurs crypto - De nombreuses images cloud légères et solutions d’infrastructure dans le secteur crypto utilisent Alpine Linux ou des versions basées sur musl. L’avis d’Alpine mentionne les images tiny-cloud des versions 3.18.11 à 3.24.3 : leur compte alpine par défaut peut exécuter doas sans mot de passe et, si les conditions d’exploitation sont réunies par la suite, une connexion réussie peut permettre d’obtenir les privilèges root. Même si les connexions root sont bloquées par défaut, un compte administratif compromis peut toujours servir à obtenir des privilèges élevés — un risque sérieux pour les opérateurs de nœuds, les portefeuilles, les validateurs et les services de conservation. Que faire maintenant ? - Mettre à jour : installez OpenSSH 10.6p2 ou les paquets corrigés d’Alpine Linux (Alpine indique avoir rétroporté les correctifs jusqu’à la version 3.16). Attention : la mise à jour des paquets ne suffit pas ; vous devez redémarrer le processus sshd après la mise à jour. - Si vous ne pouvez pas effectuer la mise à jour immédiatement : désactivez temporairement l’authentification par mot de passe en définissant PasswordAuthentication no dans sshd_config, puis redémarrez sshd après avoir vérifié que l’accès par clé SSH fonctionne. - Vérifier les journaux : examinez les journaux d’authentification SSH pour repérer toute connexion inattendue par mot de passe à des comptes qui ne devraient pas l’accepter. - Si vous ne pouvez pas exclure un accès non autorisé, considérez la machine comme compromise et suivez vos procédures de réponse aux incidents. Correctifs et versions - OpenSSH a publié la version 10.6p2 le 5 novembre. - Alpine a identifié les versions de paquets corrigées (notamment 3.21.10, 3.22.8, 3.23.8 et 3.24.4) et indique que les correctifs sont disponibles pour les versions actuelles ainsi que pour les anciennes branches jusqu’à la version 3.16. Contexte - La publication de CZ est le dernier d’une série d’avertissements de sécurité qu’il a signalés publiquement (il a récemment dénoncé un faux site Trust Wallet utilisé pour hameçonner les utilisateurs). Compte tenu du risque de déplacement latéral à partir d’un seul compte compromis, les opérateurs d’infrastructures crypto devraient donner la priorité à ces correctifs. En résumé : si vous utilisez Alpine ou un système basé sur musl avec OpenSSH et que l’authentification par mot de passe est activée, appliquez le correctif et redémarrez sshd dès maintenant — ou, au minimum, désactivez l’authentification par mot de passe jusqu’à ce que vous puissiez appliquer le correctif et vérifier vos systèmes. Retrouvez d’autres actualités générées par l’IA sur : https://app.chaingpt.org/news