attaque par rebond
Kevin Denis
je m'intéresse à ssh et j'ai constaté cela dans la RFC:
http://www.ietf.org/rfc/rfc4252.txt
8. Password Authentication Method: "password"
Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8.
Donc le mot de passe est envoyé en clair (dans un canal chiffré,
toutefois); ceci est confirmé par:
Note that even though the cleartext password is transmitted in the
packet, the entire packet is encrypted by the transport layer.
Ce qui signifie que si je met en place un faux serveur ssh, je
peux récupérer très facilement le couple login/pass d'un utilisateur!
(Utilisateur suffisement distrait au point de ne pas se rendre compte
que la clé de l'hôte distant à changé[1]).
Ma question est la suivante: pourquoi avoir laissé transiter le
mot de passe en clair, et non pas demander un hash (ou un autre
procédé crypto, lequel?) de celui-ci afin que l'attaquant qui
mette en place ce type de serveur ne récupère pas le password en
clair. Ceci semblerait plus sûr en première analyse.
Mais à la réflexion, rien n'empêche l'attaquant d'ouvrir en parrallèle
une connexion vers le véritable serveur ssh et faire suivre les
requêtes imaginables au paragraphe précédent. Ceci complexifie le
code de l'attaquant, mais reste possible. Ce qui revient à dire que
demander un hash au lieu d'un mot de passe en clair ne sécurise pas
réellement la connexion du client! Et donc, autant envoyer en clair
le mot de passe...
Donc, est il possible de mettre en place une méthode afin qu'un
attaquant ne puisse pas interférer sur une connexion ssh, ou à tout
le moins ne pas récupérer le mot de passe de l'utilisateur?
N'y a t'il pas de solution pour protéger le mot de passe de
l'utilisateur distrait?
Merci
[1]Exemple constaté de très nombreuses fois, les users se connectent
depuis windows avec putty qui prévient que la clé de l'hôte change,
et permet de se connecter tout de même en cliquant OK, ce que font
tous les utilisateurs, mais c'est un autre débat.
--
Kevin
Erwan David
> Bonjour,
>
> je m'intéresse à ssh et j'ai constaté cela dans la RFC:
> http://www.ietf.org/rfc/rfc4252.txt
> 8. Password Authentication Method: "password"
> Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8.
> Donc le mot de passe est envoyé en clair (dans un canal chiffré,
> toutefois); ceci est confirmé par:
> Note that even though the cleartext password is transmitted in the
> packet, the entire packet is encrypted by the transport layer.
> Ce qui signifie que si je met en place un faux serveur ssh, je
> peux récupérer très facilement le couple login/pass d'un utilisateur!
> (Utilisateur suffisement distrait au point de ne pas se rendre compte
> que la clé de l'hôte distant à changé[1]).
>
> Ma question est la suivante: pourquoi avoir laissé transiter le
> mot de passe en clair, et non pas demander un hash (ou un autre
> procédé crypto, lequel?) de celui-ci afin que l'attaquant qui
> mette en place ce type de serveur ne récupère pas le password en
> clair. Ceci semblerait plus sûr en première analyse.
Ben ça dépend des backend d'authentification, mais tu en a quand même de
très utilisés qui demandent le mot de passe en clair. (les mot de passe
Unix traditionnels par exemple).
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Thomas Pornin
> Donc, est il possible de mettre en place une méthode afin qu'un
> attaquant ne puisse pas interférer sur une connexion ssh, ou à tout
> le moins ne pas récupérer le mot de passe de l'utilisateur?
> N'y a t'il pas de solution pour protéger le mot de passe de
> l'utilisateur distrait?
Dans le cas général, ça existe : ce sont les protocoles dits PAKE
(Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au
lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange")
décrit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publié
par Wu en 1998. Un protocole PAKE comporte un échange de clé "classique"
et n'a pas besoin d'être joué dans un tunnel pré-établi. Les
caractéristiques sont assez "magiques" : à l'issue du protocole, le
client et le serveur se sont authentifiés mutuellement, relativement à
leur connaissance du mot de passe, et ont une clé secrète commune de
forte entropie (qu'on peut utiliser pour chiffer symmétriquement la
suite de la conversation). Néanmoins, un faux serveur ou un faux client
n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi
que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute même
une propriété intéressante, qui est que le serveur n'a pas besoin de
stocker le mot de passe, seulement une forme "hachée" (mais pas avec
n'importe quelle fonction de hachage).
SRP est intégré dans SSL/TLS, cf RFC 5054 :
http://tools.ietf.org/html/rfc5054
(on attend que les browsers Web veuillent bien l'implémenter).
Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
que ça tombe sur les mêmes mots de passe que les mots de passe Unix
pourrait être compliqué.
--Thomas Pornin
(*) Bellovin et Merritt ont déposé un brevet, qui devrait se terminer
l'an prochain, en 2012. Il est possible que le domaine soit un peu
"miné". GnuTLS implémente TLS+SRP et l'existence potentielle de brevets
n'a pas l'air de les troubler outre mesure.
Erwan David
> According to Kevin Denis <ke...@alinto.comNOSPAM>:
>> Donc, est il possible de mettre en place une m�thode afin qu'un
>> attaquant ne puisse pas interf�rer sur une connexion ssh, ou � tout
>> le moins ne pas r�cup�rer le mot de passe de l'utilisateur?
>> N'y a t'il pas de solution pour prot�ger le mot de passe de
>> l'utilisateur distrait?
>
> Dans le cas g�n�ral, �a existe : ce sont les protocoles dits PAKE
> (Password-Authenticated Key Exchange -- parfois, on dit "Agreement" au
> lieu de "Exchange"). Le premier est EKE ("Encrypted Key Exchange")
> d�crit par Bellovin et Merritt en 1992(*). Le plus connu est SRP, publi�
> par Wu en 1998. Un protocole PAKE comporte un �change de cl� "classique"
> et n'a pas besoin d'�tre jou� dans un tunnel pr�-�tabli. Les
> caract�ristiques sont assez "magiques" : � l'issue du protocole, le
> client et le serveur se sont authentifi�s mutuellement, relativement �
> leur connaissance du mot de passe, et ont une cl� secr�te commune de
> forte entropie (qu'on peut utiliser pour chiffer symm�triquement la
> suite de la conversation). N�anmoins, un faux serveur ou un faux client
> n'apprend pas le mot de passe ni m�me un hash du mot de passe ou quoi
> que ce soit qui permette d'"essayer" des mots de passe. SRP rajoute m�me
> une propri�t� int�ressante, qui est que le serveur n'a pas besoin de
> stocker le mot de passe, seulement une forme "hach�e" (mais pas avec
> n'importe quelle fonction de hachage).
>
> SRP est int�gr� dans SSL/TLS, cf RFC 5054 :
> http://tools.ietf.org/html/rfc5054
> (on attend que les browsers Web veuillent bien l'impl�menter).
>
> Un ennui vis-�-vis des mots de passe Unix est qu'un serveur Unix ne
> stocke pas les mots de passe, ni leur hach� � la sauce SRP, mais une
> forme d�riv�e avec salt. Donc, int�grer SRP dans SSH et s'arranger pour
> que �a tombe sur les m�mes mots de passe que les mots de passe Unix
> pourrait �tre compliqu�.
>
>
> --Thomas Pornin
Tr�s int�ressant, mais en tant qu'admmin, j'ajoute qu'il va falloir
pouvoir int�gr� �a � du kerberos, ou de l'authentification LDAP, etc...
Bref �a va pas �tre simple.
--
Le travail n'est pas une bonne chose. Si �a l'�tait,
les riches l'auraient accapar�
Kevin Denis
> Néanmoins, un faux serveur ou un faux client
> n'apprend pas le mot de passe ni même un hash du mot de passe ou quoi
> que ce soit qui permette d'"essayer" des mots de passe.
C'est effectivement le but que je recherche.
> SRP est intégré dans SSL/TLS, cf RFC 5054 :
> http://tools.ietf.org/html/rfc5054
> (on attend que les browsers Web veuillent bien l'implémenter).
>
Je vais lire, merci.
> Un ennui vis-à-vis des mots de passe Unix est qu'un serveur Unix ne
> stocke pas les mots de passe, ni leur haché à la sauce SRP, mais une
> forme dérivée avec salt. Donc, intégrer SRP dans SSH et s'arranger pour
> que ça tombe sur les mêmes mots de passe que les mots de passe Unix
> pourrait être compliqué.
>
Trivialement, rien n'empêche le serveur de fournir le salt au client,
qui va s'en servir pour hacher son mot de passe afin que les deux
s'en servent comme mot de passe "SRP"?
--
Kevin
Erwan David
Le salt ne changeant pas à chaque fois, il est trivial pour un attaquant
de rejouer la session d'authentification et d'accéder au serveur.
--
Kevin Denis
>> Trivialement, rien n'emp�che le serveur de fournir le salt au client,
>> qui va s'en servir pour hacher son mot de passe afin que les deux
>> s'en servent comme mot de passe "SRP"?
>
> de rejouer la session d'authentification et d'acc�der au serveur.
>
Apparemment, non, puisque SRP est cens� emp�cher cela.
Si je lis bien ce que dis Thomas Pornin, c'est que SRP a besoin de
connaitre le mot de passe, � tout le moins le hach� SRP du mot de passe.
Comme UNIX stocke ses mots de passe � sa mani�re, SRP est difficilement
compatible avec celui-ci.
Qu'a cela ne tienne, utilisons le hach� UNIX comme mot de passe qui va
servir � l'authent SRP, apr�s tout. SRP ayant besoin qu'un serveur et
qu'un client connaissent un mot de passe, qu'est ce qui emp�che
d'utiliser le hach� unix? Le serveur connait le hach� UNIX, c'est le
deuxi�me champ de /etc/shadow. Le client ne connait pas son
hach�, mais conna�t son mot de passe, ce qui lui permet de calculer
le hach�, pour peu qu'on lui fournisse le salt.
Et donc un attaquant verra peut-�tre passer un salt, mais c'est � peu
pr�s tout.
--
Kevin
Thomas Pornin
> qui va s'en servir pour hacher son mot de passe afin que les deux
> s'en servent comme mot de passe "SRP"?
C'est théoriquement possible. Échanger la salt "en clair" n'est pas
un problème de sécurité ; ensuite, c'est le mot de passe Unix haché
qui sert lui-même de mot de passe pour SRP.
Suivant le protocole, ça peut nécessiter des messages supplémentaires,
donc de la latence. Le client doit d'abord dire qui il est ; le
serveur peut alors lui renvoyer sa salt, et là seulement le client
peut fabriquer son message.
Sinon, comme le fait remarquer Erwan, ça va mal fonctionner avec des
choses comme Kerberos ou LDAP. Sur un Unix avec du LDAP (du moins tel
que je l'ai pratiqué), le serveur LDAP connaît le mot de passe et exige
sa présentation pour authentifier l'utilisateur -- le serveur, lui, ne
peut pas obtenir le mot de passe ou même un haché du mot de passe de
façon préalable... Bref, si le concept PAKE est intéressant d'un point
de vue sécurité, il ne s'intègre pas très bien dans un environnement
Unixoïde qui a déjà son propre écosystème de gestion de mots de passe.
--Thomas Pornin