[Security] – Protocoles et systèmes d’authentifications, partie 2 – Comprendre comment Windows stocke et gère votre identité au sein du réseau d’entreprise

[Security] – Protocoles et systèmes d’authentifications, partie 1 – introduction aux systèmes d’authentifications  – http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/04/security-protocoles-et-syst-232-mes-d-authentifications-partie-1-introduction-aux-syst-232-mes-d-authentifications.aspx

[Security] – Protocoles et systèmes d’authentifications, partie 3.1 – Protocoles d’authentification – Local Authentication – http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/09/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-1-protocoles-d-authentification-local-authentication.aspx

[Security] – Protocoles et systèmes d’authentifications, partie 3.2 – Protocoles d’authentification – Basic Authentication – http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/20/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-2-protocoles-d-authentification-basic-authentication.aspx

[Security] – Protocoles et systèmes d’authentifications, partie 3.3.1 – Protocoles d’authentification – Introduction aux Challenge-Response Protocols – http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/23/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-1-protocoles-d-authentifications-challenge-response-protocols-digest-authentication.aspx

[Security]
– Protocoles et systèmes d’authentifications, partie 3.3.2 – Protocoles
d’authentification – Digest Authentication –
http://danstoncloud.com/blogs/jordanlaurent/archive/2014/01/10/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-2-protocoles-d-authentifications-digest-authentication.aspx

 

Lorsque vous gérez un système d’authentification, vous devez stocker plusieurs informations sur vos utilisateurs de sorte qu’elles puissent être comparées au moment de l’exécution de ce qu’ils rentreront sur leurs systèmes pour obtenir l’accès à votre réseau d’entreprise. Ce procédé d’authentification varie en fonction à la fois du type du système d’authentification et comment le concepteur a construit le système.

Dans cette partie, nous allons discuter des authentificateurs stockés dans Windows, en particulier en mettant l’accent sur ​​les mots de passe, car ils sont plus communément utilisés et soumis à beaucoup plus de variations que les cartes à puce.

Les cartes à puce reposent sur des certificats, dont la gestion sera confiée à une autorité de certification. Brièvement, la carte à puce détient la partie secrète du certificat, le système d’authentification, dans ce cas un domaine Active Directory (AD DS – Active Directory Domain Services), détient la partie publique. Lorsque vous utilisez des cartes à puce pour authentifier vos utilisateurs, aucuns « secrets » liés à la carte à puce nécessitent d’être stockées sur les contrôleurs de domaine (DC – Domain Controller), mais comme dit plus haut, seront stockées au sein d’une autorité de certification (CA – Certification Authority) elle même faisant partie intégrante de l’infrastructure à clés publiques (PKI – Public Key Infrastructure) de votre entreprise. Dans le monde Microsoft, c’est le service AD CS – Active Directory Certificate Services qui joue ce rôle.

Les mots de passe, dans pratiquement toutes leurs formes d’implémentations disponibles aujourd’hui, sont dit « à secret partagé ». C’est-à-dire? Bien entendu, nous aborderons l’authentification d’un client Windows sur un réseau d’entreprise en détail, mais simplement, gardez en tête que votre serveur d’authentification contient au sein de sa base de données toutes les informations de vos utilisateurs, cela signifie que ce serveur « connaît » à l’avance quels informations (couple nom d’utilisateur + mot de passe) il devrait recevoir de la part de vos clients Windows afin que ceux-ci puissent se connecter… Les mots de passe sont donc sensibles et doivent être protégés (pour l’instant rien de nouveau 🙂 )

Note : Dans les systèmes du début de l’ère informatique, les mots de passe étaient simplement stockés en clair dans un fichier texte Ceux-ci n’ont jamais été vraiment destiné à empêcher les gens d’accéder à une ressource parce que seul un petit groupe de personnes y avait accès. Ils ont été principalement utilisés pour contrôler l’environnement. Aujourd’hui, la base de données contenant vos mots de passe ont été chiffrés (encryptées diront certains même si ce terme provient de nos amis anglais). 

 

  • Chiffrement(s) et Hash(s)

« Chiffrement » provient du terme cryptographie, qui littéralement signifie « écriture cachée« . Le cryptage est le processus utilisé par la cryptographie pour cacher l’écriture, ou convertir un texte clair (plaintext) en texte chiffré (ciphertext). Le « décryptage » (decryption) est le processus inverse, convertir un texte chiffré en texte clair.

Le cryptage utilise la cryptographie pour convertir quelque chose dans un format illisible mais réversible, le hash est une fonction qui convertit quelque chose en format illisible et irréversible. Un hash peut, par exemple, être utilisé comme une somme de contrôle (checksum) pour comparer les deux textes en clair. Si les deux génèrent le même hash (c’est-à-dire la même valeur numérique), vous serez sûrs que les textes en clair sont identiques. Les hash(s) sont aussi beaucoup plus petit qu’un texte chiffré et sont très bien adaptés à des usages comme le stockage de mot de passe. Nous pouvons donc maintenant revenir sur façon dont la base Active Directory stocke les mots de passe de vos utilisateurs! Lorsqu’il s’authentifie, celui-ci n’envoi donc pas son mot de passe en clair mais la valeur du couple « nom d’utilisateur + mot de passe »  (à travers une fonction de hash); une fois que le serveur d’authentification la reçoit il compare cette valeur avec celle contenue dans sa base (Somme de contrôle – checksum). Si les valeurs de hash correspondent, votre session Windows se chargera! Si ces valeurs ne correspondent pas vous n’aurez pas accès à votre session et aux ressources de votre entreprise 🙂

 

  • Comparaison avec les systèmes UNIX

La plupart des systèmes Unix utilisent encore cette forme exacte de stockage de mot de passe, avec deux légères modifications. Tout d’abord, le fichier de mot de passe, généralement stocké dans /etc /passwd, ne contient désormais plus les hash(s) des mots de passe, mais seulement les noms d’utilisateur et les ID. Les hach(s) sont stockés dans le fichier de mot de passe caché (/etc /passwd.shadow). Bien que le fichier de mot de passe soit lisible par tous, le fichier shadow est lisible uniquement par le compte root (ou droits équivalents).

Etant donné que les mots de passe étaient à l’origine lisible dans le fichier /etc /passwd, ils devaient être protégés contre les attaques. Imaginez une situation dans laquelle vous et moi avez des comptes utilisateurs sur le même ordinateur. Mon mot de passe est « P@ssw0rd«  et, par pure coïncidence, vous choisissez le même mot de passe avec une comparaison des hash(s), nous aurions le même hash stocké dans ce fameux fichier. Je pourrais donc chercher le fichier pour mon hash puis recherchez d’autres comptes avec le même hash. Je saurai alors qui a le même mot de passe que le mien… vous serez d’accord pour dire que c‘est une situation inacceptable La solution est d’ajouter une valeur aléatoire au mot de passe (technique du « grain de sel ») avant que la fonction de hash « intervienne » (principe de MD4 et MD5). De cette façon, même si les deux mots de passe sont identiques, leurs hash(s) respectifs seront différents! (Si vous souhaitez en savoir un peu plus sur la technique du grain de sel, je vous conseille de lire l’article de Guillaume Affringue – http://guillaume-affringue.developpez.com/securite/chiffrement/?page=3#LIII-B).

Windows utilise des variantes sur toutes ces techniques pour stocker les mots de passe. Rentrons maintenant dans le cœur du sujet! Quels sont les fonctions de hash(s) utilisés dans le monde Microsoft…

 

  • LM Hash

La fonction de hash LM a été d’abord utilisé par Microsoft dans son système d’exploitation réseau LAN Manager (dernière version publiée au début des années 90). LAN Manager faisait également partie intégrante du système d’exploitation OS/2 de IBM. Lorsque Windows NT a été publié en 1993, il était impératif que le nouveau système d’exploitation inter opère avec LAN Manager afin que les organisations qui avaient investi dans LAN Manager ne se retrouvent pas dans une impasse. LAN Manager à continuer d’être activé par défaut dans les différents noyaux de Windows NT pour des raisons de rétrocompatibilité pendant 13 ans, avant que Microsoft ne décide de déprécier LM à partie de la version 6.0 (Vista / Server 2008 – tout récent donc). Il peut être activé si certains systèmes de votre entreprise utilisent encore la fonction de hash LM.

Techniquement, cette fonction n’est pas réellement un hash, même si elle en utilise quelques propriétés –  il s’agit d’une fonction à sens unique – et est désigné techniquement LMOWF (LanManager One-Way Function). Le hachage LM est créé en utilisant un grand nombre d’étapes relativement compliquées  

  1. L’utilisateur crée un nouveau mot de passe
  2. Le mot de passe est immédiatement converti en majuscules (les mots de passe stockés en utilisant la fonction de hash LM sont insensibles à la casse!).
  3. Une fois que le mot de passe soit converti en majuscules il est complété jusqu’à obtenir 14 caractères. Si le mot de passe fait déjà plus de 14 caractères (théoriquement il pourrait être tronqué), le processus échoue et le hash LM ne sera pas généré (c‘est pourquoi vous obtenez un avertissement sur ​​la compatibilité avec les systèmes d’exploitation plus anciens lorsque vous définissez un mot de passe de plus de 14 caractères).
  4. Ensuite, le mot de passe est divisé en deux parties de 7 caractères chacune. La première raison est que celles-ci vont à présent être utilisées en tant que clés de cryptage (comme dans DES – Data Encryption Standard), et la seconde est que l’algorithme de cryptage de données DEA (Data Envcryption Algorithmutilisé dans DES) opère par tranche de 56 bits (et comme vous le savez, 1 octet = 8 bits donc 7 octets = 8 bits * 7 = 56 bits! CQFD 🙂 )
  5. Enfin, les résultats des deux opérations de DES sont concaténées et les résultats sont stockés sous le hachage LM. Le hachage est stocké soit dans la base de données SAM – Security Accounts Manager si le mot de passe est associé à un compte local ou dans l’attribut dBCSPwd de l’objet utilisateur dans Active Directory.

Cela explique pourquoi un attaquant est capable de déduire la longueur du mot de passe d’une personne juste en regardant la table de hash(s). Si la seconde moitié du hash LM est AAD3B435B51404EE, la seconde moitié du mot de passe est vide, et il ne fera pas plus de sept caractères. Si les deux moitiés sont AAD3B435B51404EE, le mot de passe est entièrement vide

  • NT Hash

Lorsque la première version de Windows NT est sorti en 1993, une nouvelle méthode de stockage de mot de passe a été introduit. Ce mécanisme est bien plus simple que le hash LM. Le hash NT (techniquement NTOWF – New System One-Way Function) est stocké soit dans la SAM ou dans l’attribut unicodePwd de l’objet utilisateur dans Active Directory.

A noter que ni la fonction NTOWF ni LMOWF n’utilisent la technique de « grain de sel » comme dans le monde UNIX. Pourquoi c’est à noter? Tout simplement, parce que la fonction de hash NT  est finalement un dérivé de la fonction de hash bien connu – MD4 (Message Digest version 4). Microsoft n’a jamais utilisé ce procédé pour la simple et bonne raison que les bases de données de mots de passe ne sont jamais lisibles par les comptes (excepté administrateur), de telle sorte que la  recherche ne soit pas utilisé en tant que vecteur d’attaque!

NoteL’authentification NTLM se sert encore de MD4 et RC4 (méthode d’encryption) pour effectuer les comparaisons de mots de passe des noyaux Windows NT 5.1 (XP / 2003), NT 6.0 (Vista / 2008), NT 6.1 (7 / 2008 R2), NT 6.2 (8 / 2012) et NT 6.3 (8.1 / 2012 R2) lors de l’ouverture de session en locale (base SAM) – http://msdn.microsoft.com/en-us/library/cc236715.aspx. Kerberos et la méthode d’encryption AES (Advanced Encryption Standard) seront utilisés à partir de NT 6.0, si et seulement si, les ordinateurs se connectent à un domaine Active Directory (ou un annuaire informatique prenant en charge le protocole Kerberos)!

 

  • Système de vérification du mot de passe

Si vous travaillé déjà dans un environnement Active Directory, vous avez probablement remarqué que vous pouvez transporter un ordinateur portable joint au domaine avec vous et vous authentifier à l’aide d’un compte de domaine, même si vous n’êtes pas connecté à celui-ci. Ce cas particulier est opéré grâce à ce qu’on appelle le vérificateur de mot de passe (Password Verifier). Le vérificateur de mot de passe, souvent appelé en dehors de Microsoft comme « la mise en cache des identifiants » (Cached credentials) – http://technet.microsoft.com/en-us/magazine/2009.07.windowsconfidential.aspx, est une copie locale de votre « hash de domaine » que vous pouvez utiliser pour ouvrir une session. Dans les versions du système d’exploitation antérieures à NT 6.0, le calcul du vérificateur de mot de passe était « simplement » le hash d’un hash.

Au cours des dernières années, les assaillants ont mis l’accent sur ce vérificateur de mot de passe et ont commencé à créer des outils pour le « casser ». Même si le hash (+ la technique du grain de sel) d’un hash est très difficile à casser, le craquer est possible si le mot de passe n’est pas très complexe. A partir de NT 6.0, le calcul du vérificateur de mot de passe a été modifié en exécutant l’ancien vérificateur à travers un grand nombre d’opérations PKCS # 5 – Password-based Cryptography Specificationshttp://www.ietf.org/rfc/rfc2898.txt. Ceci permet d’obtenir une protection adéquate contre tous même sur les mots de passe faibles. 

« The purpose of PKCS #5 is to solve the « dictionary passwords » attack. There are two approaches to solve this problem. One approach is to combine a password with a salt to produce the key. This generates a long key which makes it is difficult to be guessed. The other approach is to provide a complicate KDF, for example, include the iteration count. therby increasing the cost of exhaustive search. » – Qing-Ming Jeff Cai, 2008.

Cas particuliers d’authentifications :

 – Lorsqu’un utilisateur se connecte en utilisant les services Terminal Server de Windows, le système d’exploitation met en cache le hash NT de l’utilisateur (et le hash LM si l’ordinateur est configuré pour le stocker). Le hash est maintenue dans un emplacement de mémoire disponible uniquement pour le système d’exploitation (ouf!), et tout processus qui peut faire office de système d’exploitation.

 – Lorsqu’un utilisateur tente d’accéder à une ressource réseau qui requiert une authentification, le système d’exploitation utilise ce hash en cache pour l’authentifier (c‘est ce qui permet l’authentification transparente aux ressources du réseau). Dès que l’utilisateur se déconnecte, l’emplacement de mémoire est automatiquement purgée.

 

Ces méthodes de hash ont fait l’objet de pas mal de critiques, il a été démontré que si un administrateur de domaine est connecté, tout autre utilisateur qui est  administrateur pourra lire le hash de cet administrateur de domaine et l’utiliser pour s’authentifier auprès d’un DC…en tant qu’administrateur du domaine!. Ces méthodes sont pris en charge pour permettre la transmission transparente (SSO – Single Sign-On) à des périphériques réseau Windows (ou non-Windows). Bien qu’il soit possible de supprimer la mise en cache des hash(s) des mots de passe, la plupart des utilisateurs se révolterait à avoir à taper son mot de passe à chaque fois qu’ils accèdent à une ressource réseau… Quel serait donc le bon compromis? En fait, le problème n’est pas vraiment de la façon dont Windows met en cache le hash NT mais plutôt à veiller à respecter les bonnes pratiques d’authentification! Un administrateur de domaine ne doit jamais se connecter de manière interactive à un poste de travail utilisé par un utilisateur avec des privilèges d’administrateur local (à moins que l’utilisateur soit également un administrateur de domaine). En suivant ce principe simple, vous pourrez garder cette fonctionnalité tout en évitant d’en faire un vecteur d’attaque 🙂

 

  • Cryptage réversible…

Windows propose une option pour stocker les mots de passe à cryptage réversible. C’est à dire? Lorsqu’un mot de passe est stocké avec l’option de cryptage réversible, il peut être inversée en texte clair. L‘option « cryptage réversible » est désactivée par défaut, et est généralement nécessaires que dans deux cas suivants :

 – Nécessaire si vous avez besoin d’utiliser d’anciens protocoles d’authentifications pour l’accès à distance comme les protocoles CHAP – Challenge-Handshake Authentication Protocol (http://technet.microsoft.com/en-us/library/cc775567(v=ws.10).aspx) ou Digest (http://technet.microsoft.com/en-us/library/cc778868(v=ws.10).aspx).

 – Nécessaire si vous souhaitez effectuer une analyse avancée de vos mots de passe (Par exemple, certaines organisations souhaitent analyser si les mots de passe contiennent certains mots spécifiques).

Note : Pour activer le chiffrement réversible d’une manière globale, utiliser l’éditeur de stratégie de groupe (GPMC – Group Policy Management Console).

Après avoir traité des fonctions de hash(s) utilisées par Windows (NT et LM), la 3e partie de cet article sur la sécurité Microsoft portera sur les protocoles d’authentifications!

Sources :

PASSWORDS TECHNICAL OVERVIEW – http://technet.microsoft.com/en-us/library/hh994558(v=ws.10).aspx

MICROSOFT SECURITY INTELLIGENCE REPORT – DEFENDING AGAINST PASS-THE-HASH ATTACKS – http://www.microsoft.com/security/sir/strategy/default.aspx#!password_hashes

Non classé

jordanlaurent

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *