Tranchant comme un couteau. SSHarp.

                             ==Phrack Inc.==

               Volume 0x0b, Issue 0x3b, Phile #0x0b of 0x12


|=--------------=[ Tranchant comme un couteau. SSHarp. ]=----------------=|
|=----------------=[ (It cuts like a knife. SSHarp.) ]=------------------=|
|=-----------------------------------------------------------------------=|
|=----------------=[ stealth <stealth@segfault.net>  ]=------------------=|
|=------=[ Traduit par Thiébaud Weksteen <tweksteen@gmail.com>  ]=-------=|

--[ 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 ]=---------------------------------------------------------------=|