Dans le processus d'authentification, LSASS est en charge de fournir le mécanisme de SSO "Single SignOn". Pour se faire, il charge en mémoire l'ensemble des mots de passe utilisés par l'utilisateur.
Les mots de passe sont chiffrés via une clef symétrique (AES ou 3xDES) qui est également stockée en mémoire.
L'interface SSPI fait le lien entres les applications et les fournisseurs de sécurité (SSP) dans Windows
Quelques SSP :
- msv1_0 : Utilisé pour une authentification challenge/réponse via les protocoles LM, NTLM et NTLMv2
- Kerberos : Utilisé lors d'une connexion réseau d’authentification au service KDC "Key Distribution Center" présent sur un contrôleur de domaine
- wdigest : Utilisé pour une authentification web HTTP
- livessp : Pour l'authentification au poste via un compte live (Outlook, hotmail, ..) [Apparu avec Windows 8]
- tskpg : Apporte un nouveau mécanisme de sécurité (NLA) pour établir un canal TLS pendant l'authentification RDP [Apparu avec Vista]
Les hash microsoft
Durant les phases offensives, l'un des artefacts important est généralement l'obtention de hash microsoft. Cette acquisition permet en général d'élever ses privilèges en cassant le hash, ou pire, en le passant à la place du mot de passe (Merci la faiblesse net-NTLM)
Attention LM et NTLM sont à la fois des formats de hash et des protocoles d'authentification distant. Selon les version d'OS Microsoft, certains anciens formats avec l'age et les attaques ont été cassés
Hash LM (Lan Manager)
Celui la, c'est le plus ancien (par conséquent le plus pourrie) fort heureusement il est désactivé depuis Vista et Server 2008, pourtant on peut encore le retrouver dans beaucoup de PME (Because compatibility needed)
LM utilise une clé de hachage pour transformer un code de taille variable en un code de taille fixe.
Le mot de passe doit contenir quatorze caractères. si il est plus court, LM ajoute des 0 pour atteindre la taille de 14 caractères. Il convertit ensuite le mot de passe en majuscules et divise celui-ci en deux parties de sept caractères (c’est le point faible de cette méthode).
Une clé DES (identique et connue) de 56 bits est ensuite construite pour chacune des deux moitiés de 7 octets. Elles sont ensuite concaténées pour donner une clé de hachage sur 16 octets.
Vous l'aurez compris, ce format de hash est obsolète et il ne faudra pas longtemps à l'attaquant pour péter votre hash
Comment se prémunir que cela arrive ? Migrez ou virez de votre domaine les vieux OS (au moins anterieur à Vista et Server 2008)
Déployez ces GPO sur votre domaine
Computer -> Paramètres Windows -> Stratégies locales -> Options de sécurité -> Sécurité réseau : niveau d'authentification LAN Manager
Computer -> Paramètres Windows -> Stratégies locales -> Options de sécurité -> Sécurité réseau : ne pas stocker de valeurs de hachage de niveau LAN Manager sur la prochaine modificaiton de mots de passe
Notez qu'un HashLM désactiver se traduit en aad3b435b51404eeaad3b435b51404
NTLM
NTLM utilise quand à lui les algorithmes 3DES et/ou MD4, les mots de passe peuvent aller jusqu'à 255 caractères. Il reste cassable (moins facilement que LM) mais possible en cas de mot de passe faible et d'attaque par bruteforce.
Exemple pour l'utilisateur toto
toto:1001:AAD3B435B51404EEAAD3B435B51404EE:4CCDB7041204D5488C04637BF6ADFF08:::
- toto est le nom du compte possédant le hash
- 1001 est l'UID du compte
- AAD3B435B51404EEAAD3B435B51404EE est le hash LM
- 4CCDB7041204D5488C04637BF6ADFF08 est le hash NTLM
Ou sont stockés les HASH microsoft ?
Partout ! Windows laisse trainer ses hash (et sous plusieurs format) On peut en retrouver en base de registre, sur le réseau, en mémoire et parfois même dans des fichiers textes (LoL)
Hash NTLM local
Les hash NTLM locaux sont utilisés en environnements workgroup, ils sont enregistrés dans la base SAM (une ruche de base de registre)
Elle se trouve à l'endroit suivant C:\Windows\system32\config\SAM
Pour le cas d'un annuaire ActiveDirectory, la base SAM est la base NTDS, celle qui contient tout les hash de compte
Elle se trouve à l'endroit suivant C:\Windows\NTDS\NTDS.dit
Hash MSCacheV2
Dans un contexte de domaine hors connexion, le hash de l’utilisateur n’est pas stocké en base SAM mais dans HKLM:/SECURITY/Cache
Par défaut, le système conserve 10 Hash (Laissant un large historique en cas de compromission de poste)
Il est recommandé de réduire à 1 hash conservé
Fonctionnement des protocoles d'authentification
Dans un écosystème windows, beaucoup de services demandent une authentification, cependant celle-ci n'est pas gérée par ces memes services.
Pour cela, les services appellerons les SSP en fonction de plusieurs critères :
La machine emetrice ou receptrice de la demande est-elle dans le domaine / hors domaine ? Quel niveau de sécurité du protocole d'authentification accepte-elle ?
Dans un environnement de domaine, et lorsque vous tentez d'accéder à un service par son nom DNS (FQDN) le protocole kerberos sera utilisé pour faire l'authentification, dans le cas ou l'emeteur ou le recepteur est hors domaine ou que vous accediez au service via l'IP, NTLMSSP sera utilisé.
L'image ci-dessous indique que le NTLMSSP est appelé pour permettre à l'accès au partage (via SMB)
L’etablissement des protocoles NTLM est réalisé grâce au protocole NTLMSSP, celui-ci se base sur les 3 étapes suivantes :
- NTLMSSP Negotiate : Négociation du protocole qui sera utilisé (Le client fournit une demande d’authentification en précisant les versions Net-NTLM acceptés)
- NTLMSSP Challenge : Le serveur répond en précisant les versions NTLM acceptés et en envoyant un “challenge”
- NTLMSSP Auth : Le client résout le challenge et le transmet au serveur (avec les informations tiers comme le login, domaine, etc …)
Pour les authentifications hors domaine il est préférable d'utiliser NTLMv2, cependant pour des raisons de compatibilité, les versions récentes de Windows acceptent toujours les protocoles antérieurs d'authentification.
Net-NTLMv1
Authentification réseau utilisé par défaut dans Microsoft, fonctionnant sous forme de challenge/réponse. Le serveur envoi une suite de chiffre/lettre (challenge) au client qui devra le chiffrer avec son hash de mot de passe.
Dans un contexte de domaine, le serveur envoi le username, le challenge et la réponse au contrôleur de domaine qui vérifierait la correspondance.
Net-NTLMv2
Version plus sécurisé que NTLMv1, en plus d'utiliser une cryptographie plus robuste il est renforcé contre l'usurpation d'identité, le serveur doit s'authentifier auprès du client.
Lors de l'échange challenge/réponse, le client envoie deux réponses sur 8 octets au serveur. Chaque réponse contient un hachage HMAC-MD5 de 16 octets du défi serveur
1- Le client concatène le username, nom de domaine et calcule un code d'authentification de message HMAC-MD5 utilisant OWF NT comme clé, le tout est appelé OWF NTLMv2
2- Le client génère son propre challenge contenant l'horodatage et des informations sur la cibles. Le tout est concaténé avec le challenge du serveur et un autre code HMAC-MD5 utilisant NTLMv2OWF comme clé.
3- Le client calcule la réponse en se basant sur OWF NTLMv2, le challenge du serveur et le challenge généré précédemment. La réponse est appelé LM2
4- Le client envoi la réponse avec le challenge client
Kerberos
Protocole d'authentification par défaut en domaine Microsoft (Depuis Windows 2000 SP4)
Grossièrement il permet à des utilisateurs de s’authentifier une première fois sur le réseau pour accéder par la suite à des services de manière authentifiée via des "tickets" (plus besoin d'authentification)
Kerberos (également appelé le KDC) se divise en 2 parties principales :
- L' Authentification Service (fournissant des TGT permettant par la suite de demander des demandes d'accès aux services via des TGS)
- Le Ticket Granting Service (vérifiant l'authenticité des demandes puis fournissant des tickets d'accès aux services demandés)
L'utilisation de kerberos se coupe principalement en 2 parties :
1ere partie : Authentification de l'utilisateur (Obtention du TGT)
- Lorsque l’utilisateur s’authentifie, il rentre sa clé (mdp) transformée en hash
- Le client envoie sa demande de TGT [KRB_AS_REQUEST]
- L’AS répond qu’il faut au préalable s’authentifier [PRE_AUTH]
- Le client envoi son timestamp (heure de connexion) chiffré avec son hash ainsi que ses USER ID
- L’AS vérifie que l’utilisateur existe et déchiffre le timestamp avec son hash contenu dans l’AD (si le timestamp est lisible c’est que le hash est bon)
- Si l’utilisateur est validé, l’AS va construire 2 parties et les envoyer au client [KRB_AS_REPONSE]
- Il génère une « TGS_SESSION_KEY » pour le TGS, chiffrée avec hash de l’utilisateur (que l’utilisateur pourra déchiffrer) (B)
- Le TGT (C), chiffré avec la clé du KDC (seul le KDC peut déchiffrer le TGT). La clé de l’utilisateur permet de chiffrer le TGT avant de le transmettre au client
- Le client utilise son hash pour déchiffrer son TGS et obtenir ainsi le « TGS_SESSION_KEY ». Cette clé lui permettra de communiquer de manière sécurisée avec le TGS
A ce stade la, vous êtes authentifié, c'est maintenant qu'entre en jeu la deuxieme partie lorsque vous souhaitez accéder à un partage, service, etc via kerberos
2eme partie : Accès à un service (Obtention des TGS)
- L’utilisateur effectue sa demande de TGS en envoyant : [KRB_TGS_REQUEST]
a) son TGT
b) le timestamp chiffré avec sa clef de session TGS_SESSION_KEY (récupérée lors de l’authentification)
c) L’identifiant du service qu’il veut utiliser ( ex : CIFS\SERVER01 ) - Le KDC reçoit la requête et utilise sa clé pour ouvrir le TGT et récupérer la TGS_SESSION_KEY
- Si le timestamp est déchiffré, l’utilisateur est validé (puisque la TGS_SESSION_KEY est la bonne)
- Le KDC va envoyer les informations pour que l’utilisateur puisse faire sa demande auprès du service [KRB_TGS_RESPONSE]
a) Un ticket de service (D) chiffré avec le hash du service (contenant le
nom et instance du service, le nom de l’utilisateur le PAC et la clef de
session de l’utilisateur)
b) La clef de session (C) “SERVICE_SESSION_KEY” chiffré avec la
“TGS_SESSION_KEY” - L’utilisateur utilise sa TGS_SESSION_KEY pour lire la réponse et obtenir la SERVICE_SESSION_KEY (C)
- L’utilisateur fait une demande auprès du service [KRB_AP_REQUEST]
a) Le ticket de service (D) chiffré avec le hash du service
b) Un nouveau timestamp (C) chiffré avec la SERVICE_SESSION_KEY - Le service utilise son hash pour déchiffrer (D) et obtenir la SERVICE_SESSION_KEY
- Le service utilise la SERVICE_SESSION_KEY pour vérifier le timestamp et valider l’utilisateur
- Le service renvoi au client un timestamp (F) chiffrée avec la « SERVICE_SESSION_KEY ». [KRB_AP_RESPONSE] (Réponse optionnelle permettant de prouver le chiffrement des 2 hôtes avec la SERVICE_SESSION_KEY)