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
On Thu, 19 Apr 2007 13:30:59 +0200, bigstyle [MVP] wrote:
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)
Si vous utilisiez Cain, vous comprendriez sûrement mieux. -- Nina
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)
Si vous utilisiez Cain, vous comprendriez sûrement mieux.
--
Nina
On Thu, 19 Apr 2007 13:30:59 +0200, bigstyle [MVP] wrote:
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)
Si vous utilisiez Cain, vous comprendriez sûrement mieux. -- Nina
Nina Popravka
On Thu, 19 Apr 2007 17:22:14 +0200, bigstyle [MVP] wrote:
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)
C'est IMHO un faux problème. Quand on a de *vrais* impératifs de sécurité, on ne laisse pas se balader dans la nature un portable avec des mots de passe d'administration des serveurs dessus. A moins éventuellement que ça ne soit une machine qui s'autodétruise en cas de tentative d'intrusion (ça existe en milieu sensible) :-) -- Nina
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)
C'est IMHO un faux problème.
Quand on a de *vrais* impératifs de sécurité, on ne laisse pas se
balader dans la nature un portable avec des mots de passe
d'administration des serveurs dessus. A moins éventuellement que ça ne
soit une machine qui s'autodétruise en cas de tentative d'intrusion
(ça existe en milieu sensible)
:-)
--
Nina
On Thu, 19 Apr 2007 17:22:14 +0200, bigstyle [MVP] wrote:
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)
C'est IMHO un faux problème. Quand on a de *vrais* impératifs de sécurité, on ne laisse pas se balader dans la nature un portable avec des mots de passe d'administration des serveurs dessus. A moins éventuellement que ça ne soit une machine qui s'autodétruise en cas de tentative d'intrusion (ça existe en milieu sensible) :-) -- Nina
Emmanuel Dreux [MS]
Salut,
oui j'ai reçu ton mail et t'ai répondu en privé. Il y a bien 2 problématiques différentes, les cached credentials stockés sous la clé cache, et les secrets ( mot de passe pour les comptes de services, mot de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté", d'une manière plus forte que le stockage dans la SAM. ... donc bon courage. Le temps que ce soit décrypté, les mots de passe associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris: "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."
-- > Vire ces applications et base toi sur l'authentification Windows. Le mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
-- Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" wrote in message news:
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
Salut,
oui j'ai reçu ton mail et t'ai répondu en privé.
Il y a bien 2 problématiques différentes, les cached credentials stockés
sous la clé cache, et les secrets ( mot de passe pour les comptes de
services, mot de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège
SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté",
d'une manière plus forte que le stockage dans la SAM.
... donc bon courage. Le temps que ce soit décrypté, les mots de passe
associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris:
"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."
-- > Vire ces applications et base toi sur l'authentification Windows. Le
mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
--
Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" <newsgroup@NOSPAM.dlaballe.cjb.net> wrote in message
news:mn.9c127d74c4f6396f.70874@NOSPAM.dlaballe.cjb.net...
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
oui j'ai reçu ton mail et t'ai répondu en privé. Il y a bien 2 problématiques différentes, les cached credentials stockés sous la clé cache, et les secrets ( mot de passe pour les comptes de services, mot de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté", d'une manière plus forte que le stockage dans la SAM. ... donc bon courage. Le temps que ce soit décrypté, les mots de passe associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris: "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."
-- > Vire ces applications et base toi sur l'authentification Windows. Le mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
-- Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" wrote in message news:
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
bigstyle [MVP]
On Thu, 19 Apr 2007 13:30:59 +0200, bigstyle [MVP] wrote:
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)
Si vous utilisiez Cain, vous comprendriez sûrement mieux.
Je n'ai aucune trace de mes comptes de domaine dans Cain non plus ;-) (sous LSA secrets du moins, mais je ne regarde pas au bon endroit ?)
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
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)
Si vous utilisiez Cain, vous comprendriez sûrement mieux.
Je n'ai aucune trace de mes comptes de domaine dans Cain non plus ;-)
(sous LSA secrets du moins, mais je ne regarde pas au bon endroit ?)
--
bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security
On Thu, 19 Apr 2007 13:30:59 +0200, bigstyle [MVP] wrote:
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)
Si vous utilisiez Cain, vous comprendriez sûrement mieux.
Je n'ai aucune trace de mes comptes de domaine dans Cain non plus ;-) (sous LSA secrets du moins, mais je ne regarde pas au bon endroit ?)
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
bigstyle [MVP]
Salut,
Salut,
oui j'ai reçu ton mail et t'ai répondu en privé.
Merci beaucoup :D
Il y a bien 2 problématiques différentes, les cached credentials stockés sous la clé cache, et les secrets ( mot de passe pour les comptes de services, mot de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté", d'une manière plus forte que le stockage dans la SAM. ... donc bon courage. Le temps que ce soit décrypté, les mots de passe associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris: "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."
-- > Vire ces applications et base toi sur l'authentification Windows. Le mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
C'est justement de l'authentification Windows utilisée lors de
l'authentification qui est stockée dans le cache LSA.
En gros, je me connecte via pcanywhere à un serveur (avec la base de compte AD comme référence d'authentification) et hop le compte, mot de passe et domaine sont enregistrés dans mon cache LSA.
-- Cordialement,
Merci pour tout :D
Emmanuel Dreux.
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
Salut,
Salut,
oui j'ai reçu ton mail et t'ai répondu en privé.
Merci beaucoup :D
Il y a bien 2 problématiques différentes, les cached credentials stockés sous
la clé cache, et les secrets ( mot de passe pour les comptes de services, mot
de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège
SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté",
d'une manière plus forte que le stockage dans la SAM.
... donc bon courage. Le temps que ce soit décrypté, les mots de passe
associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris:
"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."
-- > Vire ces applications et base toi sur l'authentification Windows. Le
mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
C'est justement de l'authentification Windows utilisée lors de
l'authentification qui est stockée dans le cache LSA.
En gros, je me connecte via pcanywhere à un serveur (avec la base de
compte AD comme référence d'authentification) et hop le compte, mot de
passe et domaine sont enregistrés dans mon cache LSA.
--
Cordialement,
Merci pour tout :D
Emmanuel Dreux.
--
bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security
Il y a bien 2 problématiques différentes, les cached credentials stockés sous la clé cache, et les secrets ( mot de passe pour les comptes de services, mot de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté", d'une manière plus forte que le stockage dans la SAM. ... donc bon courage. Le temps que ce soit décrypté, les mots de passe associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris: "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."
-- > Vire ces applications et base toi sur l'authentification Windows. Le mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
C'est justement de l'authentification Windows utilisée lors de
l'authentification qui est stockée dans le cache LSA.
En gros, je me connecte via pcanywhere à un serveur (avec la base de compte AD comme référence d'authentification) et hop le compte, mot de passe et domaine sont enregistrés dans mon cache LSA.
-- Cordialement,
Merci pour tout :D
Emmanuel Dreux.
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
Emmanuel Dreux [MS]
tu veux dire que tu te connectes avec un compte du domaine et que ce mot de passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui est allé stocker ces info à cet endroit. C'est grave.
-- Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" wrote in message news:
Salut,
Salut,
oui j'ai reçu ton mail et t'ai répondu en privé.
Merci beaucoup :D
Il y a bien 2 problématiques différentes, les cached credentials stockés sous la clé cache, et les secrets ( mot de passe pour les comptes de services, mot de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté", d'une manière plus forte que le stockage dans la SAM. ... donc bon courage. Le temps que ce soit décrypté, les mots de passe associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris: "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."
-- > Vire ces applications et base toi sur l'authentification Windows. Le mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
C'est justement de l'authentification Windows utilisée lors de
l'authentification qui est stockée dans le cache LSA.
En gros, je me connecte via pcanywhere à un serveur (avec la base de compte AD comme référence d'authentification) et hop le compte, mot de passe et domaine sont enregistrés dans mon cache LSA.
-- Cordialement,
Merci pour tout :D
Emmanuel Dreux.
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
tu veux dire que tu te connectes avec un compte du domaine et que ce mot de
passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui est
allé stocker ces info à cet endroit.
C'est grave.
--
Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" <newsgroup@NOSPAM.dlaballe.cjb.net> wrote in message
news:mn.a2a27d74fbed53dc.70874@NOSPAM.dlaballe.cjb.net...
Salut,
Salut,
oui j'ai reçu ton mail et t'ai répondu en privé.
Merci beaucoup :D
Il y a bien 2 problématiques différentes, les cached credentials stockés
sous la clé cache, et les secrets ( mot de passe pour les comptes de
services, mot de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège
SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté",
d'une manière plus forte que le stockage dans la SAM.
... donc bon courage. Le temps que ce soit décrypté, les mots de passe
associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris:
"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."
-- > Vire ces applications et base toi sur l'authentification Windows.
Le mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
C'est justement de l'authentification Windows utilisée lors de
l'authentification qui est stockée dans le cache LSA.
En gros, je me connecte via pcanywhere à un serveur (avec la base de
compte AD comme référence d'authentification) et hop le compte, mot de
passe et domaine sont enregistrés dans mon cache LSA.
--
Cordialement,
Merci pour tout :D
Emmanuel Dreux.
--
bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security
tu veux dire que tu te connectes avec un compte du domaine et que ce mot de passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui est allé stocker ces info à cet endroit. C'est grave.
-- Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" wrote in message news:
Salut,
Salut,
oui j'ai reçu ton mail et t'ai répondu en privé.
Merci beaucoup :D
Il y a bien 2 problématiques différentes, les cached credentials stockés sous la clé cache, et les secrets ( mot de passe pour les comptes de services, mot de passe du compte machine etc) stoké sous la clé secrets.
L'accès est cependant réservé aux administrateurs car le privilège SeDebugPrivilege n'est donné qu'aux administrateurs par défaut.
Au sujet des cached credentials, le hash est stocké encrypté et "salté", d'une manière plus forte que le stockage dans la SAM. ... donc bon courage. Le temps que ce soit décrypté, les mots de passe associés auront déjà été changés X fois.
Au sujet des "secrets", tu écris: "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."
-- > Vire ces applications et base toi sur l'authentification Windows. Le mot de passe est stocké dans ta mémoire, pas sur le disque dur. :-)
C'est justement de l'authentification Windows utilisée lors de
l'authentification qui est stockée dans le cache LSA.
En gros, je me connecte via pcanywhere à un serveur (avec la base de compte AD comme référence d'authentification) et hop le compte, mot de passe et domaine sont enregistrés dans mon cache LSA.
-- Cordialement,
Merci pour tout :D
Emmanuel Dreux.
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
bigstyle [MVP]
tu veux dire que tu te connectes avec un compte du domaine et que ce mot de passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui est allé stocker ces info à cet endroit. C'est grave.
-- Cordialement,
Emmanuel Dreux.
Oui c'est exactement le problème que j'ai rencontré !
Je n'ai pas encore poussé davantage mes recherches (à savoir si le mot de passe avait été enregistré sous PC anywhere à un instant T) mais j'ai fait la démo sur le poste d'un admin et j'ai pu récupérer tous ses mots de passe (admin du domaine, exchange, domaine de dev etc...).
Et le souci ne vient pas que de pc anywhere mais aussi de dameware remote control !
Je pousserai davantage mes tests d'ici quelques jours et je vous tiendrai au courant quoiqu'il arrive :D
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
tu veux dire que tu te connectes avec un compte du domaine et que ce mot de
passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui est
allé stocker ces info à cet endroit.
C'est grave.
--
Cordialement,
Emmanuel Dreux.
Oui c'est exactement le problème que j'ai rencontré !
Je n'ai pas encore poussé davantage mes recherches (à savoir si le mot
de passe avait été enregistré sous PC anywhere à un instant T) mais
j'ai fait la démo sur le poste d'un admin et j'ai pu récupérer tous ses
mots de passe (admin du domaine, exchange, domaine de dev etc...).
Et le souci ne vient pas que de pc anywhere mais aussi de dameware
remote control !
Je pousserai davantage mes tests d'ici quelques jours et je vous
tiendrai au courant quoiqu'il arrive :D
--
bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security
tu veux dire que tu te connectes avec un compte du domaine et que ce mot de passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui est allé stocker ces info à cet endroit. C'est grave.
-- Cordialement,
Emmanuel Dreux.
Oui c'est exactement le problème que j'ai rencontré !
Je n'ai pas encore poussé davantage mes recherches (à savoir si le mot de passe avait été enregistré sous PC anywhere à un instant T) mais j'ai fait la démo sur le poste d'un admin et j'ai pu récupérer tous ses mots de passe (admin du domaine, exchange, domaine de dev etc...).
Et le souci ne vient pas que de pc anywhere mais aussi de dameware remote control !
Je pousserai davantage mes tests d'ici quelques jours et je vous tiendrai au courant quoiqu'il arrive :D
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
Nina Popravka
On Fri, 20 Apr 2007 11:14:23 +0200, bigstyle [MVP] wrote:
En gros, je me connecte via pcanywhere à un serveur
Chuis pas sûre que ça soit une excellente idée, ça ;-> SSH et RDC, c'est très bien. Ou même RDC tout seul. -- Nina
On Fri, 20 Apr 2007 11:14:23 +0200, bigstyle [MVP] wrote:
En gros, je me connecte via pcanywhere à un serveur
Chuis pas sûre que ça soit une excellente idée, ça ;-> SSH et RDC, c'est très bien. Ou même RDC tout seul.
Je suis tout à fait d'accord avec toi ! :)
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
Emmanuel Dreux [MS]
ça semble se confirmer: http://www.nirsoft.net/utils/pcanypass.html
ça doit les extraire du même endroit.
Outils à proscrire donc.
-- Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" wrote in message news:
tu veux dire que tu te connectes avec un compte du domaine et que ce mot de passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui est allé stocker ces info à cet endroit. C'est grave.
-- Cordialement,
Emmanuel Dreux.
Oui c'est exactement le problème que j'ai rencontré !
Je n'ai pas encore poussé davantage mes recherches (à savoir si le mot de passe avait été enregistré sous PC anywhere à un instant T) mais j'ai fait la démo sur le poste d'un admin et j'ai pu récupérer tous ses mots de passe (admin du domaine, exchange, domaine de dev etc...).
Et le souci ne vient pas que de pc anywhere mais aussi de dameware remote control !
Je pousserai davantage mes tests d'ici quelques jours et je vous tiendrai au courant quoiqu'il arrive :D
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
ça semble se confirmer:
http://www.nirsoft.net/utils/pcanypass.html
ça doit les extraire du même endroit.
Outils à proscrire donc.
--
Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" <newsgroup@NOSPAM.dlaballe.cjb.net> wrote in message
news:mn.a2c77d7478dc4054.70874@NOSPAM.dlaballe.cjb.net...
tu veux dire que tu te connectes avec un compte du domaine et que ce mot
de passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui
est allé stocker ces info à cet endroit.
C'est grave.
--
Cordialement,
Emmanuel Dreux.
Oui c'est exactement le problème que j'ai rencontré !
Je n'ai pas encore poussé davantage mes recherches (à savoir si le mot de
passe avait été enregistré sous PC anywhere à un instant T) mais j'ai fait
la démo sur le poste d'un admin et j'ai pu récupérer tous ses mots de
passe (admin du domaine, exchange, domaine de dev etc...).
Et le souci ne vient pas que de pc anywhere mais aussi de dameware remote
control !
Je pousserai davantage mes tests d'ici quelques jours et je vous tiendrai
au courant quoiqu'il arrive :D
--
bigstyle
MVP Windows Server - Directory Services
MCSE 2000/2003 Security
ça semble se confirmer: http://www.nirsoft.net/utils/pcanypass.html
ça doit les extraire du même endroit.
Outils à proscrire donc.
-- Cordialement,
Emmanuel Dreux.
"bigstyle [MVP]" wrote in message news:
tu veux dire que tu te connectes avec un compte du domaine et que ce mot de passe se retrouve dans le lsa secret?
Si la réponse est oui, vire de toute urgence pcanywhere, c'est lui qui est allé stocker ces info à cet endroit. C'est grave.
-- Cordialement,
Emmanuel Dreux.
Oui c'est exactement le problème que j'ai rencontré !
Je n'ai pas encore poussé davantage mes recherches (à savoir si le mot de passe avait été enregistré sous PC anywhere à un instant T) mais j'ai fait la démo sur le poste d'un admin et j'ai pu récupérer tous ses mots de passe (admin du domaine, exchange, domaine de dev etc...).
Et le souci ne vient pas que de pc anywhere mais aussi de dameware remote control !
Je pousserai davantage mes tests d'ici quelques jours et je vous tiendrai au courant quoiqu'il arrive :D
--
bigstyle MVP Windows Server - Directory Services MCSE 2000/2003 Security
