Des pirates exploitent la faille SSHole d'OpenSSH pour pénétrer des serveurs Alpine Linux

Des attaquants exploitent déjà SSHole (CVE-2026-123158, gravité 8,1 sur 10), une faille d'OpenSSH qui permet de se connecter à certains serveurs Linux avec n'importe quel mot de passe de plus de 256 caractères. Elle touche les systèmes bâtis sur la bibliothèque C musl, Alpine Linux en tête. La société de veille GreyNoise a relevé la première intrusion réussie le 7 novembre à 00 h 46 UTC, environ 40 heures après la sortie du correctif. Une fois connectés, les intrus ont cherché des mots de passe et des clés, ajouté leurs propres clés SSH et, dans un cas, installé un agent de contrôle à distance, rapporte BleepingComputer.

Comment fonctionne le contournement

Sous Linux, un * dans le champ mot de passe de /etc/shadow signifie qu'on ne peut pas du tout se connecter à ce compte par mot de passe. Alpine l'utilise pour root et pour les comptes qui se connectent uniquement par clé. Le chercheur Özgün Kültekin, de Wakefield, qui a signalé le bug, en fait remonter l'origine à une modification de musl en 2012 : quand sa fonction de hachage de mot de passe échoue, elle renvoie * au lieu d'une erreur. Or elle échoue sur tout mot de passe de plus de 256 octets. Un mot de passe très long donne donc *, correspond au compte verrouillé, et sshd laisse entrer l'attaquant. Avec PAM activé, sshd ne compare pas les empreintes de cette façon, ces systèmes sont à l'abri.

L'attaque exige quatre conditions à la fois : sshd compilé avec musl, PAM désactivé, connexion par mot de passe autorisée et au moins un compte avec * dans le champ mot de passe. Sous Alpine, les trois premières sont les réglages par défaut du paquet openssh-server, et root a un * depuis la version 3.16. Les images officielles d'Alpine pour AWS et Azure ont en plus un utilisateur alpine qui peut lancer des commandes en root sans mot de passe : s'y connecter donne le contrôle total.

Ce qu'ont fait les attaquants

OpenSSH a publié la version 10.6p2 avec le correctif le 5 novembre. L'analyse du chercheur est parue le même jour, et le code d'exploitation était sur GitHub moins d'une heure plus tard. GreyNoise a vu 16 chaînes d'attaque réussies depuis six adresses IP sur les systèmes qu'elle surveille, en précisant que ce n'est qu'une partie de l'activité. Les intrus ont vérifié s'ils se trouvaient dans un conteneur, interrogé les services de métadonnées cloud, tenté de lire les clés SSH de root et /etc/shadow, et inscrit leurs clés dans authorized_keys pour root et l'utilisateur alpine afin de garder l'accès.

Un groupe a obtenu les droits root, modifié les réglages DNS, lancé un second serveur SSH caché et installé TAC Agent, un programme Python aux commentaires et messages en chinois, capable d'exécuter des commandes et de transférer des fichiers. Il n'a jamais réussi à s'enregistrer auprès de son serveur de contrôle, tac.vpnla[.]org, et n'a reçu aucune tâche. Les sociétés de sécurité Previdian et Defused ont aussi relevé des tentatives, et watchTowr a relié la faille à des botnets et à du minage de cryptomonnaies.

Comment vérifier votre serveur

• Voyez ce qui tourne : cat /etc/os-release. S'il s'agit d'Alpine ou d'un autre système musl, lisez la suite. Les serveurs sous Ubuntu et Debian ne sont pas exposés à ce bug.
• Mettez à jour : apk upgrade openssh sous Alpine. Des paquets corrigés existent pour les branches 3.19 à 3.24 et edge, selon le suivi de sécurité d'Alpine.
• Si vous utilisez des clés, coupez la connexion par mot de passe : PasswordAuthentication no dans la configuration de sshd, puis redémarrez sshd. Cela ferme la faille même avant la mise à jour.
• Cherchez des traces : connexions par mot de passe réussies (grep "Accepted password" /var/log/messages) sur des comptes ayant * dans /etc/shadow, clés inconnues dans authorized_keys, fichiers /opt/py3/tac_agent.py et /etc/init.d/tac-agent, modifications de /etc/hosts et /etc/resolv.conf, serveur SSH supplémentaire sur un port inhabituel (ss -tlnp liste les ports ouverts).
• Si vous trouvez l'un de ces éléments, considérez le serveur comme compromis : réinstallez-le et changez tous les mots de passe et clés qui s'y trouvaient.

Cela concerne tous ceux qui font tourner leur propre VPN sur un VPS bon marché : les images Alpine légères sont populaires pour cela. La plupart des routeurs domestiques sous OpenWrt utilisent Dropbear pour SSH et ne sont pas touchés, sauf si leur propriétaire l'a remplacé par OpenSSH. Notre guide de sécurisation d'un VPS recommande déjà la connexion SSH par clé uniquement, et ce réglage bloque l'attaque.