Vulnérabilité SSH d'Alpine Linux : connexion sans mot de passe via des chaînes de caractères longues

Alpine Linux a publié une alerte de sécurité urgente concernant une vulnérabilité grave dans son implémentation du serveur OpenSSH. Ce défaut permet à des attaquants distants de contourner entièrement l'authentification par mot de passe et d'obtenir un accès shell aux systèmes affectés sans connaître aucun identifiant. Les administrateurs utilisant les versions 3.16 à 3.24 d'Alpine doivent mettre à jour leurs paquets openssh et redémarrer immédiatement le démon SSH pour combler cette faille.

Ce qui s'est passé

La vulnérabilité affecte le démon sshd lorsqu'il est compilé sans les modules d'authentification pluggables (PAM), ce qui constitue la configuration par défaut du paquet standard openssh-server d'Alpine. Un attaquant ayant accès au port SSH peut se connecter en tant que n'importe quel compte utilisateur ne disposant pas de mot de passe défini, à condition que le système possède au moins un autre compte local avec un hachage de mot de passe standard. L'attaque ne nécessite qu'une seule tentative de connexion et réussit de manière fiable sans re-tentatives ni techniques de force brute.

Ce problème touche un large éventail de versions d'Alpine, y compris les versions supportées 3.21 à 3.24 et les anciennes versions non supportées jusqu'à la 3.16. Il cible spécifiquement les systèmes où PasswordAuthentication est activé, ce qui reste la valeur par défaut d'OpenSSH sauf si désactivée explicitement. Les scénarios courants incluent les comptes root configurés avec PermitRootLogin yes, les utilisateurs créés uniquement avec des clés sans mot de passe, et les utilisateurs gérés via des services d'annuaire comme SSSD ou Winbind qui ne possèdent pas d'entrées shadow locales.

Les images officielles tiny-cloud sont particulièrement vulnérables si elles ont été modifiées après le démarrage initial. Bien que ces images soient livrées avec des paramètres par défaut sûrs, l'ajout d'un utilisateur avec un hachage de mot de passe ou la définition d'un mot de passe console introduit la condition nécessaire à l'exploitation de la faille. Une fois déclenchée, un attaquant peut se connecter en tant qu'utilisateur alpine par défaut et élever ses privilèges vers root en utilisant doas, qui est configuré pour une utilisation sans mot de passe dans ces environnements.

Fonctionnement

La cause profonde réside dans la manière dont OpenSSH gère la vérification des mots de passe lorsqu'il est compilé sans prise en charge de PAM. Dans ce mode, sshd utilise la fonction de bibliothèque C crypt() pour hacherer le mot de passe fourni et le comparer au hachage stocké dans /etc/shadow. Pour les comptes sans mot de passe, le champ stocké contient un seul astérisque (*). Normalement, crypt() nécessite un sel issu du hachage stocké pour traiter l'entrée, mais les comptes avec * n'ont pas de sel.

Lorsqu'il rencontre un tel compte, sshd emprunte le sel d'un autre compte du système qui possède un hachage valide $5$ ou $6$. La vulnérabilité se déclenche lorsque l'attaquant envoie une chaîne de mot de passe comprise entre 257 et 1024 octets. La bibliothèque C musl, utilisée par Alpine, renvoie * comme indicateur d'erreur lors du traitement de clés plus longues que 256 octets. Comme le champ stocké pour le compte cible est également *, la comparaison correspond et l'authentification réussit.

Détails clés

• Versions affectées : Alpine 3.16 à 3.24, y compris les versions edge et non supportées.
• Prérequis : sshd compilé sans PAM (ou UsePAM no), PasswordAuthentication yes, et au moins un compte avec un hachage $5$ ou $6$.
• Comptes cibles : Utilisateurs avec * dans le champ mot de passe, tels que les utilisateurs uniquement basés sur des clés ou l'utilisateur alpine par défaut.
• Paquets corrigés : Disponibles pour toutes les branches, notamment 9.9_p2-r1 pour la 3.21 et 10.6_p2-r0 pour edge.
• Détection : Vérifiez /var/log/messages pour repérer les entrées Accepted password for liées à des comptes sans mot de passe.
• Risque cloud : Les images tiny-cloud deviennent exploitables si un hachage de mot de passe est ajouté après le démarrage.

Pourquoi c'est important

Pour les ingénieurs d'infrastructure et les équipes DevOps, cette vulnérabilité remet en cause l'hypothèse fondamentale selon laquelle les comptes SSH basés uniquement sur des clés sont sécurisés contre les attaques par mot de passe. De nombreuses organisations utilisent Alpine pour les conteneurs et les VM légères, partant souvent du principe que la désactivation de la connexion root par mot de passe suffit. Cependant, ce bug contourne ces protections en exploitant l'interaction entre les champs de mot de passe vides et la présence d'autres mots de passe hachés sur le système. Cela met en évidence les risques liés aux configurations par défaut dans les distributions minimales où PAM n'est pas utilisé.

La facilité d'exploitation rend cette faille particulièrement dangereuse. Contrairement aux attaques par force brute qui génèrent du bruit et peuvent être bloquées par fail2ban, cette méthode ne nécessite qu'un seul paquet et ne laisse aucune trace immédiate de tentatives échouées. Si un attaquant accède à une instance cloud, il peut rapidement élever ses privilèges et pivoter au sein du réseau. Les équipes doivent vérifier non seulement que les paquets ont été mis à jour, mais aussi que le démon en cours d'exécution a bien été redémarré, car les gestionnaires de paquets ne redémarrent pas toujours les services automatiquement.

Que pouvez-vous faire

• Mettez à jour votre système immédiatement en utilisant apk upgrade -U -a et assurez-vous d'installer la version corrigée pour votre branche.
• Redémarrez explicitement le démon SSH avec rc-service sshd restart après la mise à niveau, car la mise à jour seule ne recharge pas le processus en cours d'exécution.
• Si vous ne pouvez pas mettre à jour immédiatement, désactivez l'authentification par mot de passe en définissant PasswordAuthentication no dans votre configuration SSH et en redémarrant le service.
• Vérifiez votre configuration avec sshd -T | grep -i passwordauthentication pour vous assurer que le changement est actif.
• Auditez vos logs pour repérer les entrées inattendues Accepted password concernant des comptes qui ne devraient pas avoir de mot de passe.
• Passez en revue vos instances cloud pour détecter tout ajout de hachage de mot de passe utilisateur qui aurait pu activer involontairement la vulnérabilité.