Conseils sur la vulnérabilité critique d'OpenSSH, regreSSHion
Synthèse
La vulnérabilité critique CVE-2024-6387 provient d'une exécution de code à distance (RCE) dans OpenSSH qui découle d'une régression de CVE datant de 2006.
Pour l'exploiter, le système doit remporter une épreuve d'endurance, car son exploitation peut prendre des heures, voire des semaines.
La procédure à suivre consiste à mettre en place un correctif vers une version non affectée du serveur OpenSSH sur les systèmes Linux basés sur la glibc. Pour les circonstances dans lesquelles cela n'est pas faisable, nous avons inclus d'autres options d'atténuation pour réduire l'impact potentiel.
osquery est également disponible pour détecter les versions vulnérables d'OpenSSH.
Contexte de vulnérabilité d'OpenSSH et analyse technique
Une nouvelle vulnérabilité critique (CVE-2024-6387) dans OpenSSH a récemment été découverte par l'équipe Threat Research Unit de Qualys qui pourrait conduire à une RCE non authentifiée. Le 1er juillet 2024, l'équipe a publié ses trouvailles à propos de la régression de la vulnérabilité, CVE-2006-5051, qui a été corrigée en 2006 et est réapparue en 2021.
La cause première de ce problème est une situation de conflit provoquée par un traitement non sécurisé des signaux lorsque le délai d'authentification de l'utilisateur expire. Lors de l'expiration du délai, l'émission d'un signal SIGALRM provoque une interruption d'un fil d'exécution qui exécute une routine de gestion de tas. Si le gestionnaire de signaux appelle la routine de gestion de tas, il peut engendrer un comportement inattendu et, dans ce cas, exécuter du code arbitraire.
Actuellement, il existe une démonstration de faisabilité publique (PoC) qui exploite cette vulnérabilité, elle est donc connue (cette PoC est proposée par un tiers non affilié à Akamai, veuillez donc effectuer vos propres vérifications préalables avant de tenter toute interaction avec le code). Malgré sa gravité, la PoC met en évidence certaines limites pour une exploitation réussie. Le temps nécessaire à l'exploitation est l'une des principales limitations. En effet, sur certains systèmes, l'exploitation peut prendre plusieurs heures, tandis que sur d'autres, elle peut durer jusqu'à une semaine. D'autres limites sont liées à la distribution du système d'exploitation ainsi qu'à la version et à la configuration du serveur OpenSSH.
Qui est vulnérable ?
Cette vulnérabilité affecte de nombreuses versions d'OpenSSH, y compris la plupart des distributions Linux, car elles sont livrées avec OpenSSH par défaut.
Comme la cause première de la vulnérabilité est une régression dans le code OpenSSH, les versions du serveur OpenSSH très anciennes sont affectées par la CVE originale, mais les versions plus récentes (avant la régression) ne sont pas affectées.
À la date de publication de cet article, les versions connues d'OpenSSH affectées par cette vulnérabilité sont les suivantes :
L'ancienne version de la vulnérabilité (CVE-2006-5051) affecte les versions d'OpenSSH antérieures à OpenSSH 4.4/4.4p1 (2006-09-27) [sauf si elles sont corrigées pour CVE-2006-5051 et CVE-2008-4109]
La régression de la vulnérabilité a été introduite dans la version 8.5/8.5 p 1 d'OpenSSH (2021-03-03)
Les administrateurs d'OpenSSH ont corrigé la vulnérabilité dans la version 9.8/9.8 p 1 d'OpenSSH (2024-07-01)
Vous pouvez rechercher les serveurs affectés en utilisant la requête Insight suivante :
SELECT
name AS vulnerable_item,
'DEB' AS type,
version,
CAST(SUBSTR(version, 3, 3) AS REAL) AS version_to_compare,
source,
arch,
revision,
maintainer AS vendor
FROM deb_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
UNION
SELECT
name AS vulnerable_item,
'RPM' AS type,
version,
CAST(SUBSTR(version, 1, 3) AS REAL) AS version_to_compare,
source,
arch,
release AS revision,
vendor
FROM rpm_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
D'après nos observations, 75 % des réseaux possédaient des machines avec une version vulnérable d'OpenSSH, et, en moyenne, environ 35 % des machines d'un réseau donné étaient vulnérables. En revanche, en ce qui concerne nos environnements surveillés, nous n'avons encore jamais rencontré de machine dont le port SSH était arbitrairement ouvert sur Internet. Pourtant, une recherche rapide sur Shodan montre que plus de 6 millions de machines accessibles sont dotées d'une version vulnérable (Image).
Rapport Shodan du 2 juillet 2024, pour les machines vulnérables ouvertes à Internet
Impact potentiel
La vulnérabilité affecte OpenSSH par défaut, l'impact potentiel est donc énorme et concerne la plupart des distributions Linux, en particulier les versions les plus récentes en raison de la régression.
Cependant, trois mises en garde permettent de ne pas céder à la panique totale :
Le PoC actuel ne concerne que les machines x86, car l'exploitation sur les machines amd64 (qui sont la norme aujourd'hui) est exponentiellement plus complexe en raison de protections plus fortes de la mémoire.
Actuellement, on considère qu'une exploitation réussie nécessite beaucoup de temps et de multiples connexions pour se déclencher. Ainsi, les détecteurs d'attaques par force brute devraient être déclenchés dans la plupart des cas.
Compte tenu des deux mises en garde ci-dessus, cette attaque semble plus adaptée à un vecteur d'accès initial à partir d'Internet. Il est possible d'atténuer partiellement l'impact en utilisant une segmentation appropriée pour les connexions SSH Internet et pour le trafic provenant de machines qui doivent avoir des interfaces SSH orientées vers Internet (comme les jump boxes).
Mesures d'atténuation
Application de correctifs
La solution la plus simple est d'appliquer un correctif à OpenSSH pour obtenir une version mise à jour et non vulnérable. Cependant, comme les distributions Linux contiennent généralement OpenSSH, l'application d'un correctif dépend de la publication de celui-ci par le fournisseur, ce qui peut prendre plus de temps et nécessiter des tests supplémentaires.
Les administrateurs réseau peuvent utiliser l'osquery fourni dans cet article de blog pour détecter leurs actifs vulnérables et les suivre au fil du temps. Les clients d'Akamai Guardicore Segmentation peuvent également utiliser des requêtes planifiées à cette fin, puis étiqueter leurs ressources en fonction des résultats de la requête.
Segmentation
Comme nous l'avons indiqué ci-dessus, cette exploitation CVE est très probablement adaptée à une violation initiale dans les réseaux, car une exploitation réussie peut prendre des heures, voire des jours. Il est donc crucial de cartographier toutes les instances des interfaces OpenSSH Internet, et de fermer ou restreindre l'accès à celles-ci.
Dans les cas où un accès SSH arbitraire est requis à partir d'Internet, nous vous recommandons d'appliquer la segmentation du réseau sur ces machines pour restreindre leur accès au réseau interne et limiter le rayon d'explosion en cas d'exploitation et de violation réussies.
Seuil d'alerte en cas de menace
Puisque les correctifs ne sont pas forcément encore disponibles, il peut être plus prudent d'augmenter la sensibilité de vos alertes sur les charges de travail potentiellement vulnérables et non corrigées. De cette façon, même si la vulnérabilité est exploitée sans être détectée, vous pouvez toujours garder un œil sur ses conséquences. Nous vous recommandons en particulier de prêter attention aux tentatives de force brute, car c'est ainsi que l'exploitation se présenterait le plus vraisemblablement.
Cependant, l'augmentation de la sensibilité d'alerte, augmentera également la fatigue d'alerte. Par conséquent, nous recommandons aussi d'ajuster votre seuil d'alerte en fonction de l'importance de la charge de travail affectée pour le réseau ou de son impact.
Synthèse
Dans cet article de blog, nous avons examiné les informations disponibles sur la vulnérabilité critique regreSSHion dans OpenSSH, qui a été corrigée et divulguée récemment.
Pour les personnes responsables des systèmes de défense, l'étape critique consiste à déterminer la vulnérabilité des charges de travail dans leur réseau. Pour vous aider, nous vous proposons une osquery permettant de détecter les versions vulnérables d'OpenSSH. Nous avons également évoqué les mesures à prendre pour atténuer certains risques (c'est-à-dire ajuster le seuil d'alerte en cas de menace) en l'absence de correctifs.
Cet article de blog donne un aperçu de notre compréhension actuelle et de nos recommandations, compte tenu des informations disponibles. Notre analyse est en cours et toutes les informations contenues dans ce document sont susceptibles d'être modifiées. Suivez également notre compte X pour connaître les dernières informations en temps réel.