SSTIC07 Article Bordes Secrets Authentification Windows

Secrets dauthentication sous WindowsAurlien Bordes [email protected]

Rsum Cet article se propose dexpliquer les mcanismes dauthentication sous Windows e e e en abordant dirents th`mes comme les sessions dauthentication, les Authentication Pae e ckages, SSPI, les fournisseurs SSP, ... Puis nous nous intresserons ` la problmatique de la e a e mise en cache des credentials.

La grande majorit des tudes ont t ralises avec Windows XP service pack 2. Si les principes e e ee e e sont gnraux ` tous les Windows de la famille Windows NT, il peut exister quelques dirences. e e a e

1

Introduction

Lauthentication, gnralement prcde dune identication, est le mcanisme qui consiste ` e e e e e e a prouver une identit dont se rclame une ( entit ) Cest une tape obligatoire avant lautorisation e e ( e ). e qui consiste ` autoriser lentit ` raliser telle ou telle action. a ea e Pour un utilisateur Windows, lauthentication se rsume uniquement ` la saisie dun nom e a dutilisateur et dun mot de passe ` louverture de sa session. Il est tr`s loin de se douter quen a e ralit il sauthentie ` chaque fois quil consulte son courrier avec Outlook ou ouvre ses chiers e e a sur le rseau. Mais le syst`me lauthentie automatiquement et il nest gnralement pas oblig de e e e e e ressaisir son mot de passe. Cela est possible car Windows dispose dun mcanisme complet pour authentier les utilisateurs e et orir un dispositif de mise en cache permettant le SSO (Single Sign-On ou authentication unique).

2

Rappels

Certains rappels se veulent volontairement rapides et simplistes. Le lecteur est invit ` consulter ea les nombreux articles sur le sujet. Concernant tout ce qui se rapporte ` LM et NTLM, ainsi quaux a protocoles associs, larticle dEric Glass [1], srieux et complet, fait rfrence sur le sujet. e e ee 2.1 Condensats

Le terme credential, dont la traduction franaise pourrait tre ( authentiant ) ( crdence ) ou c e ( ), ( e ) ( preuve dauthentication ) dsigne un ou des lment(s) secret(s) permettant ` un utilisateur de ( ), e ee a sauthentier. Cela peut tre son mot de passe, ou plus souvent des condensats (hashs) calculs ` e e a partir de son mot de passe. En eet, les mots de passe ne sont pas stocks en clair, ils sont transforms e e par une fonction ` sens unique an de ne garder quun condensat (hash) non rversible. Deux types a e de condensat cohabitent sous Windows : les condensats LM et les condensats NTLM.

2

Actes du symposium SSTIC07

Condensat LM Cest la forme la plus ancienne. La taille du mot de passe est au maximum de 14 caract`res et lalphabet utilisable est limit. Le calcul dun condensat LM ` partir dun mot de e e a passe est le suivant : lalphabet est simpli (notamment les minuscules sont transformes en majuscules) ; e e un bourrage (padding) de zro est ajout en n du mot de passe pour le complter a 14 e e e ` caract`res ; e le mot de passe est scind en deux, ce qui donne deux parties de 7 caract`res, soit 56 bits la e e taille dune cl DES ; e chacune des deux parties est utilise comme cl pour chirer une constante (KGS !@#%) avec e e lalgorithme DES ; les deux rsultats sont concatns pour donner le condensat LM. e e ee Ce qui donne (Password[n] fait rfrence au n`me caract`re, cod sur un octet, du mot de passe ee e e tendu ` 14 caract`res, et | est lopration de concatnation) : e a e e e

LM = DES(Password[0..6], KGS!@#$%) | DES(Password[7..13], KGS!@#$%) Le condensat LM nest maintenant plus considr comme s r. En eet, il est assez ais de retroue e u e ver un mot de passe ` partir de son condensat LM (sa forme apr`s le passage par la simplication a e de lalphabet pour tre prcis). Cest pourquoi, il est recommand de ne plus conserver le condensat e e e LM dans la base SAM des comptes locaux dun syst`me Windows (KB2996561). e Condensat NTLM Apparu avec Windows NT 4 Service Pack 3, le condensat NTLM corrige les faiblesses du condensat LM et ore une meilleure protection : la taille des mots de passe est augmente ` 255 caract`res (certaines interfaces graphiques e a e limitaient la taille ` 14 caract`res pour assurer la compatibilit avec le condensat LM) ; a e e le codage Unicode UCS-2 est utilis pour le mot de passe, cest-`-dire que chaque caract`re e a e est cod sur deux octets. e Le condensat NTLM est calcul ` partir du mot de passe via la fonction MD4. ea NTLM = MD4(Password) 2.2 Protocoles de d/rponse LM, NTLM, NTLMv2 e e

` A partir de leurs condensats, il faut pouvoir authentier les utilisateurs via des changes publics. e Trois protocoles sont disponibles sous Windows, tous bass sur un mcanisme de d/rponse : e e e e LM, NTLM et NTLMv2. Hormis LM qui se base sur le condensat LM, tous les autres protocoles ` utilisent le condensat NTLM. A noter lexistence dun mode dnomm NTLMv2 Session Security, e e tr`s largement mconnu [3]. e e Dans toutes les explications qui suivent, on se place dans le cas dun client souhaitant sauthentier aupr`s dun serveur. e1

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


3

NTLMv2 Session Security NTLMv2 Session Security nest pas rellement un algorithme de e d/rponse au mme titre que LM ou NTLM. Il sagit plutt dun nouveau mode de calcul utilisable e e e o pour gnrer la rponse NTLM. Il modie galement le champ ddi ` la rponse LM (lalgorithme e e e e e ea e LM ne pouvant plus tre utilis). e e ` A partir de Windows 2000 SP3, puis avec Windows XP ou 2003, ce mode est systmatiquement e ngoci par dfaut. Cependant, son utilisation nest que facultative. e e e LM Soit ServerChallenge un d (challenge) propos par le serveur et LM le condensat LM du e e client. Le condensat (qui fait 2 64 soit 128 bits) est tendu ` 168 bits par lajout de zros, ce qui e a e donne 3 cls DES (3 56 = 168). ee LM[n] fait rfrence au ni`me octet du condensat. Si n 16, LM [n] = 0, car les bits de 129 ` ee a 168 valent 0.

ReponseLM = DES(LM[0..6], ChallengeServeur) | DES(LM[7..13], ChallengeServeur) | DES(LM[14..20], ChallengeServeur) Si le mode NTLMv2 Session Security est activ, la rponse LM nest pas gnre : elle est e e e e e remplace par le d du client. e e NTLM La gnration de la rponse NTLM est tr`s semblable ` celle de la rponse LM. La seule e e e e a e dirence, cest lutilisation du condensat NTLM (galement tendu ` 168 bits par lajout de zros e e e a e pour former 3 cls DES) en lieu et place du condensat LM. e Si n 16, N T LM [n] = 0, car les bits de 129 ` 168 valent 0. a ReponseNTLM = DES(NTLM[0..6], ChallengeServeur) | DES(NTLM[7..13], ChallengeServeur) | DES(NTLM[14..20], ChallengeServeur) Si le mode NTLMv2 Session Security est activ, la gnration de la rponse NTLM change e e e e car un d propos par le client est introduit. Ce nest alors plus directement le d du serveur e e e qui est utilis, mais un d temporaire, calcul ` partir des ds du serveur et du client, dont on e e ea e ne garde que les 8 premiers octets (indiqus par [0..7]). La suite de la gnration de la rponse e e e e NTLM reste inchange. Quant ` la rponse LM, elle contient le d du client (complte ` 192 bits e a e e ee a par lajout de zros). e ChallengeTemp = MD5(ChallengeServeur | ChallengeClient)[0..7] ReponseLM = ClientChallenge ReponseNTLM = DES(NTLM[0..6], ChallengeTemp) | DES(NTLM[7..13], ChallengeTemp) | DES(NTLM[14..20], ChallengeTemp) NTLMv2 Apparu avec Windows NT 4 Service Pack 4, le protocole NTLMv2 corrige la principale faiblesse des protocoles LM et NTLM, ` savoir lutilisation de DES pour le calcul de la rponse. a e Cet algorithme, qui date de 1977, nest actuellement plus considr comme s r. Par exemple, la e e u

4


recherche exhaustive sur les cls (256 possibilits) peut se raliser dans un intervalle tr`s court e e e e (certains records tant en moins de 24 heures). Il devient alors possible de retrouver le condensat e utilis (LM ou NTLM) ` partir de la capture dun d/rponse. e a e e Le protocole NTLMv2 apporte deux modications importantes : lutilisation systmatique dans les calculs dun d gnr par le client ; e e e e e lutilisation de lalgorithme HMAC-MD5 pour le calcul des rponses. e Lorsque ce protocole est utilis, les rponses LM et NTLM sont remplaces par des rponses e e e e LMv2 et NTLMv2. Les rponses LMv2 conservent la mme taille que les rponses LM pour des e e e besoins de compatibilits (192 bits). Les rponses NTLMv2 sont de tailles variables et incluent e e diverses informations supplmentaires, en particulier un champ dhorodatage. e NTLMv2Temp correspond ` un condensat temporaire calcul ` partir du condensat NTLM, du a ea nom de lutilisateur mis en majuscule et du nom de la cible. Bloc reprsente une structure de e donnes contenant diverses informations (dont le challenge du client) : e NTLMv2Temp = HMAC-MD5(NTLM, Majuscule(Nom utilisateur) | Nom cible) ReponseLMv2 = HMAC-MD5(NTLMv2Temp, ChallengeServeur | ChallengeClient) | ChallengeClient ReponseNTLMv2 = HMAC-MD5(NTLMv2Temp, ChallengeServeur | Bloc) | Bloc Authentication avec le condensat Il est tr`s important de remarquer que tous les protocoles e dauthentication voqus ci-dessus ne ncessitent pas le mot de passe, mais uniquement le condene e e sat du mot de passe pour russir le d/rponse. Si un pirate russit ` se procurer le condensat e e e e a LM ou NTLM dun utilisateur, il pourra sauthentier ` distance avec le compte de cet utilisateur. a Il existe dailleurs une version modie de Samba [4] permettant de sauthentier non pas avec un e mot de passe, mais uniquement avec un condensat LM ou NTLM. 2.3 NTLMSSP

Pour pouvoir mettre en uvre les protocoles LM, NTLM et NTLMv2, il est ncessaire dutiliser e un protocole permettant de structurer les dirents changes. Cest le rle du protocole NTLMSSP. e e o Len-tte dun message NTLMSSP est de la forme : e 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifiant NTLMSSP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifiant NTLMSSP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Donnes... e | +-+-+-+-+


5

Le champ Identifiant NTLMSSP est une constante permettant didentier un message NTLMSSP, dont la valeur est NTLMSSP. Quant au champ Type, il dtermine le format des donnes qui e e suivent len-tte en indiquant le type de message NTLMSSP. e Trois types sont dnis : e e e type 1 (NTLMSSP NEGOTIATE) : ce message est mis par le client pour dmarrer un processus dauthentication. Optionnellement, des champs supplmentaires peuvent tre prsents e e e comme le nom de sa machine, son domaine ou la version de son syst`me dexploitation ; e e e type 2 (NTLMSSP CHALLENGE) : ce message est mis par le serveur en rponse au message prcdent. Sensiblement identique, il comporte toutefois un champ supplmentaire correspone e e dant au d du serveur (toujours sur 8 octets) ; e type 3 (NTLMSSP AUTH) : ce message est le plus important car il contient les rponses du e client : le champ LM, de taille xe (24 octets, soit 192 bits) contient la rponse LM, LMv2 ou le e d du client lorsque le mode NTLMv2 Session Security est activ, e e le champ NTLM contient la rponse NTLM ou NTLMv2. e Il faut galement souligner la prsence dun champ Flags sur 32 bits dans les trois types de e e message qui permet dindiquer la prsence de champs optionnels ou le support de fonctionnalits. e e e En particulier, le 24`me bit (soit 0x00800000) indique si le mode NTLMv2 Session Security est support ou activ. e e

3

Fonctions de scurit e e

Nous allons maintenant dcrire la mani`re dont les composants Windows calculent les dirents e e e condensats et rponses LM ou NTLM. Il faut noter que les fonctions SystemFunctionXXX ne font pas e partie de lAPI Windows ( ocielle ) Leur utilisation ncessite donc de les charger manuellement ( ). e avec LoadLibrary et GetProcAddress.

3.1

Condensats LM et NTLM Pour calculer le condensat LM ` partir dun mot de passe, deux fonctions sont utilises : a e RtlUpcaseUnicodeStringToOemString, dnie dans la librairie ntdll.dll : cette fonction e permet de convertir une cha de caract`res Unicode en cha ASCII et de simplier lalne e ne phabet pour nutiliser que les caract`res dits ( OEM ) (utiliss par exemple pour les noms e ( ) e NetBios) ; SystemFunction006, dnie dans la librairie advapi32.dll : cette fonction convertit une e cha de caract`res ASCII en condensat LM. ne e

Le calcul dun condensat NTLM est plus simple, car la simplication de lalphabet nest plus ncessaire. Cest uniquement la fonction SystemFunction007 (dnie dans advapi32.dll) qui est e e utilise. Cette fonction ne fait que calculer un condensat MD4 ` partir dune cha de caract`res e a ne e Unicode (compose de WCHAR) ; e

6


3.2

Rponses LM, NTLM et NTLMv2 e

Les rponses LM et NTLM sont calcules via la fonction SystemFunction008 (dnie dans e e e advapi32.dll). Si le mode NTLMv2 Session Security est actif, il faut pralablement calculer un e det temporaire via la fonction MD5. 3.3 Utilisation des fonctions SystemFunction00*

Il est particuli`rement intressant de conna e e tre le rle des fonctions SystemFunction006 et o SystemFunction007 car elles prennent en entre une cha de caract`res reprsentant un mot de e ne e e passe en clair. Un programme, ou une librairie, qui utilise ces fonctions est probablement amen ` ea manipuler des mots de passe, ce qui lui donne un intrt certain. Dans le rpertoire System32, on e e e peut citer msv1 0.dll, netapi32.dll, raschap.dll, samlib.dll, kerberos.dll, . . .

4

Formes dauthentication sous WindowsDeux formes dauthentication sont gres par Windows : e e interactives : ces authentications servent ` ouvrir localement une session ` la machine a a crant ainsi une session dauthentication (dtaille au paragraphe suivant). Plusieurs types e e e dauthentication sont possibles, mais la plus connue est lauthentication interactive (do` le u nom) o` les authentiants sont saisis ` laide dune interface graphique (la GINA) et transmis u a au processus LSASS qui les valide ` laide dun Authentication Package (AP) ; a non-interactives : ces authentications interviennent apr`s une authentication interactive. e Elle permet ` un client de sauthentier aupr`s de serveurs distants en utilisant, ventuellement a e e de mani`re transparente, les authentiants saisis lors de lauthentication interactive. Ceci e implique donc lutilisation de mcanismes de mise en cache des credentials fournis ou calculs e e lors des authentications interactives.

5

Sessions dauthentication

Le syst`me Windows dnit la notion de session dauthentication (logon session) qui reprsente e e e un contexte dauthentication applicable ` un processus ou un thread. Une telle session est reprsente a e e par une structure du type SECURITY LOGON SESSION DATA qui contient, entre autres : lidentiant unique de session, dnomm logonID (de type LUID2 ). Il est gnr alatoirement e e e e e e lors de la cration de la session ou constant pour les sessions particuli`res ; e e le domaine et le nom de lutilisateur ; le descripteur de scurit (SID) de lutilisateur ; e e le nom de lAuthentication Packages ayant valid et cr la session ; e ee le type de session dauthentication (Interactive, Rseau, Service, . . .). e Cest le processus LSASS qui est en charge de la gestion de la base contenant ces sessions. Plusieurs utilitaires existent pour consulter cette base [6]. Ils se basent gnralement sur les fonctions e e LsaEnumerateLogonSessions et LsaGetLogonSessionData.2

un LUID est un identiant unique (Locally Unique IDentier ), mais local ` la machine par opposition ` a a un GUID (Globally Unique IDentier ), globalement unique

Actes du symposium SSTIC07LSASS (PID 2D7)MACHINE$ logonID: 0-3e7 Type : Unknown (0) SID : S-1-5-18 SERVICE LOCAL logonID: 0-3e5 Type : Service (5) SID : S-1-5-19

7services (PID 32F)

svchost (PID 42A)

Espace utilisateur

SERVICE RSEAU logonID: 0-3e4 Type : Service (5) SID : S-1-5-20 Administrateur logonID : 0-17b99 Type : Interactive (2) SID : S-1-5-21-...7-500 Credentials : LM : 445F7049... NTLM : AE0DABC8... SHA-1 : 7470E4EE...

notepad (PID 45E)

Espace noyau

nt!_EPROCESS ProcessId : 0x2D7 Token : _EX_FAST_REF nt!_TOKEN AuthenticationId : 0-3e7

nt!_EPROCESS ProcessId : 0x32F Token : _EX_FAST_REF nt!_TOKEN AuthenticationId : 0-3e7

nt!_EPROCESS ProcessId : 0x45E Token : _EX_FAST_REF nt!_TOKEN AuthenticationId : 0-17b99

nt!_EPROCESS ProcessId : 0x42A Token : _EX_FAST_REF nt!_TOKEN AuthenticationId : 0-3e5

Fig. 1: Reprsentation des associations entre les processus, leur jeton dacc`s et les sessions dauthenticae e tion

Pour chaque processus (ou threads), une session dauthentication est associe (voir schma 1). e e Cette association est symbolise par la prsence dans la structure des jetons de scurit (security e e e e tokens de type nt! TOKEN) du champ AuthenticationId. Une session peut tre associe ` un ou e e a plusieurs processus. Lexemple suivant permet avec WinDbg de consulter la valeur de ce champ pour un processus : lkd> !process 0 1 **** NT ACTIVE PROCESS DUMP **** ... PROCESS 89249988 SessionId: 0 Cid: 03c0

Peb: 7ffd5000

ParentCid: 01ec

8


DirBase: 0b5805a0 ObjectTable: e11f4d20 HandleCount: 34. Image: notepad.exe VadRoot 89164b98 Vads 55 Clone 0 Private 142. Modified 0. Locked 0. DeviceMap e29e5358 Token e1263980 ... lkd> dt -r1 nt!_TOKEN e1263980 ... +0x010 TokenId : _LUID +0x000 LowPart : 0x112895 +0x004 HighPart : 0 +0x018 AuthenticationId : _LUID +0x000 LowPart : 0x17b99 +0x004 HighPart : 0 +0x020 ParentTokenId : _LUID +0x000 LowPart : 0 +0x004 HighPart : 0 ... On commence par lister tous les processus puis, pour celui dsir, on ache le contenu du jeton e e de scurit primaire (primary token). Dans lexemple, le processus notepad.exe est associ ` la e e ea session dauthentication 0-17b99.

66.1

Authentications interactivesAuthentication Packages

Lorsque quune ( entit ) souhaite se connecter localement ` un syst`me, la demande est adresse ( e) a e e a ` LSASS qui va devoir valider lauthentication demande. Cependant, cette validation nest pas e ralise directement par LSASS, mais par des librairies dnommes Authentication Packagess (AP). e e e e Si la demande est accepte, lAuthentication Packages gn`re un numro unique de session, le e e e e logonID, et demande ` LSASS de crer une session dauthentication associe ` ce numro via la a e e a e fonction CreateLogonSession. Lors du chargement dun Authentication Packages par LSASS, celui-ci appelle la fonction SpLsaModeInitialize (obligatoirement exporte par un AP) en passant en param`tre une struce e ture de type SECPKG FUNCTION TABLE. Cette structure contient un tableau de pointeurs de fonctions que lAP doit remplir. Ces fonctions, implmentes par lAP, seront appeles ultrieurement par e e e e LSASS. Les fonctions du type LsaApLogonUserX (LsaApLogonUser, LsaApLogonUserEx et LsaApLogonUserEx2) sont particuli`rement importantes car elles sont responsables de la validation des e demandes dauthentication transmises par LSASS. La premi`re fonction ainsi appele par LSASS est SpInitialize laquelle nalise linitialisation e e de lAP. Une structure de type LSA SECPKG FUNCTION TABLE est passe en param`tre et contient e e un tableau de fonctions de ( soutien ) implmentes par LSASS que pourra appeler lAP. Parmi ( ) e e ces fonctions, on peut noter :


9

CreateLogonSession : voque prcdemment, cette fonction permet la cration dune logon e e e e e session par LSASS ; AddCredential : cette fonction permet la mmorisation de credentials. En eet, LSASS ore e la possibilit dassocier ` une session dauthentication des credentials en les sauvant pour e a pouvoir les rutiliser par la suite. Lors de lappel ` la fonction, il faut spcier le logonID e a e dune session, un numro dAuthentication Packages ainsi quune cha de caract`res servant e ne e de cl ; e GetCredentials : complment de la fonction prcdente, celle-ci permet de rcuprer des e e e e e credentials prcdemment sauvs. e e e 6.2 Validation par msv1 0

La grande majorit des validations dauthentication (surtout pour une machine autonome), e est ralise par lAuthentifation Package msv1 0, sollicit par LSASS via lappel de la fonction e e e LsaApLogonUserEx2, dont le prototype est : NTSTATUS LsaApLogonUserEx2( PLSA_CLIENT_REQUEST [in] ClientRequest, SECURITY_LOGON_TYPE [in] LogonType, PVOID [in] ProtocolSubmitBuffer, PVOID [in] ClientBufferBase, ULONG [in] SubmitBufferSize, PVOID* [out] ProfileBuffer, PULONG [out] ProfileBufferSize, PLUID [out] LogonId, PNTSTATUS [out] SubStatus, PLSA_TOKEN_INFORMATION_TYPE [out] TokenInformationType, PVOID* [out] TokenInformation, PUNICODE_STRING* [out] AccountName, PUNICODE_STRING* [out] AuthenticatingAuthority, PUNICODE_STRING* [out] MachineName, PSECPKG_PRIMARY_CRED [out] PrimaryCredentials, PSECPKG_SUPPLEMENTAL_CRED_ARRAY* [out] SupplementalCredentials ); Le param`tre LogonType indique le type dauthentication. Ce param`tre est fondamental, car e e il dtermine la mani`re dont lAP doit eectuer la validation. e e Le plus simple est le type Interactive (LogonType=2). Il sagit dune authentication ralise e e par un utilisateur, localement ` la machine, dont la mthode la plus connue est louverture de a e session physiquement sur la machine, via le clavier et lcran. Mais le service Terminal Server ou e la commande runas ouvrent galement des sessions de type Interactive. Le processus de validation e pour un utilisateur local est le suivant : la fonction LsaApLogonUserEx2 est appele. Le param`tre ProtocolSubmitBuffer reprsente e e e une structure de donnes contenant lidentiant et le mot de passe en clair de lutilisateur, e rcuprs dans la majorit des cas par la GINA et transmis par WinLogon ; e e e e

10


les condensats LM, NTLM du mot de passe sont calculs et stocks dans une structure qui e e contient galement le nom de lutilisateur et de la machine ; e les condensats sont valids en les comparant avec ceux stocks dans la base SAM. Sils sont e e dirents, lauthentication sarrte sur un chec ; e e e une session dauthentication pour lutilisateur est cre et la structure contenant le nom de ee lutilisateur et les condensats est chire (` partir de Windows XP), puis sauvegarde via e a e lappel de la fonction AddCredential oerte par LSASS (avec la cl Primary). e ` A partir de Windows XP, le condensat SHA-1 est galement calcul et sauv avec les condensats e e e LM et NTLM. Il est utilis en particulier par DPAPI [5]. e Lautre type est le type Service (LogonType=5), utilis pour crer les sessions dauthentication e e associes aux comptes de services. Il faut pralablement rappeler les dirents comptes sous lesquels e e e les services peuvent sexcuter : e LocalSystem : le processus tourne sous lidentit SYSTEM (SID S-1-5-18), cest-`-dire e a avec beaucoup de privil`ges. Le processus a la possibilit de sauthentier sous lidentit de e e e la machine car il est associ ` la session dauthentication 0-3e7 (ce numro de logonID est ea e toujours identique). La cration de cette session est dtaille dans le paragraphe 6.3 ; e e e NetworkService : le processus tourne sous lidentit SERVICE RESEAU (SID S-1-5-20), e mais avec peu de privil`ges. Cependant, il conserve la possibilit de pouvoir sauthentier sous e e lidentit de la machine et il est associ ` la session 0-3e4 ; e ea LocalService : le processus tourne sous lidentit SERVICE LOCAL (SID S-1-5-19), et e dispose de peu de privil`ges. Il na pas non plus la capacit de sauthentier, car il est toujours e e associ ` la session 0-3e5 ` laquelle aucun credential nest associ ; ea a e enn, il est possible de spcier explicitement un compte dutilisateur et le mot de passe e associ. Les privil`ges et le contexte dauthentication sont alors ceux du compte utilis. e e e e e e Cest dans ce dernier cas que lAP msv1 0 va tre sollicit. La procdure de validation est la mme que pour celle de type Interactive mais avec une dirence majeure : le mot de passe nest e e pas fourni lors de lappel de la fonction LsaApLogonUserEx2. LAP va consulter les secrets de la LSA pour le trouver, en recherchant lentre correspondante au nom du service prx par SC . e e e Par exemple, si le nom du service est DemoSrv, lentre SC DemoSrv contiendra le mot de passe ` e a utiliser. La suite de la validation reste identique (y compris la sauvegarde des condensats). Lexemple suivant montre un extrait des secrets de la LSA correspondant ` lentre du mot de a e passe du compte associ au service DemoSrv : e _SC_DemoSrv 50 00 61 00 73 00 73 00 31 00 32 00 20 00 21 00 3A 00 6.3 Authentication de la machine

P.a.s.s.1.2. .!. :.

Dans un domaine Windows 2000 ou 2003 utilisant lActive Directory, les machines sont considres e e comme des ( acteurs ) au mme titre que les utilisateurs. Elles poss`dent donc un identiant (le nom ( ) e e e de la machine suivi de ) ainsi quun mot de passe, connu par le syst`me et lActive Directory. Ils sont dailleurs renouvels priodiquement, comme pour les mots de passe des comptes utilisateurs. e e


11

Cette capacit oerte aux machines de sauthentier a permis de supprimer les acc`s anonymes ` e e a certains partages SMB ou services RPC. An que des processus (essentiellement des services) soient capables de sauthentier dans le contexte de la machine, il faut obligatoirement crer une session dauthentication quils pourront e utiliser. Cette session est cre pendant linitialisation de LSASS sans passer par un processus ee dauthentication et ses caractristiques sont : e le nom de lutilisateur qui correspond ` celui de la machine, sux par ; a e le SID qui est S-1-5-18, reprsentant le compte SYSTEM ; e le logonID qui est toujours 0-3e7. Le mot de passe utilis pour gnrer les credentials associs ` cette session va tre lu dans e e e e a e les secrets de la LSA en consultant lentre MACHINE.ACC. Si la machine nest pas membre dun e domaine, lentre nexistant pas, aucun credential nest associ. En revanche, si la machine est e e membre dun domaine, lentre contient le mot de passe de la machine. Les condensats LM, NTLM e et SHA-1 sont calculs puis sauvegards via lappel de la fonction AddCredential toujours associs e e e a ` la cl Primary. e Il est important de prciser que le compte de la machine peut sauthentier sur tous les syst`mes e e membres du domaine (serveurs et postes clients). Lexemple suivant montre un extrait des secrets de la LSA correspondant ` lentre du mot de passe de la machine : a e $MACHINE.ACC D7 3F 94 CC 37 45 29 50 7A 16 BA B8 52 91 70 F6 83 02 AB 6F 64 7E 1B F4 A1 56 C3 15 .?..7E)Pz...R.p. ...od~...V..

7

Authentications non-interactives

Lautre partie des composants dauthentication de Windows concerne la forme des authentications dites non-interactives, cest-`-dire permettant de raliser une authentication ` disa e a tance. Les informations contenues dans les sessions dauthentication prcdemment cres peuvent e e ee ventuellement tre utilises. e e e 7.1 Security Support Provider

Les authentications non-interactives sont mises en uvre via SSPI (Security Support Provider Interface) qui ore une interface de programmation unie aux applications. Les authentications e oertes par SSPI sont traites par des fournisseurs (providers) appels Security Support Provider e e (SSP). Les principaux fournisseurs de base distribus en standard par Microsoft sont : e Microsoft NTLM (msv1 0.dll) qui prend en charge lauthentication via le protocole NTLMSSP et la mise en uvre des trois algorithmes de d/rponse LM, NTLM et NTLMv2. e e Il est fondamental pour ce package de disposer des condensats LM et NTLM pour gnrer e e correctement les rponses adquates aux ds soumis ; e e e Microsoft Kerberos (kerberos.dll) qui ore une authentication base sur Kerberos v5 ; e Microsoft Negotiate qui est un pseudo-fournisseur. Il permet de ngocier lutilisation du e package NTLM ou Kerberos suivant des crit`res de scurit et de compatibilit. e e e e

12


7.2

Mise en uvre Trois fonctions exportes par secur32.lib mettent en uvre SSPI (voir gure 2) : e AcquireCredentialsHandle : appele ct client et serveur, cette fonction permet dinitialiser e o e un fournisseur qui prendra en charge lauthentication ; InitializeSecurityContext : appele ct client, cette fonction est utilise pour initier et e o e e raliser une authentication vers un serveur ; e AcceptSecurityContext : appele ct serveur, cette fonction permet de traiter et de rpondre e o e e aux requtes dauthentication mises par un client. e e

AcquireCredentialsHandle( SEC_CHAR* pszPrincipal, SEC_CHAR* pszPackage, PCredHandle phCredential );

AcquireCredentialsHandle( SEC_CHAR* pszPrincipal, SEC_CHAR* pszPackage, PCredHandle phCredential );

CLIENTInitializeSecurityContext( PCredHandle phCredential, PCtxtHandle phContext, SEC_CHAR* pszTargetName, PSecBufferDesc pInput, PCtxtHandle phNewContext, PSecBufferDesc pOutput ); InitializeSecurityContext( PCredHandle phCredential, PCtxtHandle phContext, SEC_CHAR* pszTargetName, PSecBufferDesc pInput, PCtxtHandle phNewContext, PSecBufferDesc pOutput ); InitializeSecurityContext( PCredHandle phCredential, PCtxtHandle phContext, SEC_CHAR* pszTargetName, PSecBufferDesc pInput, PCtxtHandle phNewContext, PSecBufferDesc pOutput );

SERVEUR

changes sur le rseau

AcceptSecurityContext( PCredHandle phCredential, PCtxtHandle phContext, PSecBufferDesc pInput, PCtxtHandle phNewContext, PSecBufferDesc pOutput );

AcceptSecurityContext( PCredHandle phCredential, PCtxtHandle phContext, PSecBufferDesc pInput, PCtxtHandle phNewContext, PSecBufferDesc pOutput );

Fig. 2: Schma des appels aux fonctions SSPI e

Les fonctions InitializeSecurityContext et AcceptSecurityContext gn`rent (param`tre e e e pOutput) et acceptent (param`tre pInput) des blocs binaires qui doivent tre transmis entre le client e e


13

et le serveur. Ces blocs doivent tre encapsuls dans un autre protocole pour pouvoir tre changs e e e e e sur le rseau. Par exemple, lorsque le mode ( authentication intgre Windows ) est activ, Internet e ( e e ) e Explorer utilise les champs Authorization (client vers le serveur) et WWW-Authenticate (serveur vers le client) du protocole HTTP pour les transporter. Lutilisation avec le protocole SMB est dtaille dans le chapitre 9. e e ` A la n des changes les fonctions rendent leur verdict (SEC E OK dans le cas dune authentie cation russie, SEC E LOGON DENIED sinon). e Ct client, lors de lappel ` la fonction AcquireCredentialsHandle, il est possible de spcier o e a e explicitement un nom dutilisateur et un mot de passe ` utiliser pour lauthentication via le paa ram`tre dentre optionnel pAuthData. Celui-ci reprsente une structure du type SEC WINNT AUTH Ie e e DENTITY dont la dnition est : e typedef struct _SEC_WINNT_AUTH_IDENTITY { unsigned short __RPC_FAR* User; unsigned long UserLength; unsigned short __RPC_FAR* Domain; unsigned long DomainLength; unsigned short __RPC_FAR* Password; unsigned long PasswordLength; unsigned long Flags; } SEC_WINNT_AUTH_IDENTITY, *PSEC_WINNT_AUTH_IDENTITY; Si ce param`tre est renseign, les authentiants spcis (nom dutilisateur et mot de passe) e e e e sont utiliss pour lauthentication. Dans le cas contraire (pAuthData ` NULL), les credentials ( par e a ( dfaut ) sont utiliss. Il nest alors pas ncessaire de fournir des credentials, car ceux associs ` la e ) e e e a session dauthentication du programme appelant la fonction sont utiliss. e ` A noter le cas particulier dun programme avec le privil`ge SE TCB NAME (agir en tant que partie e du syst`me dexploitation) qui peut spcier explicitement un identiant de session dauthenticae e tion an dutiliser les credentials associs. e 7.3 Rcupration des credentials par le SSP e e

Il est important de bien comprendre la rpartition des dirents rles. Une application cliente qui e e o souhaite sauthentier aupr`s dun serveur en utilisant SSPI (par exemple via la mise en uvre du e SSP msv1 0) va recevoir un d du serveur. Pour y rpondre correctement (donc sauthentier) elle e e doit calculer une rponse en utilisant les condensats LM ou NTLM. Le processus LSASS conserve e pour chaque session dauthentication un jeu de credentials constitu des dirents condensats, e e mais le processus ne peut videment pas en disposer directement. Il doit donc transmettre ` LSASS e a les ds reus, qui calculera les rponses en utilisant les credentials associs ` la session dauthene c e e a tication du processus lui soumettant la requte. Lopration est identique lorsquun serveur reoit e e c des demandes dauthentication de la part dun client : les messages reus sont transmis ` LSASS. c a Cest par le mcanisme des LPC (Local procedure call ) que la communication va soprer. Pour e e rappel, les LPC sont des RPC (Remote Procedure Call ) limites localement au syst`me (en principe). e e Lorsque LSASS sinitialise, deux ports LPC sont crs : ee

14


\SeLsaCommandPort est le port LPC permettant une communication exclusive entre le noyau et LSASS ; \LsaAuthenticationPort est le port LPC qui nous intresse, car cest celui que les applicae tions ou le noyau utilisent pour adresser leurs demandes dauthentication. La procdure de communication, par le biais de ce port, entre un processus et LSASS est la e suivante : 1. dans le processus client, la fonction AcquireCredentialsHandle est appele. Elle ouvre une e connexion LPC vers LSASS puis demande lacquisition des credentials de lutilisateur ; 2. LSASS reoit la demande et laiguilleur LPC dirige lappel vers une fonction charge dobtenir c e des informations sur le processus appelant, en particulier son numro de session dauthentie cation. Le mcanisme de changement didentit (impersonation) est mis en uvre et permet e e au thread traitant la demande dagir temporairement avec un jeton de scurit (impersonation e e token) identique ` celui du processus client appelant la fonction LPC ; a 3. La fonction consulte ensuite ce jeton de scurit et deux informations sont rcupres : e e e e e le champ AuthenticationId qui contient un numro de session dauthentication. Il sagit e donc de celui de la session du processus client, la prsence ou non didentiants de scurit dans la liste des SIDs restreints (restricted SIDs) e e e du jeton via un appel ` la fonction IsTokenRestricted; a 4. si la fonction IsTokenRestricted renvoie VRAI, lappel sarrte immdiatement, et la fonction e e AcquireCredentialsHandle renvoie lerreur 0x8009030E au client (SEC E NO CREDENTIALS : No credentials are available in the security package). Il est donc impossible de continuer la procdure dauthentication. Dans le cas contraire, un handle de type SecHandle est retourn e e au client ; 5. le processus client poursuit son authentication par des appels ` la fonction InitializeSecuria tyContext en spciant le handle rcupr prcdemment. Si le processus LSASS est amen ` e e e e e e ea manipuler des credentials, un appel ` GetCredentials permettra de les rcuprer. Le numro a e e e de session pass en param`tre correspondra ` celui rcupr lors de linitialisation, cest-`-dire e e a e e e a celui de la session du client.

88.1

Outils de rcupration e eCredentials associs aux logon sessions e

Principe Si des credentials constitus de condensats sont sauvs, il faut se prmunir contre le risque e e e de divulgation de ceux-ci. Une technique de rcupration consiste ` lister toutes les sessions actives e e a sur le syst`me (voir chapitre 5), puis pour chacune dentre elles, de rcuprer les credentials associs e e e e via lappel ` la fonction GetCredentials oerte par LSASS. Cette fonction prend en param`tres : a e LogonId : lidentiant unique de la session, rcupr via les fonctions dnumration ; e e e e e AuthenticationPackage : le numro de lAuthentication Packages, rcupr galement par e e e ee les fonctions dnumration. e e La fonction retourne alors tous les credentials sauvs, ainsi que les cls spcies lors de la e e e e sauvegarde. La cl Primary indique les credentials sauvs par lAP msv1 0 lors de la cration de e e e ` la session. A partir de Windows XP, les structures contenant les credentials sont chires ce qui e ncessite de les dchirer pralablement. e e e


15

Pour tre autoris ` accder aux credentials, il est ncessaire de sinjecter dans le procese e a e e sus LSASS (via un classique OpenProcess, VirtualAllocEx, WriteProcessMemory). La fonction OpenProcess ncessite le privil`ge SeDebugPrivilege, accord uniquement aux Administrateurs. e e e Les sessions sont alors numres via lexcution (CreateRemoteThread) de la fonction injecte. e e e e e Pour chaque session ouverte sur la machine, diverses informations sont retournes : e le nom de lutilisateur, son identiant de scurit (SID) et le numro de la session dauthene e e tication ; le nom de lAuthentication Packages ayant cr la session, ainsi que le type de session (interee active, rseau, service, . . .) ; e les credentials sauvs pour cette session, ainsi que les cls associes. e e e Exemple dutilisation dun outil de diagnostic : Administrateur Type : Interactive (2) Session : 0, logonID : 0-17b99 Authentication Package : NTLM SID : S-1-5-21-484888444-1244599845-468754557-500 Primary credentials MACHINE\Administrateur LM : 445F70495C5F594018FCD526FB48A829 NTLM : AE0DABC86921C8D0FB2F1EB234DC3AD7 SHA-1 : 7470E4EE37E27BF990AFA1E57A083C2EE6247516 MACHINE$ Type : Unknown (0) Session : 0, logonID : 0-3e7 Authentication Package : NTLM SID : S-1-5-18 SERVICE LOCAL Type : Service (5) Session : 0, logonID : 0-3e5 Authentication Package : Negotiate SID : S-1-5-19 SERVICE RSEAU E Type : Service (5) Session : 0, logonID : 0-3e4 Authentication Package : Negotiate SID : S-1-5-20 Primary credentials DOMAINE\MACHINE$ LM : AAD3B435B51404EEAAD3B435B51404EE NTLM : 31D6CFE0D16AE931B73C59D7E0C089C0 SHA-1 : DA39A3EE5E6B4B0D3255BFEF95601890AFD80709

16


Dans cet exemple, le mot de passe de lAdministrateur est sstic2007. On constate bien la prsence des sessions 0-3e4, 0-3e5 et 0-3e7 utilises par les comptes de service. La machine ntant e e e pas membre dun domaine, il ny a pas de credential associ ` la session 0-3e7. Quant ` la session ea a 0-3e4, il sagit des condensats correspondant ` un mot de passe vide. a 8.2 Scurisation des mcanismes de d/rponse e e e e

Le mcanisme des sessions dauthentication est plutt bien conu. Il permet lors de lauthentie o c cation interactive de mettre en cache des credentials, puis lors des authentications non-interactives, de les utiliser, mais sans pouvoir les manipuler directement. Sil nest pas possible ` un utilisateur a de rcuprer ses credentials (donc potentiellement son mot de passe), il est cependant possible via e e SSPI de rcuprer un change de d/rponse utilisant ses credentials. e e e e e Le principe pourrait consister ` appeler dans un programme la fonction AcquireCredentialsa Handle pour initialiser SSPI en demandant ` utiliser les credentials par ( dfaut ) de lutilisateur a ( e ) (param`tre pAuthData=NULL) et le SSP Microsoft NTLM (param`tre pszPackage="NTLM" pour e e manipuler des messages NTLMSSP). Ensuite un d (message NTLMSSP de type 2), gnr de e e e e toutes pi`ces, est soumis ` la fonction InitializeSecurityContext. On veillera dans ce d ` e a e a positionner le bit indiquant le support du mode NTLMv2 Session Response ` 0 an de ne pas le a ngocier (voir paragraphe 2.3). Un message NTLMSSP de type 3 est retourn (rponse) qui contient e e e soit : une rponse LM et NTLM si le mode NTLMv2 Session Security nest pas ngoci ; e e e un d du client et une rponse NTLM modie si le mode NTLMv2 Session Security est e e e ngoci ; e e une rponse LMv2 et NTLMv2 si lutilisation du protocole NTLMv2 est ngoci. e e e La rponse du client dpend de la valeur du param`tre LMCompatibilityLevel (KB2398693). e e e Dans tous les cas, un d/rponse complet est rcupr. Il est alors possible de faire une attaque e e e e e en force brute pour essayer de retrouver le condensat LM ou NTLM, puis le mot de passe. Il est important de souligner que cette technique est possible pour tous les utilisateurs et ne requiert pas de droits particuliers. Comme on a vu dans le paragraphe 7.3 un tel programme ne fonctionne pas si son jeton dacc`s contient des SIDs restreints. Pour excuter un programme en e e restreignant ses droits et privil`ges, il faut utiliser un logiciel spcialis du type [2] ou [7]. Depuis e e e Windows XP, lexplorateur Windows permet nativement cette fonctionnalit en utilisant le bouton e droit de la souris, puis en slectionnant loption ( Executer en tant que. . . ) et ( Protger mon e ( ) ( e ordinateur et mes donnes des programmes non autoriss ) e e ). Auto-Auth.exe Exemple avec un compte dont le mot de passe est sstic2007 et la cl LMCompatibie lityLevel 1 : [NTLM Message Type] 2 (NTLMSSP_CHALLENGE) [NTLM Challenge] 05deac1efc002a09 [NTLM Message Type] 3 (NTLMSSP_AUTH)3

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


17

[Lan Manager Response] 19eb24a7047091f2ce88574ec575c844ed5546ecc2599286 [NTLM Response] c163de084d2553ba55f40963b330b205798f91a645f0706c Si la cl LMCompatibilityLevel=2, la rponse LM nest plus gnre et est identique ` la rponse e e e e e a e NTLM : [NTLM Message Type] 2 (NTLMSSP_CHALLENGE) [NTLM Challenge] 05deac1efc002a09 [NTLM Message Type] 3 (NTLMSSP_AUTH) [Lan Manager Response] c163de084d2553ba55f40963b330b205798f91a645f0706c [NTLM Response] c163de084d2553ba55f40963b330b205798f91a645f0706c Si la cl LMCompatibilityLevel est 3, les rponses LMv2 et NTLMv2 sont systmatiquement e e e renvoyes : e [NTLM Message Type] 2 (NTLMSSP_CHALLENGE) [NTLM Challenge] 05deac1efc002a09 [NTLM Message Type] 3 (NTLMSSP_AUTH) [Lan Manager Response] ce61560b92616aa1f5f51d9a651bd0bd76e078c9956fa7bf [NTLMv2 Response] Domain name: MACHINE User name: Administrateur Parades An de se prmunir contre dventuels codes malveillants utilisant ce mcanisme, il faut e e e appliquer ces trois r`gles : e positionner la cl LMCompatibilityLevel ` une valeur 3, lidal tant 5 ; e a e e choisir un mot de passe rpondant ` des crit`res srieux en termes de taille et de complexit ; e a e e e renouveler priodiquement son mot de passe. e

99.1

Application au protocole CIFS/SMBRappel

SMB (Server Message Block) ou CIFS (Common Internet File System) est le protocole utilis sous Windows pour le partage de chiers. Il prend galement en charge les canaux nomms e e e e e via le partage IPC, ce qui inclut les RPC sur canaux nomms (ncacn np). Il est donc tr`s largement utilis. e Lors de la mise en place dune connexion SMB (voir gure 3), les deux premiers changes e (messages Negotiate Protocol Request) permettent de ngocier le dialecte SMB. Ensuite, des e messages Session Setup AndX Request sont changs an de raliser lauthentication. Le proe e e tocole SMB se base enti`rement sur SSPI pour eectuer cette authentication entre le client et le e serveur. Les blocs mis par les fonctions InitializeSecurityContext et AcceptSecurityContext e sont changs via le param`tre Security Blob des messages Session Setup AndX Request. e e e

18


ClientNegotiate Protocol Request

Serveur

Negotiate Protocol Request Session Setup AndX Request ... Security Blob NTLMSSP (NEGOTIATE)

Session Setup AndX Request ... Security Blob NTLMSSP (CHALLENGE) ChallengeServeur

Session Setup AndX Request ... Security Blob NTLMSSP (AUTH) ReponseLM ReponseNTLM

Session Setup AndX Request

Fig. 3: Echanges SMB


19

Le fournisseur Negotiate est invoqu avec cifs:// comme nom de cible (pae ram`tre pszTargetName). Celui-ci ngocie lutilisation du fournisseur NTLM ou Kerberos : e e si la machine est autonome, le fournisseur NTLM est systmatiquement utilis ; e e ` partir de Windows 2000, si la machine est membre dun domaine et que la cible est connue a dans lActive Directory, le fournisseur Kerberos est utilis ; e si la machine est membre dun domaine mais que la cible nest pas connue dans lActive Directory (par exemple parce quelle est rfrence par son adresse IP), le fournisseur NTLM ee e est utilis. e 9.2 Authentication avec les authentiants de la session La commande suivante permet de se connecter au partage SMB appel C : e net use \\192.168.0.1\c$ Comme aucun nom dutilisateur ni mot de passe nest spci, il en sera de mme lors de e e e linitialisation du fournisseur Negotiate. Ainsi lauthentication va tre ralise dans le contexte e e e dauthentication de lutilisateur initiant la commande, via lutilisation des credentials par dfaut. e 9.3 Authentication en changeant dutilisateur

Il est galement possible de spcier ` la commande net un nom dutilisateur et un mot de passe e e a alternatif pour raliser la connexion SMB : e net use \\192.168.0.1\c$ pass123 /user:Administrateur Ces authentiants sont transmis au fournisseur Negotiate qui peut ainsi raliser lauthenticae tion dans le contexte spci. A lajout du partage, cest donc lutilisateur qui fournit explicitement e e ` le mot de passe. Mais il est intressant de constater que le syst`me est toujours capable de russir une authene e e tication LM ou NTLM tant que le partage nest pas supprim (ct client). Ceci indique quun e o e mcanisme de cache conserve les condensats LM et NTLM ou plus simplement le mot de passe. e Cependant, comme voqu au paragraphe 7.2, le changement de contexte dauthentication ne e e peut se faire que lors de lappel de la fonction AcquireCredentialsHandle en fournissant un nom e dutilisateur et un mot de passe en clair (structure SEC WINNT AUTH IDENTITY via le param`tre pAuthData). Cest donc forcment le mot de passe en clair qui est sauvegard dans un cache. e e Ce cache se trouve dans le noyau. Le pilote (driver ) SMB (mrxsmb.sys) maintient une base indiquant pour chaque machine distante les authentiants a utiliser lorsque quune connexion ` un ` a partage SMB est ralise. Pour chaque entre de la base on trouve : e e e le nom de la machine ; le nombre de partages actifs vers cette machine ; le numro de la session dauthentication associe ; e e le nom de lutilisateur et le domaine devant tre utiliss pour lauthentication. Si cette e e information nest pas prsente, les credentials par dfaut seront utiliss, cest-`-dire ceux e e e a associs ` la session ; e a le mot de passe en clair ` utiliser si un nom dutilisateur alternatif a t spci. a ee e e

20


Un seul nom dutilisateur peut tre associ ` une machine donne. Si on tente dutiliser un autre e ea e nom dutilisateur, lerreur 12194 est renvoye. e 9.4 Mesures de protection

La base gre par le pilote mrxsmb.sys peut tre consulte. Cette base tant situe dans lespace e e e e e e mmoire du noyau, il faut passer par lcriture dun pilote. Apr`s le chargement de celui-ci, il localise e e e la base et la parcourt pour retourner toutes les entres. On retrouverait ainsi les informations e numres au paragraphe prcdent. Si pour une entre donne le nom dutilisateur et le mot de e e e e e e e passe ne sont pas prsents, ce sont alors les authentiants de la session associe qui sont utiliss. e e e Un tel utilitaire doit sexcuter avec des privil`ges dAdministrateur ncessaires pour linstallae e e tion du pilote. Une fois celui-ci install, nimporte quel utilisateur peut consulter la base. e Illustration : Base des sessions SMB : [\192.168.0.2] (2 rfrences) e e logonID : 0-17b99 Machine/Domaine : DOMTEST Utilisateur : (aucun) Mot de passe : (aucun) [\192.168.0.1] (1 rfrence) e e logonID : 0-17b99 Machine/Domaine : DOMTEST Utilisateur : Administrateur Mot de passe : pass123 La premi`re entre indique une authentication ralise avec les credentials associs ` la session e e e e e a 0-17b99. Il est recommand de supprimer les entres inutiles de la base en se dconnectant des partages e e e inutiliss. La commande net use permet de visualiser les partages actifs. La commande net use e /delete permet de supprimer des partages. Lorsque tous les partages vers une machine donne ont e t supprims, lentre est eace de la base des caches. ee e e e C:\>net use tat E Local Distant --------------------------------------OK Z: \\192.168.0.2\Partage OK \\192.168.0.1\c$ C:\>net use /delete z:4

Le message derreur est : Plusieurs connexions ` un serveur ou ` une ressource partage par le mme a a e e utilisateur, en utilisant plus dun nom utilisateur, ne sont pas autorises. Supprimez toutes les connexions e prcdentes au serveur ou ` la ressource partage et recommencez e e a e


21

Z: a t supprim. e e e C:\>net use /delete \\192.168.0.1\c$ \\192.168.0.1\c$ a t supprim. e e e C:\>net use La liste est vide. C:\>dumpsmb.exe Base des sessions SMB : La base est vide.

10

Conclusion

Lauthentication sous Windows est gre par un dispositif particuli`rement ( sophistiqu ) e e e ( e ) mais qui reste transparent pour lutilisateur. Cet article a essay dclaircir certains mcanismes, e e e en particulier celui de la mise en cache des credentials. Il faut garder ` lesprit quil est ncessaire de disposer de privil`ges dAdministrateur pour a e e manipuler directement les bases des caches et que lapplication des bonnes pratiques usuelles est indispensable. Mais il est important conna leur existence et le risque de divulgation suite ` la tre a compromission dune machine.

Rfrences ee1. Glass, E. : The NTLM Authentication Protocol and Security Support Provider. http://davenport. sourceforge.net/ntlm.html 2. Howard, M. : Browsing the Web and Reading E-mail Safely as an Administrator. http://msdn2. microsoft.com/en-us/library/ms972827.aspx 3. Johansson, J. : The Most Misunderstood Windows Security Setting of All Time. http://www. microsoft.com/technet/technetmag/issues/2006/08/SecurityWatch/default.aspx?loc=fr/ 4. JoMo-kun : Passing the Hash. http://www.foofus.net/jmk/passhash.html 5. NAI Labs, Network Associates : Windows Data Protection. http://msdn2.microsoft.com/en-us/ library/ms995355.aspx 6. Russinovich, M. : LogonSessions. SystemInformation/LogonSessions.mspx http://www.microsoft.com/technet/sysinternals/

7. Russinovich, M. : PsExec. http://www.microsoft.com/technet/sysinternals/utilities/psexec. mspx

Documents

SSTIC07 Article Bordes Secrets Authentification Windows