Dans les clients SSH OpenSSH et PuTTY ( dans PuTTY et dans OpenSSH), entraînant une fuite d'informations dans l'algorithme de négociation de connexion. La vulnérabilité permet à un attaquant capable d'intercepter le trafic client (par exemple, lorsqu'un utilisateur se connecte via un point d'accès sans fil contrôlé par l'attaquant) de détecter une tentative de connexion initiale du client à l'hôte alors que le client n'a pas encore mis en cache la clé de l'hôte.
Sachant que le client tente de se connecter pour la première fois et n'a pas encore la clé d'hôte de son côté, l'attaquant peut diffuser la connexion par lui-même (MITM) et donner au client sa clé d'hôte, que le client SSH considérera comme être la clé de l'hôte cible s'il ne vérifie pas l'empreinte digitale de la clé. Ainsi, un attaquant peut organiser MITM sans éveiller les soupçons de l'utilisateur et ignorer les sessions dans lesquelles le côté client a déjà mis en cache des clés d'hôte, une tentative de remplacement qui entraînera un avertissement concernant le changement de clé d'hôte. L'attaque repose sur la négligence des utilisateurs qui ne vérifient pas manuellement l'empreinte digitale de la clé hôte lors de leur première connexion. Ceux qui vérifient les empreintes digitales des clés sont protégés contre de telles attaques.
En guise de signe permettant de déterminer la première tentative de connexion, un changement dans l'ordre de liste des algorithmes de clé d'hôte pris en charge est utilisé. Si la première connexion se produit, le client transmet une liste d'algorithmes par défaut, et si la clé hôte est déjà dans le cache, alors l'algorithme associé est mis en première place (les algorithmes sont triés par ordre de préférence).
Le problème apparaît dans les versions OpenSSH 5.7 à 8.3 et PuTTY 0.68 à 0.73. Problème en cause en ajoutant une option pour désactiver la construction dynamique d'une liste d'algorithmes de traitement de clé hôte au profit d'une liste des algorithmes dans un ordre constant.
Le projet OpenSSH ne prévoit pas de modifier le comportement du client SSH, car si vous ne spécifiez pas en premier lieu l'algorithme de la clé existante, on tentera d'utiliser un algorithme qui ne correspond pas à la clé mise en cache et un avertissement concernant une clé inconnue sera affiché. Ceux. un choix se présente - soit une fuite d'informations (OpenSSH et PuTTY), soit des avertissements concernant le changement de clé (Dropbear SSH) si la clé enregistrée ne correspond pas au premier algorithme de la liste par défaut.
Pour assurer la sécurité, OpenSSH propose des méthodes alternatives de vérification de la clé d'hôte à l'aide des entrées SSHFP dans DNSSEC et des certificats d'hôte (PKI). Vous pouvez également désactiver la sélection adaptative des algorithmes de clé d'hôte via l'option HostKeyAlgorithms et utiliser l'option UpdateHostKeys pour permettre au client d'obtenir des clés d'hôte supplémentaires après l'authentification.
Source: opennet.ru