Supprimer certaines entrées du cache LSA ?

Le
bigstyle [MVP]
Bonjour,

certains d'entre vous ont-ils déjà trouvé une solution afin d'éviter le
type d'attaque permettant de récupérer des infos de mot de passe via le
cache LSA ?

Comment avez-vous réglé le probleme ?
Est-ce que le fait de supprimer des entrées dans la base de registre
peut avoir des conséquences néfastes ?

Merci

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Emmanuel Dreux [MS]
Le #727762
Bonjour,

si c'est pour vous une problématique forte, vous pouvez positionner le
nombre d'entrées du cache à 0 ( par GPO).

Le risque principal, c'est lors d'un vol de portable.
Dans ce cas, il vous faudra également prendre en compte le pagefile qui peut
contenir des informations importantes, également des données confidentielles
à encrypter sur le disque.

--
Cordialement,

Emmanuel Dreux.

"bigstyle [MVP]" news:
Bonjour,

certains d'entre vous ont-ils déjà trouvé une solution afin d'éviter le
type d'attaque permettant de récupérer des infos de mot de passe via le
cache LSA ?

Comment avez-vous réglé le probleme ?
Est-ce que le fait de supprimer des entrées dans la base de registre peut
avoir des conséquences néfastes ?

Merci

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security




bigstyle [MVP]
Le #727759
Bonjour,

si c'est pour vous une problématique forte, vous pouvez positionner le nombre
d'entrées du cache à 0 ( par GPO).

Le risque principal, c'est lors d'un vol de portable.
Dans ce cas, il vous faudra également prendre en compte le pagefile qui peut
contenir des informations importantes, également des données confidentielles
à encrypter sur le disque.

--
Cordialement,

Emmanuel Dreux.

"bigstyle [MVP]" news:
Bonjour,

certains d'entre vous ont-ils déjà trouvé une solution afin d'éviter le
type d'attaque permettant de récupérer des infos de mot de passe via le
cache LSA ?

Comment avez-vous réglé le probleme ?
Est-ce que le fait de supprimer des entrées dans la base de registre peut
avoir des conséquences néfastes ?

Merci

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security





Bonjour et merci pour votre réponse.

C'est une problématique assez forte dans la mesure où des applications
comme PC Anywhere ou Dameware NT Utilities stockent les mots de passe à
cet endroit (donc depuis les postes d'admin, un trés grand nombre de
mot de passe y sont stockés)

Concernant le nombre d'entrées du cache à 0, cela m'ennuie par rapport
aux ordinateurs portables car, si j'ai bien compris, ce paramètre
empêchera les utilisateurs nomades à ouvrir une session si aucun DC
n'est disponible, non ?

Par ailleurs, et bizarrement contrairelemnt à ce que j'ai pu lire, la
lecture de mon cache LSA ne m'a pas permis de mettre en évidence le mot
de passe de mon compte de domaine (avec lequel je suis loggué
actuellement).

Mon but final n'est pas de le trouver mais évaluer si le risque est
tout de même bien présent pour ce compte.

Merci pour vos futurs conseils.

Cordialement,

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security


Nina Popravka
Le #727758
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]

Par ailleurs, et bizarrement contrairelemnt à ce que j'ai pu lire, la
lecture de mon cache LSA ne m'a pas permis de mettre en évidence le mot
de passe de mon compte de domaine (avec lequel je suis loggué
actuellement).


MDR...
Oui, on lit beaucoup de bêtises. C'est à peu près du même niveau que
le "en 5mn on craque un pass NT avec LoophtCrack" d'il y a 10 ans ;->
(moi, en plusieurs semaine, j'ai jamais cracké le mien...)
Le passe n'est pas en clair, bien entendu ; mais avec un pass très
peu robuste, beaucoup de temps, et de la chance, oui, on peut le
trouver.
Enfin c'est, personnellement, une problématique qui me laisse
parfaitement indifférente pour le niveau de sécurité dont j'ai besoin.
--
Nina

bigstyle [MVP]
Le #727755
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]

Par ailleurs, et bizarrement contrairelemnt à ce que j'ai pu lire, la
lecture de mon cache LSA ne m'a pas permis de mettre en évidence le mot
de passe de mon compte de domaine (avec lequel je suis loggué
actuellement).


MDR...
Oui, on lit beaucoup de bêtises. C'est à peu près du même niveau que
le "en 5mn on craque un pass NT avec LoophtCrack" d'il y a 10 ans ;->
(moi, en plusieurs semaine, j'ai jamais cracké le mien...)
Le passe n'est pas en clair, bien entendu ; mais avec un pass très
peu robuste, beaucoup de temps, et de la chance, oui, on peut le
trouver.
Enfin c'est, personnellement, une problématique qui me laisse
parfaitement indifférente pour le niveau de sécurité dont j'ai besoin.


Bonjour Nina,

la lecture du mot de passe LSA n'utilise pas une technique de
"crackage", la découverte de ces derniers est instantanée.

Par ailleurs, Emmanuel semblait confirmer que le compte de domaine
était lisible via le cache LSA. (en me conseillant de passer la valeur
du nombre d'entrées du cache à 0).

Pour moi la problématique est importante notamment pour les postes
d'admin (cf post précédent :))

@bientot

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security


Nina Popravka
Le #727513
On Wed, 18 Apr 2007 17:22:41 +0200, bigstyle [MVP]

la lecture du mot de passe LSA n'utilise pas une technique de
"crackage", la découverte de ces derniers est instantanée.


Je pense que vous vous trompez et parlez plutôt de quelque chose de ce
genre :
Sinon, si y a un endroit où tous les pass sont en clair, je veux
immédiatement savoir où. :-)
--
Nina

bigstyle [MVP]
Le #727512
On Wed, 18 Apr 2007 17:22:41 +0200, bigstyle [MVP]

la lecture du mot de passe LSA n'utilise pas une technique de
"crackage", la découverte de ces derniers est instantanée.


Je pense que vous vous trompez et parlez plutôt de quelque chose de ce
genre :
Sinon, si y a un endroit où tous les pass sont en clair, je veux
immédiatement savoir où. :-)


Effectivement je parle d'une méthode similaire.
Par craquage, j'entendais par là "Brute force ou via dictionnaire". Là,
c'est un décryptage qui s'opère et qui fait que certains mots de passe
sont affichés de façon instantannés.

Si Emmanuel Dreux a d'autres informations ou conseils la dessus je suis
preneur ! (ou les autres ;))

@bientot

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security


Emmanuel Dreux [MS]
Le #727506
Bonjour,

exactement.

Il y a plusieurs "choses" stockées dans le cache LSA:

Les cached credentials ( 10 par défaut): les hashs des 10 derniers
interactifs logons sont stockés pour permettre d'ouvrir une session
localement en absence de DC (ex à la maison).
Ce sont des hashs qui sont stockés pas des mots de passe, et effectivement
avec un peu de patience (beaucoup !!!) ça pourrait être crackable.

Ensuite les hash des comptes utilisés par les services qui tournent sous des
comptes utilisateurs de domaine ou locaux sont également stockés.

Des applications peuvent également y stocker leurs secrets.

Pour accéder à cette partie, il faut être déjà administrateur, donc...

Le risque reste donc une attaque offline lors d'un vol de portable.

--
Cordialement,

Emmanuel Dreux.

"Nina Popravka" news:
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]

Par ailleurs, et bizarrement contrairelemnt à ce que j'ai pu lire, la
lecture de mon cache LSA ne m'a pas permis de mettre en évidence le mot
de passe de mon compte de domaine (avec lequel je suis loggué
actuellement).


MDR...
Oui, on lit beaucoup de bêtises. C'est à peu près du même niveau que
le "en 5mn on craque un pass NT avec LoophtCrack" d'il y a 10 ans ;->
(moi, en plusieurs semaine, j'ai jamais cracké le mien...)
Le passe n'est pas en clair, bien entendu ; mais avec un pass très
peu robuste, beaucoup de temps, et de la chance, oui, on peut le
trouver.
Enfin c'est, personnellement, une problématique qui me laisse
parfaitement indifférente pour le niveau de sécurité dont j'ai besoin.
--
Nina



bigstyle [MVP]
Le #727301
Bonjour,

exactement.

Il y a plusieurs "choses" stockées dans le cache LSA:

Les cached credentials ( 10 par défaut): les hashs des 10 derniers
interactifs logons sont stockés pour permettre d'ouvrir une session
localement en absence de DC (ex à la maison).
Ce sont des hashs qui sont stockés pas des mots de passe, et effectivement
avec un peu de patience (beaucoup !!!) ça pourrait être crackable.

Ensuite les hash des comptes utilisés par les services qui tournent sous des
comptes utilisateurs de domaine ou locaux sont également stockés.

Des applications peuvent également y stocker leurs secrets.

Pour accéder à cette partie, il faut être déjà administrateur, donc...

Le risque reste donc une attaque offline lors d'un vol de portable.

--
Cordialement,

Emmanuel Dreux.



J'avoue ne pas bien comprendre le processus de mise en cache LSA pour
les comptes de domaine dans la mesure où je viens de faire le test sur
deux postes différents.(2000 et XP)
Je me suis loggué avec un compte de domaine puis j'ai fermé la session.
Je me suis alors logué avec un compte admin mais je n'ai pas vu de hash
pour le mot de passe de mes comptes windows.(les cached credentials
sont à 10) .

Le compte asp.net se trouve par contre dans mes cached credentials
alors qu'il n'est a priori pas utilisé sur ce poste... (et le mot de
passe est en clair, ce n'est pas un hash)

J'essaie de comprendre la façon dont est renseigné ce cache LSA pour
pouvoir sécuriser cette faille (notamment pour les applications tierces
comme expliquées plus haut)

Merci Emmanuel :)

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security

Emmanuel Dreux [MS]
Le #727299
Comment extrais-tu ces informations?

Les cached credentials sont stockés dans HKLMsecuritycache et accessibles
uniquement au compte système.
Il sont stockés encryptés dans les clés NL$ de 0 à 10.

Pour y accéder en clair, il faut injecter du code dans LSASS et appeler la
fonction LSACryptUnprotectData pour récupérer en clair la valeur du hash.

Une fois fait, celà ne permet que de se loguer localement sur la machine.

Accessibles uniquement au compte system signifie qu'il faut être
administrateur pour y accéder.
Il n'y a donc pas de faille ( hors vol et boot sur sytème alternatif).

--
Cordialement,

Emmanuel Dreux.

"bigstyle [MVP]" news:
Bonjour,

exactement.

Il y a plusieurs "choses" stockées dans le cache LSA:

Les cached credentials ( 10 par défaut): les hashs des 10 derniers
interactifs logons sont stockés pour permettre d'ouvrir une session
localement en absence de DC (ex à la maison).
Ce sont des hashs qui sont stockés pas des mots de passe, et
effectivement avec un peu de patience (beaucoup !!!) ça pourrait être
crackable.

Ensuite les hash des comptes utilisés par les services qui tournent sous
des comptes utilisateurs de domaine ou locaux sont également stockés.

Des applications peuvent également y stocker leurs secrets.

Pour accéder à cette partie, il faut être déjà administrateur, donc...

Le risque reste donc une attaque offline lors d'un vol de portable.

--
Cordialement,

Emmanuel Dreux.



J'avoue ne pas bien comprendre le processus de mise en cache LSA pour les
comptes de domaine dans la mesure où je viens de faire le test sur deux
postes différents.(2000 et XP)
Je me suis loggué avec un compte de domaine puis j'ai fermé la session. Je
me suis alors logué avec un compte admin mais je n'ai pas vu de hash pour
le mot de passe de mes comptes windows.(les cached credentials sont à 10)
.

Le compte asp.net se trouve par contre dans mes cached credentials alors
qu'il n'est a priori pas utilisé sur ce poste... (et le mot de passe est
en clair, ce n'est pas un hash)

J'essaie de comprendre la façon dont est renseigné ce cache LSA pour
pouvoir sécuriser cette faille (notamment pour les applications tierces
comme expliquées plus haut)

Merci Emmanuel :)

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security





bigstyle [MVP]
Le #727295
Comment extrais-tu ces informations?


Je t'ai envoyé un mail à ce sujet (si tu peux me confirmer la bonne
réception de celui-ci)

Les cached credentials sont stockés dans HKLMsecuritycache et accessibles
uniquement au compte système.
Il sont stockés encryptés dans les clés NL$ de 0 à 10.


Peut être que mon incompréhension se situe ici car les informations que
je remonte se trouve dans HKEY_LOCAL_MACHINESECURITYPolicySecrets.

Pour y accéder en clair, il faut injecter du code dans LSASS et appeler la
fonction LSACryptUnprotectData pour récupérer en clair la valeur du hash.

Une fois fait, celà ne permet que de se loguer localement sur la machine.


Pourquoi ? Si le hash du mot de passe est trouvé, le mot de passe du
domaine est alors potentiellement "craquable", non?

Accessibles uniquement au compte system signifie qu'il faut être
administrateur pour y accéder.


Etrange sur Internet j'ai lu à plusieurs reprises que le droit
SeDebugPrivilege suffisait mais je te fais confiance.

(exemple issu de leastprivilege.com :
"So why do i want to get rid of SeDebugPrivilege?
SeDebug is a very powerful privilege, it allows you to read the memory
of other processes (including the Local Security Authority) and let's
you even inject code in those processes.
A famous tool only needs this privilege to dump out all LSA Secrets."

Il n'y a donc pas de faille ( hors vol et boot sur sytème alternatif).


Il subsite une faille majeure au niveau de certaines applications de
contrôle à distance qui stocke leurs mots de passe à cet endroit. (dans
la pratique ce sont les mots de passe des serveurs administrés à
distance)

--
Cordialement,

Emmanuel Dreux.



Merci !

--

bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security

Publicité
Poster une réponse
Anonyme