 Sécurité de la base SAM sur les serveurs Windows 2000 non contrôleur de domaine
Accueil > Articles > Système
|
|
|
 |
86093
66/284
|
Introduction
Depuis le tout début de l’informatique, le besoin d’établir
une « relation de confiance » entre l’utilisateur et le système informatique
s’est fait sentir.
La personne physique connectée au système informatique
devait pour cela être identifiée. Cette personne identifiée par un mécanisme
adapté pouvait ensuite agir sur les différents éléments du système
d’information.
Le besoin d’authentification
L’identification de la personne physique connectée au
système est-il un mécanisme suffisant ? Evidemment non ! La personne
physique qui désire interagir avec le système doit dans un premier temps
décliner son identité, elle doit ensuite prouver cette identité. Le fait
de fournir une preuve de son identité est l’authentification.
La méthode d’authentification la plus simple, qualifiée
aussi d’authentification faible, consiste à fournir au mécanisme
d’authentification un secret que la personne physique et le mécanisme
d’authentification sont les seuls à détenir. On parle alors de secret partagé.
Ce secret n’est ni plus ni moins que le mot de passe associé a l’utilisateur du
système.
Principe : Si l’utilisateur détient un secret,
et qu’il a lors de son authentification fourni ce
secret au système en charge de l’authentification, on en déduit qu’il est bien
la personne physique qu’il prétend être.
La problématique
Un rapide coup d’œil sur
le dessin ci–dessus nous montre que pour mettre en œuvre un mécanisme
d’authentification solide, nous devrons impérativement respecter trois règles
essentielles :
·
Une confidentialité du mot de passe
de la part de l’utilisateur
·
Une confidentialité au niveau du
protocole d’authentification
·
Une confidentialité au niveau de la
base de données d’authentification
Le premier document
s’attachera à apporter une vision pertinente des différentes méthodes adoptées
par la société Microsoft afin de garantir la confidentialité de la base de
données d’authentification.
Dans un second document,
nous parlerons plus précisément des protocoles d’authentification et nous
ferons une étude sur leur niveau de confidentialité et de solidité.
La base d’authentification versus
Microsoft
Les systèmes
d’exploitation de la société Microsoft, Windows NT 4.0 et Windows 2000 possèdent
un ensemble de composants de sécurité qui constituent le sous système de
sécurité. On distingue parmi ces composants :
·
L’autorité de sécurité locale ou LSA
·
Le service Netlogon
·
L’authentification NTLM et Kerbéros (Windows 2000)
·
Le gestionnaire des comptes de
sécurité ou SAM
C’est ce gestionnaire
des comptes de sécurité qui est l’objet de notre étude.
La base de registre
Afin de centraliser toutes les informations nécessaires à la
machine, à l’utilisateur, au système et aux applications, l’éditeur Microsoft a
centralisé toutes ces données dans une base de données appelée le registre.
Nous visualisons grâce à l’outil « éditeur du
registre » les différentes clés principales constituant la base de
données. Nous remarquons que sous la clé Hkey_local_Machine
se trouve les sous-clés SAM et SECURITY, objet de
toutes les convoitises des pirates.
Où se trouve le gestionnaire de compte?
La sous clé SAM ou Sécurité Account Manager est la base de données des comptes. Cette
base contient le nom des utilisateurs, leur identifiant de sécurité ou SID
ainsi que leur mot de passe
Exemple : le compte Administrateur à pour SID 000001F4
Et la confidentialité dans tout
cela ?
Comme nous pouvons le
constater, les mots de passe ne se trouvent pas inscrit en clair dans la
base SAM. Microsoft apporte à ces mots de passe une confidentialité grâce à la cryptographie.
Les mots de passe sont
inscrits dans la base de registre après avoir subi un chiffrement.
Le même mot de passe est
chiffré de deux façons différentes.
·
Afin de conserver une
authentification compatible avec les anciens clients Microsoft le mot de passe
sera chiffré une première fois avec un algorithme DES d’une
longueur de 56 bits. De plus avant chiffrement, le mot de passe sera
converti en majuscules. Cette méthode est due au fait que la couche Netbios ne fait pas de distinction entre les majuscules et
les minuscules. Cette méthode de chiffrement que l’on peut qualifiée de faible
est nommé LanMan Hash.
·
Le mot de passe sera chiffré une
seconde fois avec un algorithme de type MD4. Cette fois-ci le mot de passe ne
subira aucune modification. Cette méthode de chiffrement plus forte que celle
précédemment décrite se nomme NT Hash
Voici un exemple
Voici l’extraction complète de la sous-clé grâce à la fonction
d’exportation de clé de registre inclus dans l’outil “Editeur de registre”
Etude de la vulnérabilité
En étudiant bien le problème de la confidentialité de cette base
de données, nous pouvons affirmer plusieurs choses.
Les outils de pirate que je viens d’utiliser pour visualiser
les informations secrètes de la base de registre sont tous des outils dédiés à
Windows NT 4.0, certains concepts liés à l’outil sont même antérieurs à cette
version 4.0.
Alors, malgré les efforts apportés par l’éditeur Microsoft
en terme de sécurité dans la version Windows 2000, pourquoi tous ces outils de
« pirate » sont encore redoutables d’efficacité.
Tout d’abord le choix de l’éditeur est d’assurer une
compatibilité avec des versions anciennes voire préhistoriques.
Le tribut à payer est lourd de conséquences, on trouve
dans la base de données, un chiffrement faible, vulnérable, connu
de tous, une mise en œuvre déroutante de simplicité,
en un mot un « panier percé ». Les craqueurs de mot de passe vont
bien sûr se précipiter sur cette aubaine afin de percer l’ultime secret de la
défense du système, le mot de passe de l’administrateur.
Malgré un mot de passe complexe pour l’utilisateur Alain ( Alain1234 ), il a fallu à l’utilitaire L0phtCrack,
quelques secondes pour trouver les 2 derniers caractères du mot de passe. Il
faudra moins d’une journée à mon PII 300 Mhz pour casser le mot de passe,
quelques heures suffiront à un ordinateur doté d’un Pentium IV.
On voit clairement dans le cas présent, que l’outil s’attaque au chiffrement LanMan.
En second lieu, la structure de la SAM reste semblable à
celle que l’on retrouve dans la version NT 4.0, alors la communauté hostile à
Microsoft revendique haut et fort le manque de robustesse des mots de passe
dans la nouvelle version Windows 2000, et fait constater, preuves à l’appui le
manque de progrès de la part de Microsoft en matière de sécurité.
Les véritables constatations
La première contre-attaque de Microsoft visant à pallier au
manque de confidentialité de la SAM est apparue dans Windows NT 4.0. Le
concept est simple, tout le contenu de la SAM est chiffré par une clé générée
aléatoirement par le système et stocké dans un endroit sûr à l’abri des regards
indiscrets sur l’ordinateur, ou bien stocké sur une disquette, ou alors
dernière possibilité dérivée d’un mot de passe connu de l’administrateur.
On constatera que contrairement à NT 4.0, syskey, en version Windows 2000, est activée par défaut et
que la désactivation de la fonction n’est pas possible.
La contre attaque n’a pas tardé. La première est un
utilitaire du nom de Pwdump. Notons que cet
utilitaire fonctionne avec les privilèges « Administrateur » et que
son utilisation en fait plus un outil d’administration
qu’un outil de craquage de mots de passe.
Il reste cependant une attaque efficace, une petite
disquette contenant un mini système linux. Cet utilitaire « chntpw » permet la modification de tous les mots de
passe, y compris celui de l’administrateur et
ce malgré la protection par syskey.
Cette disquette est efficace sur tous les systèmes NT 4.0 et
Windows 2000, avec toutefois une exception pour les contrôleurs de domaine.
Mais prudence, eux aussi possèdent une SAM locale présente pour assurer une
ouverture de session locale en cas de défaillance d’Active Directory.
Peut-on mieux protéger notre SAM ?
Une brève analyse de la console sur les stratégies de
sécurité locale attire notre attention.
Nous pouvons demander à notre serveur de refuser les
authentifications faible de type LM ( Lan
Manager). Certes, mais ce paramètre concerne le protocole d’authentification et
non pas le chiffrement de la SAM. Tentons tout de même et voyons si la SAM s’en
trouve modifiée.
Edition
de la base de registre avant la désactivation de Lan
Man dans les stratégies
Edition
de la base de registre après modification du paramètre
Les
mots de passe chiffrés en LanMan sont toujours
présents dans la base SAM
Alors que peut-on faire ? Le
conseil du jour
Définissons pour le compte de l’administrateur un mot de passe de plus de 14
caractères (Windows 2000 en supporte jusque 127 ).
Edition de la base de
comptes après modification du mot de passe
Tiens aurais-je trouvé
le bug du siècle ? L’outil L0phtCrack m’indique que le compte
Administrateur n’est pas protégé par mot de passe.
Essayons d’ouvrir une
session « Administrateur » « sans mot de passe » ………
Suspense……….. Non…pas d’ouverture de session, OUF le système n’a pas été trompé , nous avons un mot de passe solide.
Nous avons donc éliminé
le problème des mots de passe chiffrés en LanMan.
Le tribu à payer :
Impossible d’ouvrir une session à partir d’un poste 95, 98 ou NT 4.0 ils ne
proposent dans la boîte de dialogue d’ouverture de session qu’un champ de 14
caractères. De toute façon, le paramètre de stratégie visant à refuser
l’authentification LanMan, éliminait déjà les clients
95 et 98.*
* : Sauf si vous
avez installé le client « Directory Services »
Alors où se porte les améliorations au
niveau de la sécurité ?
Jetons un coup d’œil au sous-système de sécurité de Windows
2000. Nous remarquons que, pour les serveurs, non contrôleur de domaine, le
schéma de l’authentification reste semblable à celui adopté par NT 4.0. La base
de compte est la SAM et toutes les vulnérabilités propres à NT 4.0 se
retrouvent dans la version Windows 2000 pour les machines configurées en tant
que serveur autonome ou serveur membre d’un domaine.
Des améliorations notables ont cependant été mises en œuvre
avec Windows 2000, principalement au niveau du protocole d’authentification et
au niveau de la base de compte, intégré à l ‘annuaire Active Directory
pour les contrôleurs de domaine.
Migration de la base SAM dans Active Directory
Lors de la migration d’un serveur membre vers les fonctions
de contrôleur de domaine, la base de compte SAM est migrée vers l’annuaire
Active Directory. Les attaques portées vers la SAM avec les outils
traditionnels sont totalement inefficaces.
Remarque : dans l’exemple ci-dessous on a dans un premier
temps visualisé la base de compte du serveur membre. Après promotion de
ce serveur en contrôleur de domaine, on a de nouveau visualisé la base de
compte. On s’aperçoit que seuls les comptes administrateur
et invité sont présents. Dans un prochain article, je vous expliquerai le rôle
particulier de ce compte d’administrateur,
présent sur les contrôleurs de domaine.
Conclusion
Le but de cet article est de vous montrer, vous
démontrer que le produit Windows 2000 est un système d’exploitation présentant
de remarquables améliorations au niveau de la sécurité. Cependant une bonne
connaissance de son fonctionnement est nécessaire. Le choix de l’éditeur de
rester compatible avec toute ses précédentes gammes
est un choix lourd de conséquences pour la sécurité de votre systèmes
d’information.
Vous ne bénéficierez d’un environnement très sécurisé qu’en
misant sur le tout Windows 2000, qu’en abandonnant les clients précédents et en
suivant quelques conseils pour pallier à certains comportement pour le moins
étonnant du système.
Un point important à noter .
Toutes les démonstrations que j’ai effectuées dans cet article ont été
faites en étant connecté localement à l’ordinateur (session interactive). La
tâche aurait été beaucoup plus ardue, voire même impossible par un accès via le
réseau. Les efforts de l’éditeur se sont concentrés à juste titre sur la
sécurité des protocoles d’authentification et un contrôle sévère, par le sous système de sécurité, des utilisateurs se connectant
à distance.
Conseils :
·
Etablissez un contrôle d’accès aux locaux abritant vos machines
physiques
·
Utilisez une authentification forte de type carte à puce pour ouvrir des
sessions interactives
·
Définissez une stratégie qui empêche une ouverture de session
interactive par des utilisateurs lambda
·
Désactivez le lecteur de disquette et de CD pour empêcher le chargement
d’un autre OS ou d’un pilote
·
Eliminer vos clients DOS, Windows 3.11.
|
|
|
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
