==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0b of 0x12 |=--------------=[ Tranchant comme un couteau. SSHarp. ]=----------------=| |=----------------=[ (It cuts like a knife. SSHarp.) ]=------------------=| |=-----------------------------------------------------------------------=| |=----------------=[ stealth ]=------------------=| |=------=[ Traduit par Thiébaud Weksteen ]=-------=| --[ Sommaire - Intoduction 1 - Jouer avec la bannière 2 - Jouer avec les clefs 3 - Contre-mesures 4 - Une implémentation 5 - Discussion 6 - Remerciements 7 - Références --[ Introduction Le protocole Secure Shell (SSH) est considéré comme solide en soi mais son implémentation présente souvent des faiblesses. En particulier, l'interopérabilité entre SSH1 et SSH2, telle qu'elle est implémentée dans la majeure partie des clients SSH, souffre de certains points faibles décrits ci-dessous. De plus, le protocole SSH2 lui-même est suffisamment souple pour comporter des éléments qui intéresseront les attaquants. L'avis de non-responsabilité concernant cet article est disponible dans la version pdf [ici]. Le programme HDM sera disponible disponible une semaine après la parution de cet article pour permettre aux revendeurs de corriger (ces corrections seront assez minimes) leurs logiciels afin de limiter les possibilités d'abus. Dans cet article je vais décrire comment les clients SSH peuvent se faire piéger et penser qu'ils ne possèdent pas la clef-hôte pour l'hôte sur lequel ils se connectent, bien qu'ils la possèdent déjà dans leur liste des hôtes connus. Ceci est possible à cause de certains points dans les brouillons SSH qui rendent la vie des développeurs SSH plus difficile mais qui auraient dû offrir une protection spéciale ou plus de souplesse. Je pars du principe que vous comprenez les bases du fonctionnement de SSH. Cependant, il n'est pas nécessaire de tout comprendre dans les détails car cette attaque survient au moment de la poignée de main alors que quelques paquets seulement ont été échangés. Je considère aussi que vous connaissez bien les scénarios classiques d'attaque sur le réseau comme les attaques de l'Homme Du Milieu (Man In the Middle), les attaques par détournement contre les protocoles en texte clair, les attaques par répétition, etc. --[ 1 - Jouer avec la bannière Le brouillon SSH exige que les deux parties, client et serveur, échangent une bannière avant de négocier la clef utilisée pour crypter le canal de communication. Cela est en effet nécessaire pour que les deux côtés voient quelle version du protocole sera utilisée. Généralement, une bannière ressemble à ça : SSH-1.99-OpenSSH_2.2.0p1 Un client qui reçoit une bannière comme celle-là y lit "me parle SSH1 ou SSH2". Cela est dû au "1" après le tiret, également connu sous le nom de version majeure à distance. Cela permet au client de choisir SSH1 pour la négociation des clefs et d'autres cryptages. Cependant, il est également possible pour le client de continuer avec des paquets SSH2 comme le "99" le précise, également connu sous le nom de version mineure à distance. (Par convention, la combinaison d'une version mineure à "99" et une version majeure à "1" indique que les deux protocoles sont possibles.) En fonction du fichier de configuration du client et des options passées à la commande, il décide d'utiliser l'un ou l'autre des protocoles. A supposer alors que l'utilisateur ne force pas un protocole avec soit le "-1" soit "-2", le comportement des clients devrait être identique. Cela est dû aux fichiers de configuration qui ne diffèrent pas tant que ça d'un revendeur SSH à un autre, et comportent souvent la ligne Protocol 1,2 qui incite le client à choisir la version 1 du protocole. Ce qui se passe ensuite est évident. Puisque le client SSH utilisait jusqu'à maintenant SSH1 pour parler au serveur il est fort probable qu'il n'ait jamais parlé SSH2 avant. Cela peut être exploité par les attaquants pour demander une bannière comme SSH-2.00-TESO-SSH au client. Le client recherche dans sa base de données des hôtes connus et rate la clef-hôte parce qu'il ne trouve que la clef SSH1 du serveur qui ne sert pas à grand-chose car, d'après la bannière, il n'est plus autorisé à parler SSH1 (puisque la version majeure à distance est 2). Au lieu de présenter un avertissement comme @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA1 host key has just been changed. The fingerprint for the RSA1 key sent by the remote host is f3:cd:d9:fa:c4:c8:b2:3b:68:c5:38:4e:d4:b1:42:4f. Please contact your system administrator. [ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ ATTENTION: L'IDENTIFICATION DE L'HÔTE DISTANT A CHANGÉ @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IL EST POSSIBLE QU'ON ESSAYE DE VOUS FAIRE DU MAL! Quelqu'un est peut-être en train de vous espionner (attaque homme-du-milieu)! Il est également possible que la clef-hôte RSA1 vienne d'être changée. L'empreinte pour la clef RSA1 envoyé par l'hôte distant est f3:cd:d9:fa:c4:c8:b2:3b:68:c5:38:4e:d4:b1:42:4f. Veuillez contacter votre administrateur système.] si quelqu'un essaye une attaque HDM contre lui sans une bannière modifiée, il est seulement demandé à l'utilisateur d'accepter la nouvelle clef: Enabling compatibility mode for protocol 2.0 The authenticity of host 'lucifer (192.168.0.2)' can't be established. DSA key fingerprint is ab:8a:18:15:67:04:18:34:ec:c9:ee:9b:89:b0:da:e6. Are you sure you want to continue connecting (yes/no)? [ Activation du mode de compatibilité pour le protocole 2.0 L'authenticité de l'hôte 'lucifer (192.168.0.2)' n'a pu être établie. L'empreinte de la clef DSA est ab:8a:18:15:67:04:18:34:ec:c9:ee:9b:89:b0:da:e6. Êtes-vous sûr de vouloir continuer la connexion (oui/non)?] Il est nettement plus simple pour l'utilisateur de taper "yes" au lieu d'éditer le fichier known_host et de redémarrer le client SSH. Une fois accepté, le serveur SSH des attaquants enregistrera le login et le mot de passe et déviera la connexion SSH afin que l'utilisateur ne remarque pas l'usurpation de son compte. L'attaque décrite n'est pas qu'une simple attaque par mise à jour. Cela fonctionne aussi pour mettre en SSH1 des clients qui parlent SSH2. Si la bannière comportait "2.0" le client ne parlait que SSH2 au serveur original et il ne peut normalement pas connaître la clef SSH1 du serveur car il ne parle pas du tout SSH1. Cependant, notre serveur HDM parle SSH1 et fait une nouvelle demande au client avec une clef qu'il ne peut connaître. Cette attaque ne fonctionnera pas avec les clients ne supportant qu'un unique protocole (sûrement SSH1) car il n'en implémente qu'un seul. Ces clients sont très rares et la majorité, voire tous les clients SSH, supportent les deux versions. En effet, le support des deux versions est même un argument commercial. Si le client utilise une identification RSA, il n'existe aucun moyen pour l'attaquant de s'immiscer puisqu'il ne peut utiliser les modes questions/réponses RSA présentés à lui par le serveur car il parle un protocole différent avec le client. En d'autres termes, l'attaquant ne parle jamais la même version de protocole avec les deux parties et ainsi il ne peut transférer ou intercepter l'identification RSA. On trouvera un exemple de programme HDM (ssharp) qui met en place la modification de la bannière et qui enregistre les logins sur [ssharp]. --[ 2 - Jouer avec les clefs Il serait intéressant d'avoir une attaque similaire contre SSH sans le basculement de version. En effet, le basculement de version rend impossible le décryptage de l'authentification RSA. La lecture des brouillons SSH2 montre que SSH2 n'utilise plus la clef-hôte pour le cryptage (tout comme avec SSH1 où l'hôte et la clef-serveur sont envoyés au client qui a retourné la clef de session cryptée avec ces clefs). Au lieu de cela, le client obtient la clef-hôte pour vérifier s'il y a eu atteinte à l'intégrité d'un des paquets échangés en comparant le MAC (Message Authentication Code; le serveur calcule un hachage des paquets échangés et les signe en utilisant l'algorithme négocié) envoyé par le serveur avec le hachage qu'il a lui-même calculé. Le brouillon SSH2 est suffisamment souple pour offrir plus qu'un seul algorithme statique pour permettre le calcul du MAC. Au contraire, il indique que pendant l'échange des clefs, le client et le serveur échangent une liste des algorithmes préférés qu'ils utilisent pour assurer l'intégrité du paquet. Généralement, ce sont DSA et RSA qui sont utilisés: stealth@liane:~> telnet 192.168.0.2 22 Trying 192.168.0.2... Connected to 192.168.0.2. Escape character is '^]'. SSH-1.99-OpenSSH_2.2.0p1 SSH-2.0-client `$es??%9?2?4D=?)??ydiffie-hellman-group1-sha1ssh-dss... J'ai supprimé de nombreux caractères et les ai remplacés par "..." car la partie intéressante est le "ssh-dss" qui dénote l'algorithme préféré que les serveurs utilisent pour le calcul du MAC. Les clients qui se connectent à 192.168.0.2 ne peuvent pas avoir une clef RSA pour le calcul puisque le serveur n'en a pas! Bien sûr, le programme HDM des attaquants a une clef RSA et ne fournit que RSA pour assurer l'intégrité: stealth@liane:~> telnet 192.168.0.2 22 Trying 192.168.0.2... Connected to 192.168.0.2. Escape character is '^]'. SSH-2.0-OpenSSH_2.9p1 SSH-2.0-client at s?eu??>vM??E=diffie-hellman-group-exchange-sha1, diffie-hellman-group1-sha1ssh-rsa... Un client SSH qui se connecte à notre serveur HDM invitera de nouveau l'utilisateur à accepter la nouvelle clef au lieu d'afficher l'avertissement d'HDM. Le serveur HDM se connecte au serveur original et se rend compte qu'il utilise DSA. Il décide alors d'accepter l'utilisateur avec une clef RSA. Si le serveur original propose DSA et RSA, le serveur HDM attendra que le client envoie ses algorithmes préférés et choisira alors l'algorithme que le client a mis en second choix. Un serveur SSH2 conforme à la RFC doit choisir le premier algorithme qu'il supporte dans la liste du client. Notre serveur HDM choisira le suivant et produira ainsi une absence de clef du côté du client. Cela entraînera encore une invite à répondre oui/non au lieu du message d'avertissement. "ssharp" supporte aussi ce mode de modification de la clef. --[ 3 - Contre-mesures Le fait d'avoir la clef-hôte RSA pour un serveur offrant une clef-hôte DSA ne signifie plus rien pour les clients d'aujourd'hui. Ils ne tiennent pas compte du fait qu'ils possèdent une clef-hôte valide pour cet hôte mais sous un format différent. Les clients SSH devraient aussi afficher l'avertissement HDM s'ils trouvent des clef-hôtes pour le serveur lorsque la version ou bien le type ne correspond pas. On a sûrement à faire à quelqu'un qui veut nous jouer un tour. Pour moi, il s'agit clairement d'un bogue dans le logiciel client SSH. --[ 4 - Une implémentation Il existe déjà quelques implémentations HDM pour SSH1 comme [dsniff] ou [ettercap]. Généralement, elles comprennent bien le protocole SSH1 et développent énormement d'efforts dans l'assemblage, le réassemblage ou le transfert des paquets. Les choses sont beaucoup plus simples. ssharp est basé sur un démon SSH normal qui a été modifié pour accepter toute paire de login/mot de passe et démarrer un shell spécial pour cette connexion: un client SSH qui reçoit le login/mot de passe et l'IP de la destination réelle. Il s'identifie sur l'hôte distant sans interaction de l'utilisateur et, puisqu'il est relié au pty du serveur HDM, cela donne l'impression à l'utilisateur qu'il est dans son shell normal. Il n'est donc pas nécessaire de chambouler les protocoles SSH1 ou SSH2 ou de remplacer les clefs, etc. Il suffit de jouer avec la bannière ou la négociation de l'algorithme de signature comme décrit ci-dessus. S'il est compilé avec l'option USE_MSS activée, ssharp fera passer le client SSH par une session comme avec le logiciel screen qui permet de joindre des tiers aux connexions SSH1 ou SHH2 existantes. Il est aussi possible d'éjecter l'utilisateur légitime et de prendre le contrôle total de la session. --[ 5 - Discussion Je sais, je sais. Il y a plein de gens qui vont dire "Bon, c'est tout?". Comme à chaque découverte, une ribambelle de gens vont affirmer qu'il s'agit d'une "sémantique UNIX standard" ou que c'est une caractéristique normale et non un bogue ou que cette vulnérabilité est complètement Théo...rique. Ce n'est pas le cas ici, et les gens qui recherchent uniquement les faiblesses dans les algorithmes de cryptage telles que la réutilisation du flux de clef et la possibilité d'injecter 2^64 ;-) textes bruts choisis et adaptés auront l'honneur de découvrir que, en 2002, l'analyse cryptographique privilégie la paresse et la mauvaise compréhension des brouillons. La paresse est déjà venue à bout d'Enigma, mais dans les prochaines années on se rendra compte des conséquences de l'incapacité des gens à bien comprendre les protocoles, ou de l'excès de confiance qu'ils mettent dans la cryptographie en oubliant les conséquences s'ils refusent de tenir compte du simple "DOIT" que l'on trouve dans la section 1.1.70.3.3.1.9.78. du brouillon du super cryptage. --[ 6 - Remerciements Les gens du consortium segfault point net ;-) pour leur discussion et leur mise à disposition d'environnement de test. Si vous désirez faire un don de matériel ou d'argent à ces personnes, faites le moi savoir. Cela permettrait sans aucun doute à la recherche sur ce sujet et d'autres du même ordre de continuer. Merci aussi aux nombreuses personnes ayant discuté de SSH avec moi. Cet article est aussi disponible [ici] sous forme de document pdf avec des captures d'écran pour démontrer la force de ssharp. --[ 7. Références [dsniff] autant que je sache, il s'agit de la première implémentation HDM sous SSH1 traitant des attaques dites "monkey-in-the-middle" appartenant au paquet dsniff. http://www.monkey.org/~dugsong/dsniff [ettercap] bon programme combinant renifleur/HDM pour les bidouilleurs paresseux ;-) http://ettercap.sourceforge.net [ssharp] implémentation des attaques décrites dans cet article http://stealth.7350.org/7350ssharp.tgz [ici] notre article en anglais au format pdf avec captures d'écran http://stealth.7350.org/ssharp.pdf |=[ EOF ]=---------------------------------------------------------------=|