Un compte destiné à l’accès par clé SSH pouvait tout de même laisser un attaquant entrer via sa connexion par mot de passe.
Cette contradiction est au cœur de SSHole, une vulnérabilité OpenSSH récemment découverte qui permet à des attaquants de contourner l’authentification sur certains systèmes Linux sans connaître le mot de passe de la victime ni disposer de sa clé privée SSH.
La faille exploite une interaction inattendue entre OpenSSH et musl, une bibliothèque C standard légère utilisée par Alpine Linux, transformant l’échec d’une opération de hachage du mot de passe en connexion réussie.
Ars Technica rapporte que l’image de base Alpine sur Docker Hub a dépassé le milliard de téléchargements. Ce chiffre ne permet pas d’établir combien de systèmes sont vulnérables ; l’exploitation nécessite une combinaison précise de logiciels, de paramètres et de configurations de comptes.
OpenSSH a publié un correctif, mais les administrateurs doivent l’installer et redémarrer le service SSH. Les systèmes soumis à des fenêtres de maintenance limitées peuvent nécessiter une mesure d’atténuation immédiate, le temps que les équipes organisent la mise à jour.
Ce qui est nécessaire pour mener à bien une exploitation de SSHole
La réussite de l’exploitation nécessite une combinaison précise de logiciels, de paramètres d’authentification et de configurations de comptes.
Tout d’abord, la cible doit exécuter OpenSSH avec musl libc, sans que des modules d’authentification enfichables (PAM) ne prennent en charge l’authentification. L’authentification SSH par mot de passe doit également être activée, afin de permettre aux attaquants de soumettre des mots de passe via le mécanisme d’authentification concerné.
L’exploitation nécessite également deux conditions liées aux comptes :
- Le champ du mot de passe du compte cible dans /etc/shadow doit contenir un astérisque (*), indiquant que l’authentification ordinaire par mot de passe doit être désactivée.
- Un autre compte local doit posséder un hachage de mot de passe SHA-256 ou SHA-512 utilisable, dont OpenSSH peut emprunter le sel lors de la vérification.
Selon Alpine, un attaquant qui connaît le nom d’utilisateur du compte concerné et peut accéder au service SSH peut exploiter un système réunissant ces conditions. Il peut ensuite soumettre un mot de passe de 257 à 1 024 octets.
La fonction de musl crypt() rejetterait normalement l’entrée, car celle-ci dépasse la limite de 256 octets de la bibliothèque. Cependant, au lieu de renvoyer un hachage de mot de passe valide, la fonction renvoie un astérisque (*) pour signaler l’échec du hachage.
OpenSSH compare alors ce résultat au champ de mot de passe enregistré du compte cible, qui contient lui aussi un astérisque. Les deux valeurs correspondent, et OpenSSH interprète à tort l’échec de l’opération de hachage comme une authentification réussie, accordant à l’attaquant l’accès au compte sans son mot de passe ni sa clé privée SSH.
Comment des comportements logiciels anciens ont créé un contournement de connexion
Le plus inquiétant avec SSHole n’est peut-être pas seulement qu’il permet aux attaquants de contourner l’authentification, mais aussi la durée pendant laquelle les conditions qui l’ont rendu possible sont passées inaperçues.
La vulnérabilité découle de comportements logiciels qui remontent à plusieurs années. Autrement dit, les composants pris individuellement se comportaient comme prévu, mais leur interaction a produit une faille de sécurité restée invisible pendant des années.
La réponse PHP2Shell souligne également pourquoi les équipes de sécurité doivent vérifier les correctifs en cours d’exécution et enquêter sur les accès antérieurs. Parallèlement, les services proposant des analyses de vulnérabilités assistées par l’IA intensifient leurs efforts pour détecter les failles négligées.
Pour les équipes de sécurité, la leçon pratique consiste à tester la manière dont les composants d’authentification interagissent, y compris les chemins d’échec que les vérifications de connexion courantes peuvent manquer.
Depuis des années, les évaluations de sécurité, les revues de code et les tests d’intrusion aident les organisations à identifier les faiblesses, mais ils ne peuvent pas garantir d’avoir découvert tous les échecs possibles. Les avancées récentes de la recherche de vulnérabilités assistée par l’IA rendent cette limite plus difficile à ignorer, car des failles ayant résisté à des années d’examen sont désormais étudiées de manière à révéler des chemins d’exploitation jusque-là négligés.
Les services SSH accessibles depuis Internet méritent une attention particulière, car les attaquants peuvent les atteindre à distance.
Comme l’explique Jake Knott, responsable du renseignement sur les menaces chez watchTowr, « SSH est présent à peu près partout et est souvent exposé publiquement pour l’administration des serveurs, mais les prérequis signifient que de nombreux systèmes ne seront pas concernés. »
Ces exigences fournissent néanmoins aux attaquants des configurations identifiables à rechercher. Knott cite « les images Alpine pour AWS et Azure » comme étant « probablement les premières que nous verrons ciblées ». Alpine précise que les images tiny-cloud concernées sont sûres au premier démarrage, mais deviennent exploitables lorsqu’un hachage de mot de passe répondant aux critères y est ajouté.
L’exploitation active de failles SSH distinctes de MikroTik illustre les risques auxquels sont exposés les services d’administration accessibles. Knott a averti que les opérations existantes de devinette de mots de passe pourraient également intégrer des tentatives SSHole. Comme l’explique Knott, « exploiter cette vulnérabilité signifie simplement que ces mêmes attaquants ajoutent une tentative avec un mot de passe très long à leur liste de force brute. »
« Nous serions extrêmement surpris de ne pas voir les attaquants qui testent des mots de passe par force brute sur SSH essayer cette méthode d’ici le week-end. La tentative ne coûte pratiquement rien et peut rapporter facilement si elle fonctionne », a-t-il ajouté.
Corriger le service et enquêter sur les accès antérieurs
OpenSSH a publié la version 10.6p2 le 5 novembre pour corriger le contournement. Alpine fournit également des paquets corrigés pour les anciennes branches ; les administrateurs doivent donc consulter l’avis de sécurité de leur distribution plutôt que de se fier uniquement au numéro de version en amont.
Les équipes de sécurité doivent donner la priorité à trois étapes :
- Confirmer l’exposition : vérifier si le système utilise musl, si l’authentification par mot de passe est activée, si PAM ne prend pas en charge l’authentification et si les conditions requises pour les comptes sont réunies.
- Appliquer le correctif : installer le paquet corrigé approprié et redémarrer sshd. La mise à jour du paquet seule ne remplace pas le démon en cours d’exécution.
- Atténuer le risque si nécessaire : vérifier d’abord que l’accès par clé SSH fonctionne. Définir ensuite PasswordAuthentication no, valider la configuration et redémarrer sshd. Conserver la session d’administration existante ouverte jusqu’à la réussite d’une nouvelle connexion par clé.
Examinez également l’activité antérieure. Alpine recommande de vérifier /var/log/messages pour y rechercher des connexions réussies par mot de passe à des comptes qui n’en possèdent pas. Enquêtez sur toute élévation de privilèges inattendue, les utilisateurs nouvellement créés et les modifications apportées aux clés autorisées.
Une mise à jour réussie corrige ce contournement de l’authentification ; elle ne permet pas d’établir si des attaquants ont accédé auparavant au système. Toute connexion suspecte doit déclencher une enquête sur l’incident.
La leçon plus générale est de vérifier la politique d’authentification réellement appliquée sur le serveur. L’utilisation de clés SSH ne désactive pas automatiquement la connexion par mot de passe, et un compte destiné à un accès par clé peut rester exposé via une autre méthode activée.
En savoir plus : découvrez comment détecter et supprimer le logiciel malveillant CWPdoor, notamment les signes avant-coureurs et les étapes de récupération que les administrateurs de serveurs Linux doivent vérifier.