Une nouvelle vulnérabilité de libSSH donne un accès root aux serveurs

Depuis près de 5 ans, la librairie libSSH est affectée par une vulnérabilité susceptible de donner de manière triviale à des attaquants un accès doté des plus hauts droits d’administration aux serveurs concernés.

Peter Winter-Smith, consultant en sécurité chez NCC Group, a découvert cette vulnérabilité de contournement de l'authentification (CVE-2018-10933) dans libSSH – une bibliothèque utilisée pour implémenter le protocole SSH dans les applications client et serveur – et l'a révélé à l'équipe projet fin juin. Le correctif a été développé à la mi-septembre et une mise à jour est disponible depuis le 16 octobre.

Sur Twitter, Peter Winter-Smith explique l’origine de la vulnérabilité : « le serveur et le client libSSH partagent un automate à états, de sorte que les paquets conçus uniquement pour être traités par le client et pour mettre à jour son état puissent mettre à jour l'état du serveur ». Dans la pratique, l'attaque la plus triviale consiste en un contournement du processus d’authentification, mais « toute la machine à états est défectueuse et il peut y avoir d'autres méthodes d'exploitation, plus subtiles ».

Will Dormann, analyste de vulnérabilités chez CERT/CC, a noté que GitHub utilise libSSH en mode serveur. Mais GitHub a précisé que son environnement n'est pas affecté par la vulnérabilité libSSH, du fait de la configuration retenue.

We use a custom version of libssh; SSH2_MSG_USERAUTH_SUCCESS with libssh server is not relied upon for pubkey-based auth, which is what we use the library for. Patches have been applied out of an abundance of caution, but GHE was never vulnerable to CVE-2018-10933.

— GitHub Security (@GitHubSecurity) October 17, 2018

Cette vulnérabilité a été introduite avec la version 0.6 de libSSH, publiée le 8 janvier 2014. Selon Amit Serper (responsable de la recherche en sécurité, Cybereason), il faut compter avec plus de 6 000 équipements exposés sur Internet et susceptibles d’être compromis, selon un inventaire réalisé avec le moteur de recherche spécialisé Shodan. Au programme, des imprimantes, routeurs, modems et autres systèmes de stockage en réseau. Mais dans la pratique, détecter une intrusion dans un serveur SSH concerné peut s’avérer chronophage.

Amit Serper suggère ainsi plusieurs pistes : se connecter à son périphérique via SSH et observer les sessions ouvertes ; consulter la liste des processus actifs et en chercher des « bizarres »… ou encore surveiller le trafic réseau sur le port utilisé par SSH.

A ce stade, Peter Winter-Smith recommande de mettre à jour libSSH en version 0.7.6 ou ultérieure. Et lorsque cela n’est pas possible, Amit Serper n’exclue pas l’option consistant à désactiver purement et simplement le service SSH. Enfin, lorsque même cela est impossible, « il est parfois possible de rediriger le port SSH vers une IP inutilisée du réseau local ».

Parallèlement, F5 a indiqué que certaines versions de son module AFM pour la plateforme Big-IP sont affectées : 12.1 à 12.1.3, 13.0 à 13.1.1, et 14.0.0. C’est le composant proxy SSH qui est concerné et aucun correctif n’est disponible à l’heure où sont publiées ces lignes. L’équipementier recommande en attendant d’utiliser l’authentification interactive par clavier et mot de passe au lieu de l’authentification par clé publique.