Contournement de l'authentification de libssh

Une vulnérabilité existe sur libssh permettant de contourner l’authentification.

Il faut tout de même bien différentier libssh et openssh. Le second est l’outil permettant la prise de contrôle d’un serveur à distance alors que le premier est une librairie apportant les mêmes fonctionnalités mais nécessitant d’être intégrée dans un développement.

Cela ne signifie donc pas que tous les serveurs ayant un accès SSH ouvert sur internet sont vulnérables, heureusement 😊.

Problématique

Lors d’une connexion SSH (avec libssh), le client peut envoyer un message d’authentification réussie, ce qui fait entrer le serveur dans un cas où il fait plus de vérification sur l’état de l’utilisateur car il est maintenu dans un structure « session->auth » dont le paramètre « session->auth.state » est initialisé avec la valeur « SSH_AUTH_STATE_NONE = 0 », non prise en compte dans le traitement. La correction consiste en partie à créer des états intermédiaires des phrases d’authentification comme SSH_AUTH_STATE_PASSWORD_AUTH_SENT et SSH_AUTH_STATE_AUTH_NONE_SENT.

Pour faire simple, lors de l’authentification, les développeurs n’avaient pas prévu de traiter le cas « je dis être authentifié et mon état côté serveur est à 0 ».

Tous les détails du changement corrigeant la vulnérabilité (et donc comment l’exploiter 😉) sont ici :
https://git.libssh.org/projects/libssh.git/commit/?id=2bddafeb709eacc80ad31fec40479f9b628a8bd7 => source de la problématique
https://git.libssh.org/projects/libssh.git/commit/?id=825f4ba96407abe8cebb046a7503fa2bf5de9df6
https://git.libssh.org/projects/libssh.git/commit/?id=20981bf2296202e95d7919394d4610ae3a876cfa
https://git.libssh.org/projects/libssh.git/commit/?id=5d7414467d6dac100a93df761b06de5cd07fc69a
https://git.libssh.org/projects/libssh.git/commit/?id=459868c4a57d2d11cf7835655a8d1a5cf034ccb4
https://git.libssh.org/projects/libssh.git/commit/?id=68b0c7a93448123cc0d6a04d3df40d92a3fd0a67
https://git.libssh.org/projects/libssh.git/commit/?id=75be012b4a14f4550ce6ad3f126e559f44dbde76
https://git.libssh.org/projects/libssh.git/commit/?id=e1548a71bdac73da084174ab1d6d2713edd93f6e

Cas d’usage

Libssh est utilisé principalement pour des services ou scripts accédant à des accès SSH, mais il existe parfois des services utilisant libssh en écoute, afin de traiter des connexions entrantes et c’est là que le risque est présent. Il n’y a finalement pas beaucoup de services utilisant libssh exposés sur internet, comme le montre le site Shodan :
https://www.shodan.io/search?query=Libssh

libssh

Dans tous les cas, il est primordial d’avoir un inventaire de ses accès, de vérifier si la librairie libssh est utilisée puis de mettre à jour, en priorité les composants exposés à des réseaux non sûrs comme internet.

De manière générale, il n'est bien entendu pas du tout recommandé d’exposer des services d’administration sur internet. Le filtrage par IP Source et/ou le VPN sont vos amis 😉.

//MISE A JOUR\

Après quelques jours concernant cette vulnérabilité CVE-2018-10933, je me rends compte que j’ai sous-estimé l’inventivité des développeurs 😱.

F5, RedHat et à priori Cisco ont communiqué sur la problématique en indiquant que certains de leurs produits sont vulnérables.
https://www.zdnet.com/article/vendors-confirm-products-affected-by-libssh-bug-as-poc-code-pops-up-on-github/

Chez F5, ce sont les équipements de répartition de charge Big-IP (oui, c’est une description réductrice de ces solutions 😉) qui sont touchés, mais, à priori, uniquement sur la fonctionnalité de Proxy SSH du module AFM (Advanced Firewall Manager). Très honnêtement, j'ai rarement vu cette fonctionnalité chez des clients.
https://support.f5.com/csp/article/K52868493

Chez Cisco, les produits sont encore en cours d’analyse, en particulier :

  • Cisco Webex Meetings Server
  • Cisco Cloud Services Platform 2100
  • Cisco Content Security Management Appliance (SMA)
  • Cisco Email Security Appliance (ESA)
  • Cisco Identity Services Engine (ISE)
  • Cisco Web Security Appliance (WSA)
  • Cisco Enterprise Service Automation
  • Cisco NetFlow Generation Appliance
  • Cisco Network Analysis Module
  • Cisco Prime Network Registrar Virtual Appliance
  • Cisco WAN Automation Engine (WAE)
  • Cisco Application Policy Infrastructure Controller (APIC)
  • Cisco IP Interoperability and Collaboration System (IPICS)
  • Cisco Management Heartbeat Server
  • Cisco Cloud Object Storage
  • Cisco DCM Series D990x Digital Content Manager
  • Cisco Video Surveillance 4300E and 4500E High-Definition IP Cameras
  • Cisco Wireless LAN Controller
  • Cisco Smart Software Manager Satellite
  • Cisco Virtual HetNet

Le bulletin de sécurité sera mis à jour au fur et à mesure de leurs analyses : https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181019-libssh

Mais les développeurs ayant crée des scripts pour automatiser la détection de la problématique ne sont pas en reste d’inventivité 😉. Par exemple, je suis tombé sur ce superbe script Python : https://github.com/leapsecurity/libssh-scanner

LeapSecurity réalise ici l’exploit de faire 106 lignes quand le test peut se faire avec une simple ligne de commande :

libssh

Bon, je reconnais que je suis très critique et que ce script permet de tester une liste de cibles provenant d’un fichier mais également d’exploiter la vulnérabilité 😉.

Détection

Pour nos SOC-boys and girls, j’ai trouvé un petit article qui décrit comment trouver des services vulnérables avec ELK (et exploité ?) : https://www.marcolancini.it/2018/blog-libssh-auth-bypass/

Remédiation

Le conseil est donc toujours le même : identifier les ressources vulnérables, estimer le risque, définir le plan de remédiation priorisé selon le contexte et l’exposition*, appliquer le plan.