La semaine dernière, Qualys a publié unconseil de sécurité exposant les vulnérabilités (CVE-2016–0777 et 0778) dans les versions 5,4 à 7,1 du client OpenSSH. Lorsqu’elles sont exploitées, ces vulnérabilités peuvent entraîner le vol de matériel de clé privée. Pour éliminer la vulnérabilité, les administrateurs peuvent appliquer des correctifs à OpenSSH avec la version 7,1p2 ou configurer les clients SSH existants pour désactiver la fonctionnalité exploitable.
La découverte de versions vulnérables de logiciels comme OpenSSH dans une entreprise de toute envergure est un problème majeur, car la plupart des entreprises ne disposent pas de la capacité de base de voir tous les endpoints de leur réseau. Tout ce que vous voudriez faire sur un seul système, comme tuer des processus, mettre des systèmes en quarantaine ou déployer des correctifs, sur tous les endpoints peut être difficile, ce qui est l’une des raisons pour lesquelles Tanium est une excellente ressource.
Recherche initiale
Après avoir lu le communiqué de presse de Qualys, nous devions essayer de trouver plus d’informations sur les solutions de contournement, idéalement auprès des personnes fournissant le correctif. Theo de Raadt, une autorité sur le sujet, a publié une directive de configuration non documentée UseRoaming no qui empêche le bug de se propager. À première vue, il semblait que la solution de contournement serait triviale : il vous suffit de créer un script shell pour ajouter l’entrée au fichier de configuration. Une discussion connexea noté astucieusement que l’ajout de la configuration au fichier de configuration peut échouer si le fichier de configuration définit des modèles d’hôte. Ainsi, 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 des fichiers de configuration actifs en masse doit rendre tout administrateur rationnel nerveux. Ce n’est pas quelque chose à faire sans une mesure de prudence et un plan de retrait. Si nous modifions le fichier, comment pouvons-nous annuler rapidement les modifications sur un ou tous les systèmes ? Nous avons commencé par sauvegarder notre configuration existante dans un nouveau fichier, puis appliquer UseRoaming no fix à ssh_config :
Lors de tests précoces, nous avons découvert que l’indicateur -e pour l’écho n’est pas disponible sur tous les systèmes, nous avons donc choisi d’utiliser la structure $’’ pour la portabilité. Nous avons donc amélioré la commande avec ce qui suit :
Nous avons testé à nouveau sur un seul système. Voici une image représentant les dernières lignes de l’ancien fichier, en exécutant manuellement le correctif via la ligne de commande et les dernières lignes du fichier de configuration modifié :
Nous avons testé le cas Edge de l’ajout du correctif plusieurs fois au fichier de configuration et déterminé que le client ssh continue de fonctionner avec la redondance. Sur le plan opérationnel, il s’agit d’une bonne protection, mais nous avons noté que cela était quelque chose à nettoyer plus tard dans le développement.
Échec de la sécurité
La chose la plus simple à faire est de copier le fichier de sauvegarde sur le fichier de configuration. Idéalement, nous n’aurions jamais à le faire, mais c’est une once de prévention qui pourrait payer de graves dividendes et fournir une confiance supplémentaire à mesure que nous remédions rapidement à l’ensemble de l’entreprise.
Le script est de base :
Déterminer la portée de la vulnérabilité OpenSSH
Maintenant que nous avons des scripts à appliquer et à supprimer le correctif, il est temps d’écrire un autre script pour déterminer l’applicabilité. Nous emballerons ce script dans un sensor Tanium afin de pouvoir exécuter la requête sur l’ensemble du réseau d’endpoints. Étant donné que plusieurs tests ont montré que la solution de contournement avait un impact positif, la méthode la plus simple à notre disposition est de vérifier que ssh_config contient la sortie qui était prévue à partir du correctif.
Pour la portabilité, la méthode de mise en œuvre que nous avons choisie était une ligne unique fabuleuse, qui imprime les lignes d’un fichier qui existent entre d’autres correspondances d’expression régulière :
Cela correspond uniquement aux cas où la séquence de correction complète de trois lignes a été écrite dans le fichier. Nous avons choisi de renvoyer une chaîne de « Potentiellement vulnérable » au lieu de « Vulnérable », car nos solutions fonctionnent indépendamment de la version OpenSSH. En créant un réseau plus large, indépendamment de la version, nous n’aurons pas besoin de mettre à jour notre code si les chercheurs continuent d’exposer des vulnérabilités supplémentaires à la même fonctionnalité d’itinérance d’OpenSSH. (La fonction d’itinérance n’est jamais utile dans la pratique, donc une désactivation basée sur la configuration renforce la sécurité sans avoir d’impact négatif sur les opérations.) Certains se souviendront peut-être de Shellshock, qui a mis quelques essais et mises à jour logicielles avant que la communauté ne réussisse. Notre approche fournit une résilience contre ce résultat se répétant avec le client SSH.
Voici le résultat de notre test par rapport à un fichier ssh_config par défaut :
Et maintenant contre un que nous venions de corriger :
Cela semble bien ! Nous avons ensuite enveloppé ces scripts dans un Tanium Sensor que nous appellerons « Statut de contournement des fuites de clé SSH ».
Configurations SSH spécifiques à l’utilisateur et polissage du contenu
Lors de nos recherches, nous n’avons pas trouvé beaucoup de personnes dans la communauté discutant des machines sur lesquelles les utilisateurs peuvent avoir défini leurs propres fichiers ~/.ssh_config. Étant donné que ces paramètres remplaceraient les configurations globales, des correctifs doivent être appliqués ici pour fermer la vulnérabilité. Cela nous a conduits à d’autres améliorations de notre contenu qui passe également par les répertoires d’accueil. En raison des différences de plateforme, nous avons obtenu deux versions différentes des scripts pour prendre en charge les versions OS X et *nix de manière égale.
De plus, nous avons amélioré la logique de nos scripts précédents qui appliquaient le correctif afin de ne pas l’appliquer plusieurs fois et de vider les fichiers de configuration. Ils sont suffisamment longs pour ne plus s’intégrer parfaitement à un billet de blog, mais toujours un peu plus de 40 lignes de code et commentaires.
Notre résultat final est une solution qui identifie les systèmes comme « potentiellement vulnérables » sur *nix systèmes et OS X en quelques secondes. Si des fichiers de configuration SSH résidents ne contiennent pas l’atténuation pour sécuriser l’entreprise, les utilisateurs peuvent appliquer ou rétablir le correctif sur tout ou partie des systèmes de l’entreprise en quelques minutes seulement.
Tanium la plateforme
Tanium facilite la résolution de la vulnérabilité OpenSSH, car il fournit la seule visibilité en temps réel du secteur sur le statut de tous les endpoints, quel que soit le nombre de machines. La plateforme est le moyen le plus rapide et le plus simple de mettre en œuvre l’approche décrite dans ce message : commencez par les données d’une source réputée, développez des scripts, testez et affinez l’échelle, puis déployez entièrement ce qui devient essentiellement une nouvelle fonctionnalité de la plateforme.
Dites-nous ce que vous en pensez, ou contactez votre responsable de compte technique si vous souhaitez exécuter le contenu dans votre propre déploiement. Si vous ne connaissez pas Tanium et souhaitez en savoir plus, veuillez nous contacter pour une démonstration.
Rory Prendergast, Directeur principal
Peter Oelschlaeger, Directeur principal
Vous souhaitez voir Tanium en action ? Planifiez une démo individuelle ou participez à notre webinaire hebdomadaire. Discutez avec nos experts Tanium lors de nos prochains événements.
