Version txt, cet article a été traduit très gentillement par Thiébaud Weksteen.
==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 ]=---------------------------------------------------------------=|