Dans les clients SSH OpenSSH et PuTTY ( dans PuTTY et dans OpenSSH), menaçant d'exposer des informations dans l'algorithme de négociation de connexion. Cette vulnérabilité permet à un attaquant, capable d'intercepter le trafic du client (par exemple, lors de la connexion d'un utilisateur via un point d'accès sans fil contrôlé par l'attaquant), de déterminer la tentative de connexion initiale du client à l'hôte, lorsque la clé de l'hôte n'est pas encore mise en cache par le client.
Sachant que le client essaie de se connecter pour la première fois et ne possède pas encore la clé de l'hôte, l'attaquant peut intercepter la connexion (MITM) et fournir au client sa propre clé d'hôte, que le client SSH considérera comme celle de l'hôte cible, s'il ne vérifie pas l'empreinte de la clé. Ainsi, l'attaquant peut réaliser une attaque MITM sans éveiller les soupçons de l'utilisateur et ignorer les sessions où des clés d'hôtes sont déjà mises en cache, une tentative de substitution de celles-ci entraînerait un avertissement concernant le changement de la clé d'hôte. L'attaque repose sur la négligence des utilisateurs qui ne vérifient pas manuellement l'empreinte de la clé d'hôte lors de la première connexion. Ceux qui vérifient les empreintes de clé sont protégés contre de telles attaques.
Comme indice pour déterminer la première tentative de connexion, on utilise le changement d'ordre de la liste des algorithmes de clés d'hôtes supportés. Si la connexion est initiale, le client envoie la liste des algorithmes par défaut, alors que si la clé de l'hôte est déjà en cache, l'algorithme associé est placé en premier (les algorithmes sont triés par ordre de préférence).
Le problème se manifeste dans les versions d'OpenSSH de 5.7 à 8.3 et dans PuTTY de 0.68 à 0.73. Le problème dans la version via l'ajout d'une option pour désactiver la construction dynamique de la liste des algorithmes de traitement des clés d'hôtes en faveur d'un énoncé d'algorithmes dans un ordre fixe.
Le projet OpenSSH ne prévoit pas de modifier le comportement du client SSH. Si l'algorithme de la clé existante n'est pas spécifié en premier, une tentative d'application d'un algorithme qui ne correspond pas à la clé mise en cache sera effectuée, entraînant l'affichage d'un avertissement concernant une clé inconnue. Cela signifie qu'il y a un choix à faire : soit une fuite d'informations (OpenSSH et PuTTY), soit l'affichage d'avertissements sur le changement de clé (Dropbear SSH) si la clé enregistrée ne correspond pas au premier algorithme de la liste par défaut.
Pour garantir la sécurité dans OpenSSH, il est recommandé d'utiliser des méthodes alternatives de vérification de la clé hôte à l'aide d'enregistrements SSHFP dans DNSSEC et de certificats hôtes (PKI). Il est également possible de désactiver le choix adaptatif des algorithmes de clés hôtes via l'option HostKeyAlgorithms et d'utiliser l'option UpdateHostKeys pour recevoir des clés hôtes supplémentaires après authentification.
Source : opennet.ru
