En cybersécurité, les vulnérabilités sont souvent comme des fantômes du passé, apparaissant de manière inattendue et nous hantant encore et encore. C’est le cas de regreSSHion (CVE-2024-6387) CVSS 8.1, une vulnérabilité apparue dans OpenSSH après près de deux décennies d’inactivité. Voyons en quoi consiste cette vulnérabilité et comment elle affecte vos systèmes.

Swachchhanda Shrawan Poudel
Swachchhanda Shrawan Poudel

Security Research

Jump To Section

Share This Story

Présentation de regreSSHion

La vulnérabilité regreSSHion (CVE-2024-6387) est une faille d'exécution de code à distance non authentifiée trouvée dans les serveurs OpenSSH (sshd) et les systèmes Linux basés sur glibc. En cas d’exploitation, elle permettrait un accès root complet au niveau de la machine ciblée sans interaction avec l'utilisateur. Cette vulnérabilité est considérée comme étant de gravité « élevée » (CVSS 8.1).

Un fantôme du passé

  • En 2006, OpenSSH a été confronté à une vulnérabilité de type ‘regression’ similaire (CVE-2006-5051), qui a été corrigée.

  • Dans ce contexte, ‘regression’ signifie qu'une faille, une fois corrigée, est réapparue dans une version logicielle ultérieure, généralement en raison de modifications ou de mises à jour qui réintroduisent le problème par inadvertance

  • Retour rapide en 2020 : OpenSSH 8.5p1 a introduit un correctif transformateur qui a résolu le problème.

  • Mais le destin en a décidé autrement : regreSSHion a refait surface en raison de la suppression accidentelle d'un composant critique dans les versions comprises entre 8.5p1 et 9.8p1.

Versions concernées

La gamme vulnérable concernée

  • Les versions antérieures à 4.4p1 sont vulnérables à moins d'être corrigées concernant les vulnérabilités suivantes : CVE-2006-5051 et CVE-2008-4109.

  • Les versions de 4.4p1 jusqu'à (mais non inclus) 8.5p1 sont sécurisées grâce au correctif transformateur.

  • La zone de danger : les versions de 8.5p1 jusqu'à (mais non inclus) 9.8p1.

Version État de vulnérabilité
OpenSSH < 4.4p1 OUI (sauf si correctifs installés pour CVE-2006-5051 et CVE-2008-4109)
4.4p1 <= OpenSSH < 8.5p1 NON
8.5p1 <= OpenSSH <= 9.7p1 OUI

Détails techniques de la vulnérabilité

Le 1er juillet 2024, OpenSSH a publié la version 9.8/9.8p1, qui corrige la vulnérabilité de situation de concurrence (race condition) critique : CVE-2024-6387. La note de version aborde de manière approfondie les détails de cette vulnérabilité. Vous trouverez ci-dessous les informations partagées au 3 juillet 2024 :

Détails de l'exploitation

  • Exploitation démontrée : une exploitation réussie a été démontrée sur des systèmes Linux 32 bits utilisant glibc avec l’ASLR (Address Space Layout Randomization) activée. Dans des conditions de laboratoire contrôlées, l'attaque a duré 6 à 8 heures durant lesquelles des tentatives de connexion continues ont été lancées, jusqu'au nombre maximum de connexions autorisées sur le serveur.

  • Risque potentiel pour les systèmes 64 bits : bien que l'exploitation sur les systèmes 64 bits n'ait pas été démontrée, elle est considérée comme possible et susceptible d'être améliorée par les attaquants.

  • Systèmes non-glibc : bien que l'exploitation de systèmes non-glibc soit envisageable, elle n'a pas été véritablement analysée.

  • Considérations relatives à l’ASLR : les systèmes sans ASLR ou les distributions Linux aval qui ont désactivé la re-randomisation ASLR par connexion peuvent être plus susceptibles d'être exploités plus facilement.

Vecteurs d'attaque

  • Connexions continues : l'attaque nécessite des connexions continues sur une période prolongée, profitant de la situation de concurrence (race condition) critique dans le processus sshd(8).

  • ASLR Bypass : l'exploitation démontrée s'appuie sur l'ASLR pour augmenter les chances de succès. Les systèmes dépourvus d’ASLR peuvent être plus vulnérables.

Détection avec Logpoint

Nous avons spécialement développé un playbook pour identifier si les systèmes Linux de votre environnement étaient vulnérables à CVE-2024-6387.

La requête SQL suivante est exécutée via Osquery sur chaque machine et les résultats sont reflétés dans Logpoint.

Cette requête évalue l'état de vulnérabilité des packages OpenSSH installés sur un système en examinant ceux gérés par les gestionnaires de packages DEB et RPM. Elle détecte les packages OpenSSH, obtient leurs numéros de version et détermine s'ils sont sensibles, non vulnérables ou potentiellement vulnérables en fonction de leur version. La sortie des deux gestionnaires de packages est regroupée dans un tableau contenant le type de gestionnaire de packages, le nom du package, la version et l'état de vulnérabilité.

Les informations renvoyées peuvent être visualisées à partir de Logpoint Case Management (Gestion d’incident).

Pour une meilleure agrégation et visualisation des données, vous pouvez également utiliser une requête de recherche Logpoint, car ces informations sont également indexées dans Logpoint SIEM. Vous pouvez copier la requête depuis la fenêtre ‘Case Management’ (Gestion d’incident) et démarrer votre agrégation.

Cette requête fournit une liste d'agents sur lesquels openssh-server est installé avec leurs versions respectives. Si la version appartient à une plage vulnérable, l'état de vulnérabilité correspondant est affiché dans la colonne vulnerability_status.

Si vous souhaitez uniquement voir les machines vulnérables, vous pouvez utiliser la requête ci-dessous :

Si les options ci-dessus ne sont pas réalisables, vous pouvez utiliser le script bash fourni pour vérifier la vulnérabilité localement.

Supposons que vous soupçonniez que votre appareil ait été piraté. Dans ce cas, vous pouvez mitiger le risque en l'isolant ou en bloquant l'adresse IP suspecte via AgentX.

Stratégies de mitigation

La stratégie de mitigation la plus efficace consiste à reconnaître tous les appareils vulnérables et à les corriger en installant la dernière version, OpenSSH 9.8/9.8p1. Si une telle action n’est pas possible, plusieurs autres stratégies de mitigation peuvent être mises en œuvre, elles sont détaillées ci-dessous.

Actions immédiates

  1. Installez les correctifs et les mises à jour ::

    • Pour mitiger le problème, installez immédiatement tous les correctifs ou mises à jour disponibles auprès de votre fournisseur SSH ou de votre système d'exploitation.

    • Selon Qualys, si la mise à jour ou la recompilation sshd n'est pas une option, mettez LoginGraceTime sur 0 dans le fichier de configuration. Bien que ce paramètre puisse conduire à une attaque par déni de service en sollicitant de manière excessive toutes les connexions MaxStartups, il mitige le risque d'exécution de code à distance.

  2. Désactivez temporairement SSH :

    • Pour éviter toute exploitation, désactivez l'accès SSH jusqu'à ce que la vulnérabilité soit corrigée.

  3. Restreindre l'accès IP :

    • Utilisez des règles de pare-feu ou des groupes de sécurité pour limiter l'accès SSH aux seules adresses IP de confiance.

  4. Désactivez la connexion root :

    • Modifiez votre configuration SSH (/etc/ssh/sshd_config) et mettez PermitRootLogin sur ‘no’.

  5. Utilisez des méthodes d’authentification fortes :

    • Désactivez l'authentification par mot de passe et utilisez plutôt l'authentification par clé. Assurez-vous que le numéro d'authentification par mot de passe soit défini dans vos paramètres SSH.

  6. Mettre en œuvre l'authentification multifacteur (MFA) :

    • Utilisez l'authentification multifacteur pour bénéficier de couches de sécurité supplémentaires de sorte que même si la vulnérabilité est exploitée, elle soit inaccessible sans la clé MFA.

Techniques de renforcement (hardening) à long terme

  1. Modifiez le port SSH par défaut :

    • Modifiez le port SSH par défaut (22) en un port non standard pour minimiser les attaques automatisées.

  2. Utilisez la gestion des clés SSH :

    • Faites régulièrement tourner les clés SSH et assurez-vous qu'elles disposent de passphrases solides.

    • Utilisez des outils commessh-agent et ssh-add pour gérer vos clés en toute sécurité.

  3. Activez la journalisation (logging) et la surveillance SSH :

    • Activer la journalisation/logging détaillée pour SSH (LogLevel VERBOSE dans sshd_config).

    • Surveillez régulièrement les logs pour détecter les activités suspectes à l'aide d'outils tels que fail2banou de systèmes SIEM comme Logpoint SIEM.

  4. Mettre en œuvre des systèmes de détection d'intrusion (IDS : Intrusion Detection Systems) :

    • Déployez un IDS tel que Snort ou OSSEC pour détecter et répondre aux activités suspectes en temps réel.

  5. Limitez l'accès des utilisateurs et utilisez AllowUsers ou AllowGroups:

    • Utilisez les directives AllowUsers ou AllowGroupsdanssshd_config pour limiter les utilisateurs ou les groupes pouvant accéder à SSH.

  6. Utilisez un hôte Bastion :

    • Configurez un hôte bastion pour agir comme une passerelle pour l'accès SSH, réduisant ainsi la surface d'attaque et centralisant la journalisation/logging et la surveillance.

  7. Mettre en œuvre la segmentation du réseau :

    • Créez une segmentation au niveau de votre réseau pour minimiser l'impact d'un serveur SSH compromis.

  8. Audits de sécurité et pentests réguliers :

    • Des audits de sécurité et des pentests réguliers sont nécessaires pour identifier et mitiger les vulnérabilités.

  9. Renforcez les configurations des clients SSH :

    • Assurez-vous que vos clients SSH soient également configurés de manière sécurisée, à l'aide de techniques de chiffrement et d'algorithmes puissants (Ciphers, MACs et KexAlgorithms dansssh_config).