Une faille permettait d’accéder à certains serveurs Alpine Linux avec un faux mot de passe

Un administrateur utilise une clé numérique pour se connecter à son serveur à distance. Aucun mot de passe n’a été défini pour son compte. Pourtant, dans certaines configurations d’Alpine Linux, un intrus pouvait ouvrir une session sans posséder cette clé. Il lui suffisait de pouvoir joindre le service de connexion à distance, appelé SSH, et de connaître le nom du compte visé. Comment le serveur pouvait-il accepter un mot de passe qui n’existait pas ?

Un astérisque, deux significations

Pour vérifier un mot de passe, le serveur calcule normalement son empreinte, une valeur qu’il compare à celle enregistrée pour le compte. Sur les machines concernées, certains comptes sans mot de passe portaient à la place un simple astérisque (*). Ce signe indiquait qu’aucun mot de passe ne devait permettre d’ouvrir la session.

Or, lorsqu’on lui soumettait une valeur de plus de 256 octets, le composant chargé du calcul renvoyait lui aussi un astérisque, cette fois pour signaler une erreur. Le serveur comparait les deux signes et acceptait la connexion. Aucun mot de passe n’avait été deviné : le logiciel avait pris un échec de vérification pour une vérification réussie.

Qui était réellement exposé ?

La faille exigeait plusieurs conditions à la fois. Le serveur SSH devait accepter les connexions par mot de passe et effectuer lui-même leur vérification, sans la déléguer au module appelé PAM. Il fallait aussi un compte marqué d’un astérisque et au moins un autre compte local dont le mot de passe était enregistré avec l’un des deux formats concernés, SHA-256 ou SHA-512. Un conteneur Docker utilisant Alpine sans faire tourner de serveur SSH n’était donc pas exposé à cette faille.

Le bon réflexe Dav’Filtr

Pour les administrateurs concernés, deux gestes sont nécessaires : mettre à jour OpenSSH, puis redémarrer le service sshd. Sans ce redémarrage, l’ancienne version continue d’accepter les connexions. Si la mise à jour doit attendre, Alpine recommande de désactiver temporairement les connexions SSH par mot de passe et de redémarrer le service, après avoir vérifié que l’accès par clé fonctionne. Sur une machine qui a été exposée, une connexion par mot de passe enregistrée pour un compte censé n’en avoir aucun mérite une enquête.

Pour les lecteurs, la leçon est simple : gardez vos mots de passe longs. Le défaut se trouvait dans la façon dont certains serveurs traitaient une erreur. Raccourcir son mot de passe n’aurait pas corrigé le problème.