La semaine dernière, Qualys a publié une alerte de sécurité signalant des vulnérabilités (CVE-2016–0777 et 0778) dans les versions 5,4 à 7,1 du client OpenSSH. Si elles sont exploitées, ces vulnérabilités peuvent entraîner le vol de clés privées. Pour corriger cette vulnérabilité, les administrateurs peuvent soit appliquer le correctif de la version 7,1p2 à OpenSSH, soit configurer les clients SSH existants afin de désactiver la fonctionnalité susceptible d'être exploitée.
La découverte de versions vulnérables de logiciels tels qu’OpenSSH au sein d’une entreprise, quelle que soit sa taille, constitue un problème majeur, car la plupart des entreprises ne disposent pas des moyens élémentaires nécessaires pour identifier l’ensemble des terminaux présents sur leur réseau. Toute opération que vous souhaiteriez effectuer sur un seul système, comme l'arrêt de processus, la mise en quarantaine de systèmes ou le déploiement de correctifs, peut s'avérer difficile à mettre en œuvre sur l'ensemble des terminaux ; c'est l'une des raisons pour lesquelles Tanium constitue une excellente solution.
Recherches préliminaires
Après avoir lu le communiqué de Qualys, nous avons cherché à obtenir davantage d'informations sur les solutions de contournement, de préférence auprès des personnes ayant fourni le correctif. Theo de Raadt, une référence en la matière, a publié une directive de configuration non documentée « UseRoaming no » qui empêche le bogue de se manifester. À première vue, la solution semblait simple : il suffisait de créer rapidement un script shell pour ajouter l'entrée au fichier de configuration. Une discussion connexe sur a judicieusement souligné que l'ajout de la configuration au fichier de configuration pouvait échouer si ce dernier définissait des modèles d'hôte. Par conséquent, le script doit ajouter le paramètre de configuration pour tous les hôtes :
Déploiement rapide d'un script sur des machines vulnérables
La modification en masse des fichiers de configuration actifs devrait inquiéter tout administrateur sensé. Ce n'est pas une démarche à entreprendre sans une certaine prudence et sans avoir prévu un plan de secours. Si nous modifions le fichier, comment pouvons-nous annuler rapidement ces modifications sur un ou sur tous les systèmes ? Nous avons commencé par sauvegarder notre configuration actuelle dans un nouveau fichier, puis nous avons appliqué la correction suivante au fichier ssh_config : UseRoaming no :
Lors des premiers tests, nous avons constaté que l'option -e de la commande echo n'était pas disponible sur tous les systèmes ; nous avons donc choisi d'utiliser la construction « $ » pour garantir la portabilité. Nous avons donc amélioré la commande comme suit :
Nous avons effectué un nouveau test sur un seul système. Voici une image présentant les dernières lignes de l'ancien fichier, l'exécution manuelle de la correction via la ligne de commande et les dernières lignes du fichier de configuration modifié :
Nous avons testé le cas limite consistant à ajouter plusieurs fois la correction au fichier de configuration et avons constaté que le client SSH continuait de fonctionner malgré cette redondance. D'un point de vue opérationnel, il s'agit d'une bonne mesure de sécurité, mais nous avons noté qu'il faudrait y remédier ultérieurement au cours du développement.
Sécurité intégrée
Le plus simple est de remplacer le fichier de configuration par le fichier de sauvegarde. Dans l'idéal, nous n'aurions jamais à en arriver là, mais il s'agit d'une mesure préventive qui pourrait s'avérer très payante et renforcer la confiance alors que nous mettons rapidement en œuvre des mesures correctives à l'échelle de l'entreprise.
Le script est simple :
Déterminer l'étendue de la vulnérabilité d'OpenSSH
Maintenant que nous disposons de scripts permettant d'appliquer et de supprimer le correctif, il est temps d'écrire un autre script pour déterminer s'il est applicable. Nous allons intégrer ce script dans un capteur Tanium afin de pouvoir exécuter la requête sur l'ensemble du réseau de terminaux. Étant donné que plusieurs tests ont démontré que cette solution de contournement avait un impact positif, la méthode la plus simple dont nous disposons consiste à vérifier que le fichier ssh_config contient bien le résultat escompté suite à la correction.
Pour des raisons de portabilité, nous avons opté pour une implémentation sous forme de ligne unique en awk, qui affiche les lignes d'un fichier situées entre deux correspondances d'expressions régulières :
Cela ne s'applique qu'aux cas où la séquence complète de correction, composée de trois lignes, a été enregistrée dans le fichier. Nous avons choisi de renvoyer la chaîne « Potentiellement vulnérable » plutôt que « Vulnérable », car notre solution fonctionne indépendamment de la version d'OpenSSH. En élargissant notre champ d'action, quelle que soit la version, nous n'aurons pas besoin de mettre à jour notre code si des chercheurs devaient continuer à mettre au jour d'autres vulnérabilités liées à cette même fonctionnalité « Roaming » d'OpenSSH. (La fonctionnalité « Roaming » n'est jamais utile dans la pratique ; sa désactivation via la configuration renforce donc la sécurité sans nuire au bon fonctionnement du système.) Certains se souviendront peut-être de , et Shellshock, qui ont nécessité plusieurs tentatives et mises à jour logicielles avant que la communauté ne parvienne à tout régler correctement. Notre approche permet d'éviter que ce problème ne se reproduise avec le client SSH.
Voici le résultat de notre test effectué avec un fichier ssh_config par défaut :
Et maintenant, face à un adversaire que nous venions tout juste de battre :
Ça a l'air bien ! Nous avons ensuite intégré ces scripts dans un capteur Tanium que nous appellerons « État de la solution de contournement relative à la fuite de clés SSH ».
Configurations SSH spécifiques à chaque utilisateur et peaufinage du contenu
Au cours de nos recherches, nous n'avons pas trouvé beaucoup de discussions au sein de la communauté concernant les machines sur lesquelles les utilisateurs auraient pu définir leurs propres fichiers ~/.ssh_config. Étant donné que ces paramètres prévalent sur les configurations globales, les correctifs doivent être appliqués ici pour corriger cette vulnérabilité. Cela nous a amenés à apporter de nouvelles améliorations à notre contenu, qui parcourt désormais également les répertoires personnels. En raison des différences entre les plateformes, nous nous sommes retrouvés avec deux versions distinctes des scripts afin de prendre en charge à parts égales OS X et les variantes *nix.
De plus, nous avons amélioré la logique de nos scripts précédents qui appliquaient cette correction, afin d'éviter de l'appliquer plusieurs fois et d'alourdir les fichiers de configuration. Elles sont suffisamment longues pour ne plus tenir proprement dans un article de blog, mais comptent tout de même un peu plus de 40 lignes de code et de commentaires.
Le résultat final est une solution qui identifie en quelques secondes les systèmes « potentiellement vulnérables » sur les systèmes *nix et OS X. Si certains fichiers de configuration SSH résidents ne contiennent pas la mesure corrective nécessaire à la sécurisation de l'entreprise, les utilisateurs peuvent appliquer ou annuler cette correction sur tout ou partie des systèmes de l'entreprise en seulement quelques minutes.
La plateforme Tanium
Tanium facilite la résolution de la vulnérabilité OpenSSH, car il offre la seule visibilité en temps réel du secteur sur l'état de tous les terminaux, quel que soit le nombre de machines. Cette plateforme constitue le moyen le plus rapide et le plus simple de mettre en œuvre l'approche décrite dans cet article : commencez par utiliser des données provenant d'une source fiable, développez des scripts, effectuez des tests à grande échelle, affinez le tout, puis déployez pleinement ce qui devient, en substance, une nouvelle fonctionnalité de la plateforme.
N'hésitez pas à nous faire part de votre avis ou à contacter votre responsable technique si vous souhaitez intégrer ce contenu à votre propre déploiement. Si vous ne connaissez pas encore Tanium et que vous souhaitez en savoir plus, n'hésitez pas à nous contacter à l'adresse pour obtenir une démonstration.
Rory Prendergast, directeur principal
Peter Oelschlaeger, directeur principal
Vous souhaitez découvrir Tanium en action ? Prenez rendez-vous pour une démonstration individuelle ou participez à notre webinaire hebdomadaire. Venez échanger avec nos experts Tanium lors de nos prochains événements organisés dans le cadre de l' :.
