attaque par rebond

Le
Kevin Denis
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.

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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Erwan David
Le #23029341
Kevin Denis
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
Le #23029381
According to Kevin Denis
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
Le #23029431
Thomas Pornin
According to Kevin Denis
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
Le #23029561
Le 17-01-2011, Thomas Pornin
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 #23029551
Kevin Denis
Le 17-01-2011, Thomas Pornin
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"?



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.

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Kevin Denis
Le #23029881
Le 17-01-2011, Erwan David
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"?



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.



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
Le #23030341
According to 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"?



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
Publicité
Poster une réponse
Anonyme