L'algorithme utilisé dépend fortement du contexte, suivant que l'authentification se passe au niveau système ou au niveau réseau.
Deux algorithmes sont utilisés pour enregistrer de façon non-réversible les mots de passe des utilisateurs déclarés au niveau du système : LanMan et NTLM.
L'algorithme LanMan a été imposé par le protocole SMB utilisé dans les services réseau Windows. Le hachage repose aussi sur le chiffrement d'une chaîne connue par une clé générée à partir du mot de passe.
Ici, le mot de passe est tout d'abord tronqué à 14 caractères. S'il n'est pas assez long alors il est complété avec des caractères nuls. Puis il est mis en majuscules et divisé en deux parties de 7 caractères. Chaque partie est indépendamment utilisée comme clé de chiffrement DES à 56 bits pour chiffrer la chaîne "KGS!@#$%". Les deux résultats de 8 octets chacun sont concaténés pour donner l'empreinte LanMan de 16 caractères.
Les vulnérabilités de cet algorithme sont multiples. Tout d'abord les attaques sont limitées à 2 mots de 7 caractères et aucune différence n'est faite entre majuscules et minuscules. Les tests sont alors limités à 2*69^7 = 1,49E13 combinaisons au lieu des 96^14 = 5,65E27 auxquelles s'attend l'utilisateur, rendant aujourd'hui possible une recherche exhaustive en quelques mois sur n'importe quelle machine personnelle.
De plus, aucune graine n'étant utilisée, les attaques par dictionnaire pré-calculé sont réalisables. Enfin, une comparaison de la seconde partie de l'empreinte par rapport à une certaine constante montre si le mot de passe a une longueur maximale de 7 caractères.
L'algorithme NTLM a été introduit dans Windows NT 3.5 côté postes serveurs et dans Windows Millenium côté postes clients. Le mot de passe est tout d'abord limité à 128 caractères puis passé en Unicode, c'est-à-dire qu'après chaque caractère un caractère nul est inséré. Cette chaîne est passée à la fonction de hachage MD4 pour donner l'empreinte NTLM de 16 caractères.
Ce nouvel algorithme accepte donc des mots de passe de 128 caractères, mais surtout différencie majuscules et minuscules et supporte bien plus de caractères comme les lettres accentuées. Malheureusement, ici non plus, aucune graine n'est utilisée pour diversifier les empreintes.
Des problèmes ont rapidement été trouvés sur la fonction MD4, entrainant la création de MD5 et la découverte d'autres problèmes dans MD4. Néanmoins, attaquer un haché NTLM demande bien plus de temps que d'effectuer une recherche exhaustive sur l'empreinte LanMan. Il est de plus suspecté que le fait qu'un octet sur deux soit nul rende le haché MD4 plus vulnérable à la cryptanalyse, même s'il n'y pas aujourd'hui de façon d'exploiter cela. En fait, comme nous le verrons plus tard, il est des cas où la seule connaissance de l'empreinte suffit à s'authentifier à la place de l'utilisateur, le cassage du mot de passe étant alors un luxe.
Voir Figure 2 : Authentification locale
Vocabulaire : j'ai choisi les termes LanMan et NTLM par habitude. Dans la littérature les termes respectifs LM et NT ou ASCII et Unicode ou CaseInsensitivePassword et CaseSensitivePassword sont également lisibles.
Sur le réseau, l'algorithme utilisé dépend fortement du protocole applicatif utilisé entre le client et le serveur. Dans le cas d'un réseau Windows, l'authentification est fondée sur un protocole de type défi/réponse.
Le principe du défi/réponse est utilisé lorsque le mot de passe ne doit pas passer en clair sur le réseau. Le chiffrement de la session entière ou l'authentification par un système de clef publique/clef privée sont d'autres moyens mais ces méthodes ne sont généralement pas utilisées sur un réseau Windows. Un protocole défi/réponse est composé d'un échange de données entre le serveur et le client, afin que le client prouve au serveur qu'il connaît le mot de passe de l'utilisateur sans envoyer ce mot de passe en clair sur le réseau. Pour cela, à la connexion, le serveur envoie un défi au client. Le client utilise ce défi et le mot de passe entré par l'utilisateur pour calculer une réponse qu'il retourne au serveur. De son côté, le serveur a effectué la même opération avec le défi expédié au client et l'image du mot de passe contenu dans la base des utilisateurs. Il compare alors les résultats et considère que le mot de passe saisi par l'utilisateur est correct lorsque les résultats sont identiques.
Ce défi doit être unique à chaque connexion, de sorte que quelqu'un qui écoute le réseau ne puisse pas rejouer les données d'authentification capturées, c'est à dire mener une attaque par rejeu.
Dans le cas d'un réseau Windows, le défi est une chaîne aléatoire de 8 octets. Le serveur ne possédant que des empreintes du mot de passe de l'utilisateur, le client calcule une empreinte du mot de passe fourni par l'utilisateur. Cette empreinte de 16 octets est complétée de 5 octets nuls et divisée en 3 chaînes de 7 octets chacune. Chacune des 3 chaînes est indépendamment utilisée comme clé de chiffrement pour chiffrer le défi en DES. Les 3 chaînes résultats de 8 octets chacune sont concaténées pour former la réponse.
Voir Figure 3 : Authentification distante
Si ce protocole permet que le mot de passe ne circule pas en clair et que des données d'authentification capturées ne sont pas rejouables, il possède quand même quelques faiblesses importantes à connaître.
Tout d'abord, le serveur n'ayant pas accès au mot de passe en clair puisqu'il ne possède que des images non-réversibles du mot de passe, le client doit donc se mettre au même niveau que le serveur en calculant les empreintes du mot de passe fourni. Ainsi, le vol d'un fichier de mots de passe fournit la connaissance des empreintes, ce qui suffit à s'authentifier avec l'aide d'un client modifié. C'est pour cela qu'il est dit que les fichiers de mots de passe sous Windows contiennent des équivalents de mots de passe en clair, car même si le mot de passe ne peut pas être déduit immédiatement, l'authentification à la place de n'importe quel compte est possible. Il est à noter que ces systèmes de défi/réponse fondés sur les mots de passe sont vulnérables à ce type d'attaque si le système ne chiffre pas les empreintes.
Il est laissé comme exercice au lecteur d'écrire un patch à smbclient de quelques lignes considérant toute entrée d'un mot de passe de 32 caractères hexadécimaux comme une empreinte NTLM et l'utilisant avec le défi reçu du serveur pour calculer la réponse attendue.
Le calcul de la réponse ne dépendant que du mot de passe de l'utilisateur, la facilité de cassage du mot de passe à partir de la capture du défi et de la réponse ne dépend que de la force du mot de passe. Par exemple un mot de passe comme "toto" est trouvé en un dixième de seconde avec tout logiciel de cassage performant.
Le principe du défi/réponse impose que le défi soit unique à chaque connexion pour empêcher le rejeu. Bien sûr, des problèmes de mise en oeuvre existent comme sous Windows 95 où un nouveau défi n'est généré qu'une fois toutes les 30 minutes, laissant alors en moyenne 15 minutes à un pirate pour se reconnecter au même serveur Windows 95 avec les mêmes données d'authentification que celles qu'il vient de capturer sur le réseau.
Un dernier problème est que les postes clients Windows 9x ne possèdent pas les fonctions de calcul des empreintes NTLM, ce qui signifie que c'est l'empreinte LanMan qui est utilisée pour s'authentifier. Dans ce cas, un pirate qui écoute le réseau s'attaque au résultat LanMan avec un bon taux de succès si le mot de passe est relativement faible. Si les deux protagonistes possèdent les fonctions de calcul des deux types d'empreintes, le client utilise les deux pour calculer et envoie deux résultats à partir du défi du serveur. Cela est considéré comme une vulnérabilité puisque le pirate, en s'attaquant tout d'abord au résultat LanMan, bien plus faible, puis à l'autre résultat, obtient le mot de passe exact, c'est à dire avec la casse exacte. Le serveur ne vérifie que le résultat NTLM car l'empreinte NTLM est bien plus fidèle au mot de passe en clair.
Pour se protéger de certains outils s'attaquant à l'authentification réseau LanMan et NTLM, Microsoft a mis en oeuvre NTLMv2. Il s'agit en fait de l'algorithme HMAC-MD5 (voir la rfc2104) avec en prime erreur de mise en oeuvre... Normalement lorsque la longueur de la clé est supérieure à 64 bits alors le MD5 de la clé doit être utilisé commé clé. La version de Microsoft tronque simplement la clé aux 64 premiers bits.
Lorsqu'un utilisateur se connecte localement à un poste d'un domaine, le poste se connecte à l'un des contrôleurs du domaine sur le partage IPC$ en utilisant le mot de passe saisi pour vérifier son authentification. Si la connexion réussi alors le poste accepte l'authentification de l'utilisateur. Pour d'autres informations sur l'authentification sous Windows, voir dans ce numéro l'article de Jean-Baptiste Marchand "Modèle de sécurité du système Windows".