regreSSHion: Vulnérabilité d’exécution de code à distance non authentifiée dans le serveur OpenSSH

Le groupe de recherche de Qualys a découvert une vulnérabilité d’exécution de code à distance (RCE) non authentifiée dans le serveur OpenSSH (sshd) des systèmes Linux basés sur glibc. La CVE attribuée à cette vulnérabilité est CVE-2024-6387.

Cette vulnérabilité, qui est une condition de course du gestionnaire de signaux dans le serveur OpenSSH (sshd), permet une exécution de code à distance non authentifiée en tant que root sur les systèmes Linux basés sur glibc; ce qui présente un risque de sécurité significatif. Cette condition de course affecte sshd dans sa configuration par défaut.

Sur la base de recherches utilisant Censys et Shodan, nous avons identifié plus de 14 millions d’instances de serveurs OpenSSH potentiellement vulnérables exposées sur Internet. Les données anonymisées de Qualys CSAM 3.0 avec des données de gestion de la surface d’attaque externe révèlent qu’environ 700 000 instances externes exposées à Internet sont vulnérables. Cela représente 31% de toutes les instances exposées à Internet avec OpenSSH dans notre base de clients mondiale. De manière intéressante, plus de 0,14% des instances Internet vulnérables avec le service OpenSSH exécutent une version en fin de vie/fin de support d’OpenSSH.

Dans notre analyse de sécurité, nous avons identifié que cette vulnérabilité est une régression de la vulnérabilité précédemment corrigée CVE-2006-5051, signalée en 2006. Une régression dans ce contexte signifie qu’une faille, une fois corrigée, est réapparue dans une version ultérieure du logiciel, généralement en raison de changements ou de mises à jour qui réintroduisent involontairement le problème. Cette régression a été introduite en octobre 2020 (OpenSSH 8.5p1).

Qualys a développé un exploit fonctionnel pour la vulnérabilité regreSSHion. Dans le cadre du processus de divulgation, nous avons démontré avec succès l’exploit à l’équipe OpenSSH pour les aider dans leur compréhension et leurs efforts de remédiation. Nous ne publions pas nos exploits, car nous devons laisser le temps aux correctifs d’être appliqués. Cependant, même si l’exploit est complexe, nous croyons que d’autres chercheurs indépendants pourront reproduire nos résultats.

À propos d’OpenSSH: Sécurisation des communications et de l’infrastructure d’entreprise

OpenSSH (Open Secure Shell) est une suite d’utilitaires de réseau sécurisés basés sur le protocole Secure Shell (SSH), qui est vital pour la communication sécurisée sur des réseaux non sécurisés. Il fournit un cryptage robuste pour garantir la confidentialité et des transferts de fichiers sécurisés, en en faisant un outil essentiel pour la gestion de serveurs à distance et la communication sécurisée des données. Connu pour ses nombreuses fonctionnalités de sécurité et d’authentification, OpenSSH prend en charge diverses technologies de cryptage et est standard sur plusieurs systèmes de type Unix, y compris macOS et Linux.

L’implémentation d’OpenSSH sert d’outil critique pour la communication sécurisée. Sa valeur pour les entreprises réside dans sa scalabilité et la capacité à imposer des contrôles d’accès robustes et à sécuriser les processus automatisés dans divers environnements. Cela inclut tout, des sauvegardes automatisées et du traitement par lots aux pratiques DevOps complexes, qui impliquent la manipulation sécurisée de données sensibles sur plusieurs systèmes et emplacements. Son développement continu et son adoption généralisée soulignent son importance dans le maintien de la confidentialité et de l’intégrité des communications réseau à l’échelle mondiale.

OpenSSH se positionne comme une référence en matière de sécurité logicielle, illustrant une approche robuste de la défense en profondeur. Malgré la récente vulnérabilité, son bilan global reste exceptionnellement solide, servant à la fois de modèle et d’inspiration dans le domaine.

Versions OpenSSH affectées :

• Les versions d’OpenSSH antérieures à 4.4p1 sont vulnérables à cette condition de course du gestionnaire de signaux, sauf si elles sont corrigées pour les CVE-2006-5051 et CVE-2008-4109.
• Les versions de 4.4p1 jusqu’à, mais sans inclure, 8.5p1 ne sont pas vulnérables en raison d’un correctif transformateur pour CVE-2006-5051, qui a rendu une fonction précédemment non sécurisée sûre.
• La vulnérabilité réapparaît dans les versions de 8.5p1 jusqu’à, mais sans inclure, 9.8p1 en raison de la suppression accidentelle d’un composant critique dans une fonction.

Les systèmes OpenBSD ne sont pas affectés par ce bogue, car OpenBSD a développé un mécanisme sécurisé en 2001 qui empêche cette vulnérabilité.

Impact potentiel de regreSSHion

Cette vulnérabilité, si exploitée, pourrait entraîner une compromission complète du système où un attaquant peut exécuter un code arbitraire avec les plus hauts privilèges, entraînant une prise de contrôle complète du système, l’installation de logiciels malveillants, la manipulation de données et la création de portes dérobées pour un accès persistant. Cela pourrait faciliter la propagation du réseau, permettant aux attaquants d’utiliser un système compromis comme point d’appui pour traverser et exploiter d’autres systèmes vulnérables au sein de l’organisation.

De plus, l’obtention de l’accès root permettrait aux attaquants de contourner des mécanismes de sécurité critiques tels que les pare-feu, les systèmes de détection d’intrusion et les mécanismes de journalisation, obscurcissant davantage leurs activités. Cela pourrait également entraîner des violations et des fuites de données significatives, donnant aux attaquants accès à toutes les données stockées sur le système, y compris des informations sensibles ou propriétaires qui pourraient être volées ou divulguées publiquement.

Cette vulnérabilité est difficile à exploiter en raison de sa nature de condition de course à distance, nécessitant de multiples tentatives pour une attaque réussie. Cela peut entraîner une corruption de la mémoire et nécessiter de surmonter la randomisation de l’espace d’adressage (ASLR). Les avancées en matière d’apprentissage profond peuvent augmenter considérablement le taux d’exploitation, offrant potentiellement aux attaquants un avantage substantiel dans l’exploitation de telles failles de sécurité.

Étapes immédiates pour atténuer les risques

Pour remédier à la vulnérabilité regreSSHion dans OpenSSH, qui permet l’exécution de code à distance sur les systèmes Linux, une approche de sécurité concentrée et en couches est nécessaire. Voici des étapes concises et des recommandations stratégiques pour les entreprises afin de se protéger contre cette menace significative :

1. Gestion des correctifs : Appliquez rapidement les correctifs disponibles pour OpenSSH et priorisez les processus de mise à jour en cours.
2. Contrôle d’accès renforcé : Limitez l’accès SSH par le biais de contrôles basés sur le réseau pour minimiser les risques d’attaque.
3. Segmentation du réseau et détection d’intrusion : Divisez les réseaux pour restreindre l’accès non autorisé et les mouvements latéraux au sein des environnements critiques et déployez des systèmes pour surveiller et alerter sur les activités inhabituelles indiquant des tentatives d’exploitation.
4. Évaluation et remédiation personnalisées : Exécutez rapidement le script de mitigation sur les actifs requis. Pour en savoir plus, consultez la section FAQ ‘Y a-t-il des mesures d’atténuation pour cette vulnérabilité ?’

Détails techniques

Vous pouvez trouver les détails techniques de cette vulnérabilité sur : lien

Couverture QID Qualys

Qualys publie les QID dans le tableau ci-dessous au fur et à mesure de leur disponibilité, en commençant par la version des signatures de vulnérabilités VULNSIGS-2.6.83-4 et dans la version du manifeste de l’agent cloud Linux LX_MANIFEST-2.6.83.4-5

Pour plus d’informations, veuillez consulter la base de connaissances sur les vulnérabilités de Qualys.

Découvrir les actifs vulnérables en utilisant Qualys CyberSecurity Asset Management (CSAM)

La première étape cruciale pour gérer cette vulnérabilité critique et atténuer les risques associés consiste à identifier tous les actifs susceptibles de présenter ce problème spécifique. Utilisez Qualys CSAM pour identifier les instances Internet de votre organisation qui exécutent des versions vulnérables d’OpenSSH ou qui sont en fin de vie (EOL) ou en fin de support (EOS).

Améliorez votre posture de sécurité avec Qualys Vulnerability Management, Detection, and Response (VMDR)

Qualys VMDR offre une couverture et une visibilité complètes des vulnérabilités, permettant aux organisations de répondre rapidement, de prioriser et de réduire les risques associés de manière efficace. De plus, les clients de Qualys peuvent tirer parti de Qualys Query Language (QQL) pour remédier efficacement aux vulnérabilités mises en évidence ci-dessus.

Détectez et remédiez à CVE-2024-6387 avec Qualys TotalCloud Container Security

Qualys TotalCloud Container Security offre une couverture et une visibilité complètes des vulnérabilités dans tous vos environnements de conteneurs, y compris Kubernetes gérés et Kubernetes sur site. Cela permet aux organisations de répondre rapidement, de prioriser et de réduire efficacement les risques associés de manière prompte.

Produits Qualys et responsabilités des clients

Qualys raccourcit le cycle de publication pour certains produits déployés sur les sites des clients. Au moins l’un de ces produits dépend d’un fournisseur qui publiera bientôt une version corrigée. Nous avons l’intention de publier des correctifs pour cette CVE de gravité ÉLEVÉE dans les prochains jours pour garantir la sécurité des clients contre regreSSHion. Une fois les versions validées par l’assurance qualité, nous fournirons des mises à jour pour aider les clients à appliquer les correctifs.

FAQ

• L’équipe de recherche de Qualys publiera-t-elle un code d’exploitation ou inclura-t-elle un code de preuve de concept pour cette vulnérabilité ?

Non, dans le cadre de notre engagement en matière de divulgation responsable et de maintien de normes de sécurité élevées, nous ne publierons pas de codes d’exploitation. Étant donné la complexité de cette vulnérabilité, il est crucial de permettre aux organisations d’appliquer efficacement les correctifs sans la pression immédiate d’exploits publics.

• Y a-t-il des mesures d’atténuation pour cette vulnérabilité ?

Si sshd ne peut pas être mis à jour ou recompilé, définissez LoginGraceTime sur 0 dans le fichier de configuration. Cela expose sshd à un déni de service en utilisant toutes les connexions MaxStartups, mais cela empêche le risque d’exécution de code à distance.

• Cette vulnérabilité est-elle exploitable à distance ?

Oui, cette vulnérabilité peut être exploitée à distance et permet une exécution de code à distance non authentifiée (RCE) en tant que root, posant un risque de sécurité significatif.

Source de l’article