Q : Quel est le protocole d’accès à distance le plus répandu, la technologie la plus fréquemment utilisée pour accéder aux serveurs situés dans une autre pièce, bureau, ville, région ou pays ?
N’importe quel sysadmin vous répondrait …
R : SSH.
SSH est l’abréviation de Secure Shell, et il est très utilisé non seulement pour se connecter à un shell distant (jargon pour une invite de commande dans une fenêtre au niveau d’un terminal), mais aussi pour créer des tunnels sécurisés (jargon pour désigner des circuits réseau chiffrés que vous pouvez utiliser pour protéger à peu près n’importe quelle communication réseau vis à vis de regards indiscrets).
Les tunnels sécurisés constituent un moyen efficace d’assurer la sécurité des mises à jour logicielles inter-réseaux, des téléchargements de fichiers, des sauvegardes de données, des logs système et bien plus encore.
Q : Quel est le serveur SSH le plus répandu ? L’application utilisée à l’heure actuelle pour gérer les connexions SSH en premier lieu ?
N’importe quel sysadmin vous répondrait…
R : OpenSSH.
Le logiciel OpenSSH est issu du projet de système d’exploitation ultra-sécurisé OpenBSD, le système d’exploitation “gratuit, fonctionnel et sécurisé” qui se vante sur son site web d’avoir “deux failles distantes dans l’installation par défaut, et ce depuis une éternité !”.
Comparé à la distro Linux moyenne, ou à Windows, ou MacOS, ou à peu près à tous les téléphones portables qui méritent d’être mentionnés, il ne s’agit pas d’une déclaration qui passe inaperçu, même si ce n’est pas le genre d’argument qu’un service marketing traditionnel mettrait volontiers en avant !
Quelles conséquences en cas de défaillance du SSH ?
Nous avons rencontré des sysadmins qui vivent avec une épée de Damoclès en permanence au-dessus de leur tête, inquiets chaque nuit de se réveiller le lendemain avec l’annonce d’un nouvel exploit d’exécution de code à distance SSH, ou d’une faille cryptographique longtemps négligée qui permettrait à quiconque de se connecter depuis n’importe où.
Ce genre de bug, selon eux, ne serait pas de type Heartbleed, mais plutôt de type “crise cardiaque” !
Donc, quand nous avons vu les gros titres aujourd’hui annonçant une vulnérabilité SSH “affectant toutes les versions OpenSSH“, nous avons pensé qu’il valait mieux y jeter un coup d’œil !
En fait, le bug affecte à priori toutes les versions OpenSSH depuis au moins 2000, nous avons donc eu une certaine appréhension à l’idée que cela puisse enfin être The Big One, à savoir un infarctus cryptographique collectif, pour le dire crûment !
La mauvaise nouvelle est que ces gros titres disent la vérité. La bonne nouvelle est qu’il s’agit que de gros titres et qu’ils omettent soigneusement les détails, qui prouveraient clairement qu’il ne s’agit de rien de grave.
Ironiquement, la vulnérabilité n’était qu’un bug quand elle a été corrigée, des chercheurs polonais l’ont signalé à l’équipe OpenSSH à la mi-juillet 2018.
Le bug était répertorié comme suit : “Retarder le rejet d’un utilisateur suite à authentification invalide jusqu’à ce que le paquet contenant la requête ait été entièrement analysé”.
NB : Le ok deraadt dans l’image ci-dessus est une note du chef d’OpenBSD, Theo de Raadt, pour approuver le changement.
Ce n’est qu’après que le bug ait été corrigé dans l’arborescence du code qu’il s’est transformé en vulnérabilité.
Les experts en sécurité qui ont parcouru la liste récente des modifications au niveau du code (connues sous le nom de diffs dans le jargon, après le programme diff utilisé pour afficher les différences entre deux versions d’un fichier) ont exigé que cette modification obtienne un numéro de vulnérabilité officiel…
… car cela signifiait que les anciennes versions OpenSSH présentaient une faille d’énumération des utilisateurs (ce bug est maintenant officiellement désigné par CVE-2018-15473).
Une faille d’énumération d’un utilisateur permet à un système de vous reconnaitre, en considérant que le nom d’utilisateur est valide, et ce sans vous connecter au préalable.
En essayant de vous connecter à OpenSSH en utilisant un paquet réseau délibérément mal structuré, vous vous attendez à recevoir un message d’erreur, mais jusqu’à ce que ce code change, OpenSSH va revenir vers vous plus rapidement si le nom d’utilisateur est invalide que si ce dernier est authentique.
Techniquement, cela n’est pas censé se produire. En fait, depuis des décennies, et bien avant 2000, une école de pensée considérait que l’on devait toujours afficher le nom d’utilisateur et le mot de passe sous la forme d’une paire inséparable, et ne jamais dire à l’utilisateur lequel était incorrect en cas d’échec de connexion.
Vous êtes censé dire “nom d’utilisateur et/ou mot de passe invalide”, ou simplement “Pas de chance, recommencez depuis le début”, en traitant à la fois le nom d’utilisateur et le mot de passe comme des données secrètes.
Les noms d’utilisateur doivent-ils rester secrets ?
Nous acceptons que cette modification OpenSSH soit une amélioration du code, et nous ne voyons aucune raison au quotidien pour donner des informations sur les noms d’utilisateur si cela n’est pas nécessaire.
Mais nous ne sommes pas sûrs de la nécessité de traiter les noms d’utilisateurs comme des données aussi précieuses qu’elles l’ont été par le passé.
Au moment où vous ne pouviez pas choisir votre propre identifiant et que vous receviez des noms d’utilisateur générés par une machine, comme duck21994, votre nom d’utilisateur comportait au moins une forme d’imprévisibilité.
À une époque où 8 lettres minuscules constituaient un super mot de passe sécurisé et que les utilisateurs étaient heureux de pouvoir choisir un mot de passe et l’utiliser partout, il était probablement judicieux de traiter ces cinq chiffres étranges à la fin de votre nom d’utilisateur comme un obstacle supplémentaire à contourner pour des cybercriminels.
Cette époque est néanmoins révolue !
De nombreux sites grand public modifient leur workflow de connexion de sorte à commencer avec votre nom d’utilisateur, et seulement s’il existe dans le système alors vous êtes invité à fournir votre mot de passe.
De même, les systèmes avec deux mots de passe, à savoir un code statique et un code d’authentification à deux facteurs (2FA), confirment souvent votre nom d’utilisateur et votre mot de passe avant de demander un code 2FA.
Dans tous les cas, votre nom d’utilisateur n’est plus vraiment un secret, car il s’agit souvent de votre adresse email, et cette dernière, en particulier celle de votre entreprise, est probablement construite de manière prévisible.
Après tout, il est un peu idiot d’avoir une adresse email pour permettre de vous contacter facilement, mais qui s’avère difficile à mémoriser ou à utiliser sans se tromper !
Quoi faire ?
Ne vous méprenez pas, moins vous donnerez d’informations sur votre système durant la phase d’authentification, mieux vous vous porterez !
Il s’agit donc clairement d’un correctif de code qui mérite d’être considéré, et ce changement est à la fois utile et souhaitable.
Si vous êtes inquiet, vous pouvez facilement appliquer le correctif vous-même et reconstruire vos propres copies OpenSSH.
Mais ne vous attardez pas trop sur la nécessité d’avoir des noms d’utilisateur les plus secrets possible.
Cela revient à considérer que la serrure de votre porte sera plus difficile à forcer si vous masquez le nom du fabricant, et ce même si la serrure elle-même et ses composants internes sont exactement les mêmes.
NB : Si l’escroc a déjà ce qu’il pense être la clé, il tentera sa chance de toutes les façons, si la serrure s’ouvre, il ne se souciera pas de savoir si c’est un verrou à cylindre, à levier ou un autre type de serrure plus exotique).
De même, si vos connexions SSH dépendent de la confidentialité de vos noms d’utilisateur pour leur sécurité, nous pensons que votre approche est mauvaise et que vous devriez la changer !
Billet inspiré de Vulnerability in OpenSSH “for two decades” (no, the sky isn’t falling!), sur Sophos nakedsecurity.
