Comment les informations d'identification Windows mises en cache sont-elles stockées sur la machine locale?

26

Comment les informations d'identification de domaine Active Directory mises en cache sont-elles stockées sur un client Windows? Sont-ils stockés dans la base de données SAM locale, les rendant ainsi sensibles aux mêmes attaques de table arc-en-ciel que les comptes d'utilisateurs locaux sont susceptibles, ou sont-ils stockés différemment? Notez que je me rends compte qu'ils sont salés et hachés, afin de ne pas être stockés en texte brut, mais sont-ils hachés de la même manière que les comptes locaux et sont-ils stockés au même endroit?

Je me rends compte qu'au minimum, ils sont susceptibles d'être attaqués par force brute, mais c'est une bien meilleure situation que d'être vulnérable aux tables arc-en-ciel en cas de vol de machine.

windows active-directory security

— MDMarra
source

17

"Informations d'identification mises en cache"

Les informations d'identification mises en cache pour un domaine AD sont en fait des doubles hachages salés du mot de passe et stockées dans la ruche HKLM \ Security. L'emplacement du fichier de la ruche est: %systemroot%\System32\config\SECURITY

Seul l'utilisateur "système" a accès aux clés de registre:
HKLM\Security\Cache\NL$noùn est un index 1 du nombre maximal d'informations d'identification mises en cache.

Sensibilité aux attaques

WinNT à WinXP a utilisé des hachages "Lan Manager" pour le local comptes , qui se cassent facilement sur le matériel moderne. Le cracking prend généralement plusieurs minutes (j'ai récemment fait 3 mots de passe en 00:08:06) avec juste un ordinateur de bureau "normal". Les hachages Lan Manager ne sont pas salés, il existe donc également des tables arc-en-ciel accessibles au public.

Vista et versions ultérieures utilisent des hachages NT pour les comptes locaux . Windows 2000 et versions ultérieures utilisent également des hachages NT pour les comptes de domaine . Les hachages NT sont des hachages salés double MD4. Le sel par entrée empêche l'utilisation de tables arc-en-ciel, mais MD4 peut être exécuté très rapidement sur du matériel moderne: environ 6 années de calcul pour un mot de passe 60 bits. Avec de la chance et un cluster de 6 GPU, un pirate peut casser ce type de mot de passe en ~ 6 mois. En prenant cela dans le cloud, environ 35000 $ sur le processeur graphique Amazon EC2 - selon la disponibilité, cela pourrait prendre des heures.

— Chris S
source

Je suppose que la plus grande partie de ma question était de savoir si ces informations d'identification stockées sont sensibles aux mêmes attaques basées sur la table arc-en-ciel que les comptes locaux ou si elles sont hachées d'une méthode différente

— MDMarra

Mise à jour ... Vista + c'est tout de même. Les anciennes versions étaient différentes.

— Chris S

"Le hachage NT du mot de passe est calculé à l'aide d'un algorithme de hachage MD4 non salé." - Directement depuis TechNet: technet.microsoft.com/en-us/library/hh994565(v=ws.10).aspx

— thepip3r

Cette page est fausse, les hachages NT sont salés. Voir la réponse de Joe ci-dessous pour un lien vers une base de connaissances.

— Chris S

4

Les informations d'identification ne sont pas réellement mises en cache sur la machine locale. Voir cet extrait de MS:

Sécurité des informations d'identification de domaine mises en cache

Le terme informations d'identification mises en cache ne décrit pas précisément comment Windows met en cache les informations de connexion pour les connexions de domaine. Dans Windows 2000 et dans les versions ultérieures de Windows, le nom d'utilisateur et le mot de passe ne sont pas mis en cache. Au lieu de cela, le système stocke un vérificateur crypté du mot de passe. Ce vérificateur est un hachage MD4 salé qui est calculé deux fois. Le double calcul fait effectivement du vérificateur un hachage du hachage du mot de passe utilisateur. Ce comportement est différent du comportement de Microsoft Windows NT 4.0 et des versions antérieures de Windows NT.

http://support.microsoft.com/kb/913485

— joeqwerty
source

À droite, je comprends que les informations d'identification elles-mêmes ne sont pas réellement mises en cache, mais ma question était plus dans le sens de "les hachages résultants sont-ils stockés dans la base de données SAM locale de la même manière que les comptes locaux, les rendant ainsi utilisables pour les mêmes attaques. " Je vais éditer ceci dans une minute pour être un peu plus clair.

— MDMarra

1

meh .. pour moi, ce sont des mots hachés. la nature du «hachage» est un processus à sens unique qui crée essentiellement une valeur obscurcie du mot de passe à l'aide d'un algorithme cryptographiquement sécurisé. Le problème est que MD4 peut avoir été cryptographiquement sécurisé il y a 10-15 ans mais n'est même plus proche (ni MD5 ni SHA1 du point de vue d'un cryptographe). Donc, si vous avez un matériel actuel qui peut rapidement forcer brutalement l'espace clé de l'algorithme ou découvrir une collision, alors vous pouvez facilement dériver le mot de passe du hachage ...

— thepip3r

Si les informations d'identification sont stockées de quelque manière ou forme que ce soit afin qu'elles puissent être vérifiées en mode hors ligne - alors elles sont mises en cache à toutes fins utiles, peu importe à quoi ressemblent les données dans ce cache

— NiKiZe

4

Ils sont gérés par Credential Manager, pour lequel il existe une API Credential Manager. Les hachages salés sont stockés de manière quelque peu sécurisée sur le disque et accessibles via HKLM \ Security. (Qui n'est accessible que par LocalSystem par défaut, mais est facile à contourner, par exemple, par psexec -i -s regedit.exe.)

Cependant, sur un système Windows en cours d'exécution, la situation est plus grave, car les informations d'identification récemment utilisées peuvent être obtenues et facilement inversées en texte brut en connectant une DLL à Lsass. (Voir Mimikatz.)

Donc oui, vous trouverez une sorte de hachage (ou hachage d'un hachage, ou «vérificateur» ou tout ce que vous voulez appeler) dans HKLM \ Security \ Cache sur le client. Mais je ne pense pas qu'il existe un moyen possible d'attaquer le hachage sur le disque. Ce n'est pas le même type de hachage NTLM qui est attaquable.

— Ryan Ries
source

Le craquage de mot de passe hors ligne dans le SAM est complètement différent de l'accrochage de LSASS en mémoire comme le font Mimikatz et WCE. Et selon la complexité du mot de passe, le craquage de mot de passe hors ligne du SAM peut être TRÈS facile (voir samdump2)

— thepip3r