Après avoir vu les méthodes classiques d'attaque voyons comment les contrer, tout d'abord en protégeant les mots de passe puis en les durcissant. La protection des mots de passe doit être réalisée à plusieurs niveaux : dans le système, sur le réseau et au niveau applicatif.
Au niveau système, une seule possibilité s'offre à nous : le chiffrement de la SAM. Cela est réalisable sous Windows NT avec une fonctionnalité optionnelle livrée depuis le service pack 2 de Windows NT 4 : syskey. Sur tous les systèmes Windows 2000, cette fonctionnalité est activée par défaut.
syskey effectue le chiffrement des empreintes grâce à une clé générée à partir d'un mot de passe choisi par l'administrateur. Ce mot de passe est nécessaire au démarrage du système afin que le programme lsass.exe puisse accéder normalement aux informations d'authentification. Ce mot de passe est soit stocké sur une disquette, soit caché dans la partition système, soit demandé à la console à chaque démarrage du système, celui-ci ne pouvant terminer son initialisation tant que le bon mot de passe n'aura pas été entré.
Si sur le disque les empreintes sont chiffrées, elles sont toujours accessibles déchiffrées à tous les utilisateurs possédant le droit de débogage (tous les développeurs et administrateurs). Le programme pwdump2 et son successeur récupèrent la SAM locale grâce à une "DLL Injection" sur le processus lsass.exe. Il s'agit de conduire le programme visé (lsass.exe) à appeler une fonction située dans une bibliothèque désignée par pwdump2. Dans le cas présent, cette fonction est celle qui permet à lsass.exe d'obtenir en mémoire la SAM en clair.
Un défaut de mise en oeuvre a été trouvé mi-décembre 1999 par Bindview. Après analyse de SAM chiffrées, il est apparu que les empreintes des utilisateurs étaient chiffrées en RC4. RC4 est un chiffrement fondé sur le XOR des données en clair avec une chaîne de codons (suite de nombres aléatoires). Cet algorithme est solide tant qu'un flux ne sert qu'à chiffrer un seul texte en clair. Or, Microsoft a utilisé le même flux pour chiffrer les deux empreintes LanMan et NTLM d'un utilisateur, ainsi que son historique.
Cette faille permet donc l'attaque des empreintes par force brute sans pour autant connaître la clé de chiffrement utilisée par le système : choisir un mot de passe potentiel, le chiffrer en LanMan et en NTLM, l'obscurcir tel qu'il le serait dans la SAM, puis effectuer un XOR entre ces deux empreintes calculées. Effectuer un XOR entre les empreintes chiffrées et comparer les résultats : si les résultats sont identiques, alors le mot de passe choisi est celui de l'utilisateur. Si cette attaque est bien plus lente que celle effectuée normalement sur l'empreinte LanMan, puisque ces calculs doivent être effectués pour chaque utilisateur, avec une base de plusieurs dizaines d'utilisateurs, elle donne un mot de passe assez rapidement.
De plus, Bindview a trouvé que la clé de chiffrement RC4 est fondée sur le numéro de l'utilisateur (pour être précis le MD5 de la concaténation du mot de passe syskey sur 128 bits et de 4 octets du RID), ce qui accélère encore l'attaque précédente...
Depuis le service pack 2 de Windows 2000 et sur Windows XP, la sauvegarde des mots de passe au format LanMan dans la SAM est désactivable grâce à la clé de registre NoLMHash. Il faut alors s'assurer que tous les clients sont compatibles NTLMv1 : voir l'article "How to Disable LM Authentication on Windows NT" à l'URL <http://support.microsoft.com/support/kb/articles/q299/6/56.asp>
S'il est important de protéger ses mots de passe sur le réseau, il est aussi important de savoir pourquoi, afin ne pas confondre moyen et but. La principale raison est simplement le grand nombre de renifleurs spécialisés dans l'écoute et l'extraction des mots de passe qui passent en clair sur les réseaux locaux ou distants.
Aujourd'hui encore, de très nombreux protocoles envoient leurs mots de passe en clair sur le réseau, les plus utilisés étant FTP, Telnet, POP, IMAP, SMTP, etc. De nombreux programmes, sous Unix comme sous Windows, arrivent très facilement à construire des bases d'authentification à partir de l'écoute de ces flux.
Plusieurs programmes récupèrent les couples défi/réponse SMB : readsmb2.c et L0phtCrack 2.x.
Le programme aujourd'hui le plus connu est dsniff <http://naughty.monkey.org/~dugsong/dsniff/> développé par Dug Song. Il capture les mots de passe en clair (ou obscurcis) dans plus de 30 protocoles : FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, NFS, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec, NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase et Microsoft SQL auth info.
La manière la plus classique de se protéger au niveau réseau contre l'écoute est en général d'utiliser des commutateurs (switches) à la place des répéteurs (hubs) afin que seuls l'expéditeur et le destinataire puissent avoir accès à une donnée sur le réseau. dsniff contient plusieurs autres outils afin d'aider à l'interception des informations dont arpspoof qui permet d'écouter même sur un réseau commuté. De plus, dsniff contient une documentation très complète et une FAQ expliquant de nombreuses vulnérabilités, les attaques et les façons de s'en protéger.
dsniff méritant à lui seul un article, il est fortement conseillé d'aller lire ses documentations, des traductions françaises étant disponibles : cela vaut réellement le temps investi.
Sur un réseau Windows, le principal protocole à surveiller est SMB. Le durcissement nécessaire à la protection de ses mots de passe requiert "seulement" la modification de chaque serveur et de chaque poste client.
Il faut tout d'abord interdire sur chaque client l'envoi du mot de passe en clair sur le réseau, la clé de registre dépendant de la version du système :
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ VxD\VNETSUP] "EnablePlainTextPassword"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Rdr\Parameters] "EnablePlainTextPassword"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ LanmanWorkStation\Parameters] "EnablePlainTextPassword"=dword:00000000
Il faut ensuite, sur chaque serveur, limiter le chiffrement le plus faible à NTLMv1, ou NTLMv2 à partir du service pack 4 de Windows NT 4, voir l'article "How to Disable LM Authentication on Windows NT" à l'URL <http://support.microsoft.com/support/kb/articles/q147/7/06.asp> pour les différentes explications de mise en oeuvre.
Microsoft est tellement content de son système de défi/réponse NTLM, qu'il l'a porté dans plusieurs protocoles ouverts comme HTTP, IMAP, LDAP, NNTP et POP3, rendant alors ses serveurs incompatibles avec nombre de clients d'éditeurs concurrents lorsque l'administrateur du serveur rend obligatoire cette option.
L'avantage principal est bien sûr que le mot de passe n'est plus envoyé en clair sur le réseau lorsque ces protocoles sont utilisés, cela ne fonctionnant bien sûr qu'entre un client et un serveur édités par Microsoft.
Comme nous l'avons vu avec l'authentification SMB, la base d'authentification du serveur contient des équivalents de mots de passe en clair, utilisables par tout pirate avec l'aide d'un client modifié pour s'authentifier à la place de n'importe qui. Cette extension NTLM possède exactement le même problème. Elle procure donc un faux sentiment de sécurité auprès des utilisateurs et des administrateurs.
De plus, si cela protège les mots de passe solides d'être volés sur le réseau, les mots de passe simples sont très facilement cassés à partir de couples défi/réponse capturés.
Il existe plusieurs ressources sur Internet pour effectuer de l'authentification NTLM ou "jouer" avec :
La seule application Windows abordée aujourd'hui est frontpage. Il est nécessaire de protéger les fichiers *.pwd par des ACL (listes de contrôle d'accès) ne donnant accès à ces fichiers qu'aux administrateurs et au système, et en aucun cas aux comptes utilisés par IIS.
Dans le prochain article, plusieurs applications seront étudiées. Généralement utilisées aussi bien sous Windows que sous Unix, les solutions mettront en place aussi bien de l'authentification forte que du chiffrement fort, parfois avec de l'encapsulation.