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,
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,
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,
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]" wrote in message
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,
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]" <bigstyle75@nospam.free.fr> wrote in message
news:mn.92e77d7402335479.70874@nospam.free.fr...
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,
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]" wrote in message
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
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).
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).
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).
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]
wrote: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.
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]
<bigstyle75@nospam.free.fr> wrote:
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.
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]
wrote: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.
la lecture du mot de passe LSA n'utilise pas une technique de
"crackage", la découverte de ces derniers est instantanée.
la lecture du mot de passe LSA n'utilise pas une technique de
"crackage", la découverte de ces derniers est instantanée.
la lecture du mot de passe LSA n'utilise pas une technique de
"crackage", la découverte de ces derniers est instantanée.
On Wed, 18 Apr 2007 17:22:41 +0200, bigstyle [MVP]
wrote: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 :
<http://www.securiteam.com/tools/5JP0I2KFPA.html>
Sinon, si y a un endroit où tous les pass sont en clair, je veux
immédiatement savoir où. :-)
On Wed, 18 Apr 2007 17:22:41 +0200, bigstyle [MVP]
<bigstyle75@nospam.free.fr> wrote:
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 :
<http://www.securiteam.com/tools/5JP0I2KFPA.html>
Sinon, si y a un endroit où tous les pass sont en clair, je veux
immédiatement savoir où. :-)
On Wed, 18 Apr 2007 17:22:41 +0200, bigstyle [MVP]
wrote: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 :
<http://www.securiteam.com/tools/5JP0I2KFPA.html>
Sinon, si y a un endroit où tous les pass sont en clair, je veux
immédiatement savoir où. :-)
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]
wrote: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
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]
<bigstyle75@nospam.free.fr> wrote:
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
On Wed, 18 Apr 2007 16:15:11 +0200, bigstyle [MVP]
wrote: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
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.
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.
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.
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
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
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
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.
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.
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.