La sécurité du protocole SSH reste insuffisante

Le protocole Secure Shell (SSH) est la colonne vertébrale de l'administration réseau moderne. Il fournit un accès distant crypté à pratiquement tous les serveurs, périphériques réseau et systèmes embarqués dans les environnements d'entreprise. Des routeurs et commutateurs aux systèmes de contrôle industriels et instances cloud, le SSH est devenu la norme de facto pour l'accès sécurisé en ligne de commande à l'ensemble de l'infrastructure. Cette omniprésence rend particulièrement alarmantes les récentes découvertes du chercheur en sécurité HD Moore.

Lors de la conférence DEF CON 33 organisé début août à Las Vegas, une analyse menée par l’entreprise runZero sur l'ensemble de l'Internet et présentée par M. Moore, son fondateur et CEO, a révélé des vulnérabilités persistantes dans les implémentations SSH qui affectent les principaux fournisseurs de réseaux. L’enquête a également identifié des failles de sécurité critiques dans les équipements industriels, les solutions de transfert de fichiers et d'innombrables dispositifs réseau qui constituent la base de la connectivité des entreprises. « Si l’on regarde l’Internet, le SSH est, après http, le deuxième protocole d'administration le plus courant exposé », a déclaré M. Moore.

Encore des vulnérabilités critiques dans les implémentations

Au cours de l'année écoulée, plusieurs vulnérabilités SSH à fort impact ont été découvertes, preuve évidente, selon M. Moore, de l'évolution du paysage des menaces pesant sur ce protocole. L'attaque Terrapin (CVE-2023-48795) a montré comment les pirates pouvaient manipuler les sessions TCP pour forcer la sélection d'algorithmes cryptographiques plus faibles, compromettant potentiellement l'intégrité des sessions sur toutes les implémentations SSH affectées. La porte dérobée XZ Utils (CVE-2024-3094) a peut-être été l'attaque de supply chain la plus sophistiquée visant l'infrastructure SSH. M. Moore a expliqué que le pirate avait passé des années à gagner la confiance de la communauté open source avant d'insérer une porte dérobée spécialement conçue pour compromettre le SSH via l'intégration de systemd.

La faille RegreSSHion (CVE-2024-6387) s'est avérée particulièrement dangereuse, entraînantl'exécution de code à distance non authentifiée via une vulnérabilité de réentrée de signal dans OpenSSH. Elle a affecté d'innombrables systèmes Linux et appareils réseau exécutant des versions vulnérables d'OpenSSH, même si son exploitation s’est avérée difficile en raison des protections de mémoire modernes. La vulnérabilité MOVEit (CVE-2024-5806) a démontré comment les bibliothèques SSH tierces pouvaient introduire des vecteurs d'attaque inattendus. Dans ce cas, la bibliothèque IPWorks SSH traitait les données d'authentification par clé publique comme des chemins d'accès à des fichiers, permettant ainsi de contourner l'authentification.

Une exposition persistante sur Internet des serveurs SSH

Il est déjà suffisamment grave que de nombreux problèmes liés au protocole SSH aient été rendus publics. Ce qui rend la situation encore plus préoccupante, c'est le nombre important de serveurs SSH ouverts à l'Internet public. L'analyse exhaustive de l'espace IPv4 réalisée par le chercheur a révélé des tendances significatives en matière d'exposition SSH. L'étude a recensé environ 22 millions d'adresses avec le port réseau 22 ouvert utilisé par défaut pour le SSH, contre 27 millions en 2024. Sur ces 22 millions, l'analyse a permis d'atteindre une étape d'authentification SSH sur 15,4 millions de terminaux.

Les données ont montré des tendances préoccupantes dans la diversité des implémentations. Alors qu'OpenSSH et Dropbear représentent environ 98 % des implémentations SSH, les 2 % restants sont constitués de dispositifs embarqués, d'équipements réseau et d'applications spécialisées qui contiennent souvent des vulnérabilités. Ces implémentations non standard apparaissent fréquemment dans des composants d'infrastructures critiques, notamment les systèmes de contrôle industriels, les équipements réseau et les solutions de transfert de fichiers.

Une adoption des correctifs encore extrêmement faible

L'une des conclusions les plus préoccupantes concerne le taux d'adoption des améliorations de sécurité. La version 9.8 OpenSSH a introduit PerSourcePenalties, une fonctionnalité de limitation de débit par défaut capable d’atténuer divers vecteurs d'attaque. Cependant, les recherches de M. Moore ont révélé un déploiement minimal dans le monde réel. Selon les recherches de M. Moore, sur les quelque 20 millions de serveurs OpenSSH exposés, moins de 500 000 fonctionnent sous la version 9.8 ou une version plus récente. Les statistiques sont plus élevées sur les réseaux d'entreprise, mais selon lui, il reste un long chemin à parcourir pour l’adoption de la version moderne d'OpenSSH. Ainsi, parmi les serveurs SSH connectés à Internet, moins de 2,5 % ont adopté la version sécurisée. Le chercheur estime aussi que la situation est pire avec les implémentations Dropbear, car ce démon SSH ne dispose pas de protections similaires de limitation de débit.

Les mécanismes d'authentification deviennent des cibles

Au cours de ses recherches, l'équipe de M. Moore a découvert plusieurs techniques de contournement de l'authentification, mais ils n’ont partagé aucun détail spécifique pendant leur présentation. Leur recherche a mis en évidence diverses méthodes pour contourner l'authentification SSH, notamment la manipulation des listes de méthodes d'authentification, les vulnérabilités des tests de clés publiques et les attaques par transition d'état pré-authentification. La principale technologie utilisée par l'équipe de M. Moore est l'outil open source SSHamble développé par l'entreprise runZero elle-même.

Recommandations pour les équipes de sécurité réseau

Même si l'état actuel de la sécurité SSH sur l'Internet ouvert est très insuffisant, les entreprises peuvent prendre certaines mesures pour réduire les risques et renforcer la sécurité. Au cours de la présentation, M. Moore a énoncé un certain nombre de recommandations, notamment :

**-**Mettre en œuvre une gestion agressive des correctifs pour les implémentations SSH, en mettant particulièrement l'accent sur OpenSSH 9.8 ou les versions plus récentes qui incluent des protections de limitation de débit. Compte tenu des faibles taux d'adoption observés dans les recherches de M. Moore, les entreprises qui maintiennent les niveaux de correctifs actuels réduiront considérablement leur surface d'attaque.

-Réaliser un inventaire SSH complet sur tous les segments du réseau, y compris les appareils intégrés, les équipements réseau et les systèmes industriels qui peuvent exécuter des implémentations SSH non standard. Les entreprises sont souvent moins attentives à la sécurité de ces systèmes alors qu’ils représentent des vecteurs de risque importants.

-Déployer une surveillance du réseau pour détecter les attaques basées sur SSH et les activités de reconnaissance. Les recherches de M. Moore montrent que les attaquants peuvent rapidement répertorier les systèmes vulnérables, ce qui rend la détection précoce cruciale pour répondre aux incidents.

**-**Supprimer l'authentification par mot de passe au profit d'une authentification par clé avec une gestion appropriée des clés. Les entreprises doivent régulièrement vérifier si les clés SSH ont été compromises à l'aide d'outils comme BadKeys.info et mettre en œuvre des politiques de rotation des clés.

**-**Surveiller la réutilisation des clés hôtes SSH sur l'ensemble des systèmes, car les clés en double peuvent indiquer une exposition involontaire à Internet ou une compromission. Les techniques de détection de l'intérieur vers l'extérieur présentées dans les recherches de M. Moore fournissent un modèle pour ce type d'évaluation.

**-**Mettre en œuvre une segmentation du réseau afin de limiter l'accès SSH aux réseaux d’administration et d'exiger un accès VPN ou via un hôte bastion pour l'administration à distance. Cette segmentation réduit la surface d'attaque pour la reconnaissance et l'exploitation SSH basées sur Internet.