mot de passe windows
Alain.Maurice
les mots de passe sur les sytèmes windows NT semblent divisés en blocs de 7
caractères et chiffrés indépendamment les uns des autres.
quel interet ?
Antoine BELLOT
Marc SCHAEFER
Evaluation de sécurité SMB
Marc SCHAEFER <scha...@alphanet.ch>
corrections et ajouts de Frederic Schutz <sch...@mathgen.ch>
$Id: eval_secu,v 1.4 2001/02/02 08:58:55 schaefer Exp $
1. Introduction
Ce court document a pour but de commenter le système
d'authentification (identification), ou de chiffrement, disponible
avec Samba sous UNIX (et peut-être discuter de l'interopérabilité avec
le monde Windows, des ajouts UNIX et des ajouts propriétaires Windows
en rapport avec la sécurité).
2. Description de l'authentification SMB
2.1. Sans mots de passe `cryptés'
Les mots de passe circulent en clair sur le réseau; il est possible
d'authentifier les utilisateurs avec le système UNIX usuel standard:
celui-ci calcule l'empreinte du mot de passe et de la graine (salt)
aléatoire stockée dans /etc/shadow, et vérifie le résultat avec
l'empreinte stockée dans ce même fichier. Le calcul d'empreinte,
ci-après `hâchage', consiste en l'application d'une fonction spéciale
qui n'est pas inversible dans un temps inférieur au parcours d'une
partie significative de l'espace de recherche (fonction trappe,
p.ex. plusieurs fois DES ou MD5).
DANS TOUS LES CAS (QUE JE CONNAIS) LES DONNEES SONT TRANSMISES EN CLAIR!
sauf: UNIX/Samba + mode SSL (compatible UNIX/Samba seulement)
peut-être aussi: Kerberos Windows 2000 (à vérifier)
2.2. Avec mots de passe `cryptés'
2.2.1 Stockage du mot de passe et algorithme de hâchage
Samba supporte deux systèmes: l'ancien, Lan Manager et le nouveau (ou
pas trop ancien), Windows NT. Dans les deux cas, l'utilisation du mot
`cryptés' est abusive: il s'agit en fait de calcul d'empreinte, avec
lequel il est quasiment impossible de retrouver le mot de passe
original en ne connaissant que l'empreinte, alors qu'il est toujours
possible de le faire dans le cas d'un vrai chiffrement.
Ce genre de méthodes est considéré comme faible, car si l'accès au
fichier des mots de passe est possible (à cause d'un trou de sécurité
par exemple), un pirate pourra facilement faire une recherche
exhaustive pour essayer de trouver un mot de passe. Les utilisateurs
ayant souvent tendance à utiliser des mots de passe simples à deviner,
cette attaque est souvent efficace.
2.2.1.1 Cas 1: Mots de passe `cryptés' Lan Manager
Dans ce système, la fonction de hâchage suit une méthode similaire à
celle des mots de passe UNIX standards (avec la différence qu'il n'y a
pas de graine, donc l'espace de recherche exhaustive est plus petit).
On prend le mot de passe de l'utilisateur, on le met en majuscules, et
on s'arrange pour que le résultat fasse 14 caractères (en tronquant ou
en ajoutant des NULs, valeur ASCII 0). 14 caractères correspond à 2 x
7 x 8 bits, soit deux clés DES de 56 bits. On prend une valeur magique
de 8 caractères (fixée, mais cela n'est pas très clair), qui est
cryptée séparément par chacune des deux clés formant deux chaînes
chiffrées de 8 bits chacune, soit 16 caractères. Ces 16 caractères
sont stockés par le client et le serveur. Cette valeur est l'empreinte
du mot de passe.
2.2.1.2 Cas 2: Mots de passe `cryptés' Windows NT
La fonction de hashage utilisée est MD4, le prédécesseur de MD5, qui
opère sur le codage Unicode du mot de passe utilisateur. Plusieurs
trous de sécurité ont été découverts dans MD4, ce qui fait que cette
fonction n'est plus considérée comme sûre, et cette méthode devrait
absolument être évitée.
2.2.2 Fonctionnement CHALLENGE/RESPONSE
Dans les deux cas, l'authentification fonctionne selon un système
`challenge-response', similaire à CHAP ou PAP pour PPP, qui est conçu
pour notamment éviter les `replay-attacks', c'est-à-dire faire en
sorte qu'il soit impossible à quelqu'un de se connecter sans connaître
le mot de passe, même s'il a pu écouter et analyser un grand nombre de
transactions légitimes auparavant.
Cela fonctionne ainsi:
- le serveur envoie 8 caractères aléatoires (soit 64 bits) et les
stocke pour vérification ultérieure (CHALLENGE)
- le client utilise le mot de passé hâché (16 bytes, soit 128 bits),
plus 5 bytes à zéro (soit 40 bits), donc un total de 168 bits, comme
3 clés 56 bits DES, chacune chiffrant les 8 caractères aléatoires du
challenge, formant 24 bytes qu'il renvoie au serveur (RESPONSE)
- le serveur Samba vérifie en utilisant la valeur aléatoire connue et
la version hâchée du mot de passe.
Problèmes de cette approche:
- à chaque échange, l'attaquant connaît un texte chiffré supplémentaire,
et pourrait, du moins en théorie, savoir de plus en plus de choses sur
la clé de chiffrement, c'est-à-dire le mot de passe hâché. Ce risque
est quasiment inexistant, car d'autres attaques, basées p.ex. sur le
"paradoxe des anniversaires" sont plus probables (pour les détails
mathématiques, voir les annexe A et B). Néanmoins, une façon d'éviter
le problème est de changer le mot de passe de façon sécurisée
(smbpasswd sur le serveur UNIX via ssh).
- pour se connecter au serveur, le hâchage du mot de passe est en fait
suffisant: l'attaquant n'a pas besoin de connaître le mot de passe
réel. Dans ce cas, pourquoi hâcher et ne pas utiliser directement le
mot de passe original ? Un procédé fréquemment utilisé en cryptographie
pour rendre les clés équiprobables et de longueur fixe est d'effectuer
un hâchage. Cela a l'avantage également de la vitesse (pré-hâchage).
D'autres raisons pourraient être: éviter de stocker le mot de passe
en clair sur le client et le serveur ce qui devrait limiter les risques
si par exemple le mot de passe UNIX est le même que celui du serveur
SMB: ce système permet alors de ne pas compromettre
le protocole SSH qui est plus sûr, simplement en lisant le fichier
des mots de passe du client Windows. Ou bien cela évite les problèmes
sociaux genre le mot de passe de l'employé X qui est le nom de la
femme de Y :)
- comment changer le mot de passe ? Une idée pourrait être d'utiliser
l'ancien hâchage pour chiffrer le nouveau hâchage. Ce qui pose la question
du mot de passe initial: une idée est: UNIX + SMB + SSH + smbpasswd
:) (ou utiliser SSL ... UNIX seulement). Cela est un problème
complexe en général.
Donc, finalement, ce n'est pas si sûr que l'on voudrait nous faire
croire. Certains systèmes, comme Kerberos stockent les mots de passe
*non chiffrés* sur le serveur d'authentification (ou, au mieux,
chiffrés avec le mot de passe du serveur d'authentification, qui est
disponible quand le serveur fonctionne).
Le challenge-response fonctionne alors de la même manière sauf que le
challenge aléatoire, additionné à une valeur temporelle choisie par le
serveur, est chiffré par le mot de passe en clair, qui doit être donné
une fois par l'utilisateur, puis oublié pendant la session:il est
remplacé par un ticket.
Ce ticket est envoyé par le serveur d'authentification et est chiffré
par le mot de passe et n'a qu'une durée de validité limitée (ce qui
évite d'éventuelles replay-attacks en cassant DES avec du matériel
rapide). Le changement de mot de passe se fait en chiffrant le nouveau
mot de passe avec le ticket déchiffré par le mot de passe ancien.
Kerberos est notamment supporté sous divers UNIX mais aussi Linux avec
divers systèmes comme Kerberos 4, 5 ou heimdal, ou p.ex. sur Windows
2000, plus ou moins standard dans ce dernier cas.
Au vu de ce qui précède, Kerberos, bien que n'utilisant pas non plus
de technologie à clé publique, est plus sûr. Mais il est aussi
beaucoup plus complexe.
Annexe A: Perte du secret (Information leak)
On a vu que si l'on écoute toutes les transactions
(challenge/response), on va obtenir de plus en plus d'informations sur
le hâchage du mot de passe.
Néanmoins, pour que cela serve, il faut réussir à attaquer DES avec
ces informations. Or, la meilleure attaque connue contre DES exige de
connaître 2^47 couples de texte clair/texte chiffré, donc avoir écouté
(!) et stocké (!!!) autant de transactions. Mais, par le paradoxe des
anniversaires (voir Annexe B), après seulement (!) 2^32 transactions
(SQRT(possibilité de challenges), soit environ 1 milliard)
attaquant aura plus d'1 chance sur 2 de pouvoir faire une
replay-attack, ce qui rend négligeable la probabilité d'une attaque
directe sur DES. L'attaquant ne sait donc rien de plus sur le hash,
mais ça ne change pas la conclusion comme quoi il faut changer le mot
de passe après un moment.
Annexe B: Paradoxe des anniversaires
Problème: soit 23 personnes dans une salle. Quelle est la probabilité
que 2 d'entre elles aient leur anniversaire le meme jour ?
Réponse: 0.5 ou plus (50% ou plus)
Idée générale: si l'on tire aléatoirement au moins SQRT(x) valeurs
d'une fonction qui a x valeurs possibles, alors il y a plus d'une
chance sur deux d'avoir deux tirage identiques.
Applications:
- il y a 365 dates dans l'année, SQRT(365)=~ 20, donc si 20 personnes
sont dans une salle, il y a 50% de chance pour que deux d'entre elles
aient leur anniversaire le même jour.
- si une fonction Hash peut donner 2^x valeurs possibles, il suffit de
calculer 2^(x/2) hash de textes différents (soit la racine de nombre de
valeurs) pour avoir une chance sur deux de tomber sur deux textes qui
donnent le meme hash.
- si on exécute des challenges/response avec un challenge de 64 bits,
donc 2^64 challenges possibles, la sécurité ne sera que de 2^(64/2)=2^32,
car à partir de ce nombre d'échanges, il y a de fortes chances qu'on
retrouve deux fois le meme.
Ca diminue de beaucoup la sécurité du tout: globalement, à cause de
ça, on considère comme peu sûre une hash function qui travaille sur
moins de 160 bits, ou un challenge/response qui se fait sur moins de
bits.
SOURCE pour l'analyse de SMB: /usr/share/doc/samba-doc/ENCRYPTION.txt.gz
Version: (2.0.7)