Bug SSH sérieux : des cybercriminels capables de se connecter… juste en le demandant gentiment !

Le gros bug du moment qui fait peur s’appelle CVE-2018-10933.

En fait, il s’agit d’une faille de sécurité assez grave, voire même très grave, au niveau d’une bibliothèque de logiciels libres appelée libssh.

La faille est plus que sérieuse, elle fait même peur, car elle permet théoriquement à quiconque de se connecter à un serveur protégé, via libssh, et ce sans avoir à entrer de mot de passe.

C’est effrayant, car ssh, ou SSH comme il est souvent écrit, est probablement le protocole d’accès distant le plus largement déployé dans le monde.

Presque tous les serveurs Unix et Linux utilisent SSH pour l’administration à distance, et il existe, de par le monde, beaucoup d’énormes fermes de serveurs, rendant ainsi l’utilisation de SSH assez massive.

SSH signifie Secure Shell, où le terme shell désigne, dans langage Unix, une invite de commande, à savoir l’endroit où la plupart des fonctions d’administration système de type Unix sont exécutées, que ce soit manuellement via un utilisateur connecté, ou automatiquement via un script de connexion.

Mais le SSH est utilisé pour bien d’autres choses que les seules connexions au shell, car il crée ce que l’on appelle souvent un tunnel sécurisé, un canal de données chiffré, à usage général, entre deux ordinateurs sur internet.

Les utilisations bien connues du SSH incluent le transfert de fichiers sécurisé entre serveurs et la synchronisation de données sécurisée entre centres de données.

Les failles de sécurité dans le SSH sont donc source de cauchemars pour de nombreux administrateurs système, et ce bug SSH a certainement affolé les fils de presse spécialisée en sécurité.

La bonne nouvelle

Voici la bonne nouvelle.

De loin la version SSH la plus couramment utilisée est un produit open source appelé OpenSSH, créé et maintenu par des personnes soucieuses de la sécurité chez OpenBSD.

OpenSSH est une implémentation complètement distincte de libssh, elles n’intègrent pas et n’utilisent pas le code de l’autre.

Dropbear (une version simplifiée couramment utilisée sur les routeurs et autres périphériques IoT), libssh2 (un produit différent de libssh, et pas uniquement la version la plus récente) et PuTTY (largement utilisé sous Windows) sont d’autres implémentations open source bien connues de SSH.

Aucun de ces projets ne contient ce bug SSH, donc la plupart d’entre nous peuvent se détendre et quitter la zone rouge !

Le seul projet vraiment majeur que nous connaissons, et qui utilise libssh comme serveur SSH, est le référentiel de code source GitHub de Microsoft.

Et la bonne nouvelle, c’est que le projet GitHub [a] n’appelle pas le code buggé dans le produit libssh et [b] a tout de même installé le correctif, histoire de rassurer tout le monde.

Un autre outil logiciel, cCURL, très largement utilisé, prend en charge libssh : un outil de transfert de données web, en ligne de commande, fourni avec tous les Mac, et inclus dans presque toutes les distributions Linux et largement utilisé pour automatiser les uploads et les téléchargements au niveau des appareils IoT.

Mais cURL n’inclut pas SSH par défaut et n’est généralement pas utilisé sur les serveurs pour traiter les connexions entrantes. De toutes les façons, cURL utilise libssh2 comme premier choix si vous avez besoin d’une prise en charge de SSH.

La mauvaise nouvelle

La mauvaise nouvelle est que tout serveur qui écoute les connexions SSH entrantes, à l’aide de libssh, court un risque considérable au niveau d’accès non autorisé.

Le bug SSH est mauvais, à en avoir un fou rire nerveux. De manière simplifiée, il fonctionne comme ceci.

Lors de la connexion, le client est censé dialoguer avec le serveur via les lignes ci-dessous …

   Client → Server: HELLO-I-WOULD-LIKE-TO-START-AUTHENTICATING

   Client and server:  [...une danse cryptographique a lieu entre 
les 2 parties afin de vérifier les identifiants...]
   Server → Client: WELCOME-YOU-HAVE-PASSED-THE-TEST

… Et les deux parties peuvent alors commencer à échanger des données.

Mais ce bug SSH signifie qu’un client peut simplement parler à un serveur libssh comme ceci …

   Client → Server: WELCOME-YOU-HAVE-PASSED-THE-TEST

… Et les deux parties peuvent alors commencer à échanger des données.

En d’autres termes, si le client indique au serveur que l’authentification est terminée, et non l’inverse, le serveur le croit sans sourciller.

Aucun mot de passe n’est demandé ou requis.

Quoi faire ?

• Si vous utilisez un logiciel qui inclut ou utilise libssh, téléchargez et installez immédiatement la dernière version de libssh.
• Si vous utilisez un produit avec libssh intégré, plutôt que fourni sous forme de bibliothèque partagée ou de DLL, vous aurez besoin d’une version mise à jour de l’application elle-même.
• En cas de doute, consultez la documentation du produit ou la communauté en ligne.

Pour plus d’informations, visionnez notre vidéo présentant le problème et les mesures à prendre :

Billet inspiré de Serious SSH bug lets crooks log in just by asking nicely…, sur Sophos nakedsecurity.