Cain shows DefaultPassword in plain text - LASS writes it

[c***@gmx.at]

I run Windows XP SP1 on a single user notebook (no domain account).

Recently I did a few security check and was shocked about Cain
(www.oxid.it/cain.html) showing me the plain text of my top secret
password which I only use on that notebook.

After a couple of hours of google research and sysinternals-diagnostics
I found that LSASS writes the following registry keys whenever I change
my password:

HKLM\Security\Policy\Secrets\DefaultPassword\CurrVal
HKLM\Security\Policy\Secrets\DefaultPassword\CupdTime
HKLM\Security\Policy\Secrets\DefaultPassword\OldVal
HKLM\Security\Policy\Secrets\DefaultPassword\OupdTime

I swear that autologon, which could be a reason for storing the
password, was never enabled.

Removing DefaultPassword and serveral other registry keys under
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon such as

AltDefaultUserName
DefaultUserName

and setting restrictive security option, e.g., not showing the name of
the last user who logged in did not help. All these keys were created
again, together with DefaultPassword.

Now I'm stuck. I do not want to have my password in decryptable form
anywhere in the system, neither in the registry nor in any kind of
"protected" storage.

As soon as I type in my password the system should hash it an forget
it.

Any pointers on how to get rid off
HKLM\Security\Policy\Secrets\DefaultPassword (beware this is not
DefaultPassword under Winlogon)?

Thank you
Clavigo

[Steven L Umbach]

I assume you mean you logon to Windows XP password?? First off never use
that password for anything else such as Outlook Express email password that
is saved or saved passwords in Internet Explorer as those passwords are not
stored securely. A strong password would be a password of at least eight
characters that contains all the following - number, upper case, lower case,
and special/punctuation character such as 9!mty1OT as an example OR use a
long pass phrase [including spaces] such as I forget my stupid password!
Long pass phrases are more secure and easier to remember than 9!mty1OT .
Also using a long pass will prevent the password from being stored as a lm
hash that will make it much much easier to crack than a NT hash. You can
also disable storage of lm hashes for passwords as shown in the link below
using Local Security Policy for XP Pro. If you do such the change will not
take effect until the next password change.

Having said all that passwords themselves do not provide much protection to
your data if an attacker/malicious users can gain physical access to your
computer to do whatever they want. The only way to truly protect your data
is with encryption and managing of your encryption keys so that the attacker
can not gain access to them. XP Pro has EFS encryption but it should not be
used unless the user is fully aware of all the risks including the user not
being able to access his encrypted data because of loss of private key to
key corruption or operating system install. Exporting the EFS private key to
safe keeping is easily done. --- Steve

http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656&

Post by c***@gmx.at
I run Windows XP SP1 on a single user notebook (no domain account).
Recently I did a few security check and was shocked about Cain
(www.oxid.it/cain.html) showing me the plain text of my top secret
password which I only use on that notebook.
After a couple of hours of google research and sysinternals-diagnostics
I found that LSASS writes the following registry keys whenever I change
HKLM\Security\Policy\Secrets\DefaultPassword\CurrVal
HKLM\Security\Policy\Secrets\DefaultPassword\CupdTime
HKLM\Security\Policy\Secrets\DefaultPassword\OldVal
HKLM\Security\Policy\Secrets\DefaultPassword\OupdTime
I swear that autologon, which could be a reason for storing the
password, was never enabled.
Removing DefaultPassword and serveral other registry keys under
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon such as
AltDefaultUserName
DefaultUserName
and setting restrictive security option, e.g., not showing the name of
the last user who logged in did not help. All these keys were created
again, together with DefaultPassword.
Now I'm stuck. I do not want to have my password in decryptable form
anywhere in the system, neither in the registry nor in any kind of
"protected" storage.
As soon as I type in my password the system should hash it an forget
it.
Any pointers on how to get rid off
HKLM\Security\Policy\Secrets\DefaultPassword (beware this is not
DefaultPassword under Winlogon)?
Thank you
Clavigo

[c***@gmx.at]

Thank you Steve. As my dog is an Irish one, and I always have been
using dog names as passwords, my secret word is very long and reads
"ceithirFiCheadCùsADhàDheug" or similar. Moreover I change it every
time my dog learns a new command which happens every three weeks or so.

But nevertheless: XP should not care about the name of maydog it only
should care about the hash of it's name.

Maybe this is difficult for XP because as far as I know it uses
Kerberos for certain security aspects which is a dog too.

But I insists. No dog names in the Windows registry only undecryptable
hashes (which my dog likes a lot too).

[Steven L Umbach]

I had an older version of Cain installed on my computer and it would not
dump LSA secrets but would crash my computer. I just installed the latest
version from their website and while it will dump LSA secrets now it did not
show my user account or password. I am using XP Pro with SP2 installed and
administrators have debug programs user rights and Control -alt-delete is
required to logon. Of course I was logged on as an admin to run Cain. XP Pro
will only use kerberos authentication when in an Active Directory domain.
User names are stored in clear text on the computer, it is the passwords
that hashed but I suspect that is what you meant. --- Steve


<***@gmx.at> wrote in message news:***@g14g2000cwa.googlegroups.com...
Thank you Steve. As my dog is an Irish one, and I always have been
using dog names as passwords, my secret word is very long and reads
"ceithirFiCheadCùsADhàDheug" or similar. Moreover I change it every
time my dog learns a new command which happens every three weeks or so.

But nevertheless: XP should not care about the name of maydog it only
should care about the hash of it's name.

Maybe this is difficult for XP because as far as I know it uses
Kerberos for certain security aspects which is a dog too.

But I insists. No dog names in the Windows registry only undecryptable
hashes (which my dog likes a lot too).

[c***@gmx.at]

Steve, thank you for your assistance.

You pinpoint what I'm asking for. Cain does not show your password on
your computer because it is not stored as LSA secret. That's the way it
meant to be.

But on my computer LSASS does store my password as LSA secret, every
time I change the password and unfortunately I do not know how to
change this behavior.

I will install SP2 and see if things get better.

Clavigo

BTW: mentioning Kerberos was a joke. I know that is not used for local
authentication but - Kerberos is such a well known dog, and hash is
such a delicious dog food, and my dog's name gives such a good
password, and that password should give such a tasty hash that XP
should store this hash, if it wants to be a good dog handler ;-)

[Joe Richards [MVP]]

The hash is stored in the registry for every local userid. This hash can be
cracked via bruteforce or table lookup.

Which specific processd did you use to have it find your password?



--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Post by c***@gmx.at
I run Windows XP SP1 on a single user notebook (no domain account).
Recently I did a few security check and was shocked about Cain
(www.oxid.it/cain.html) showing me the plain text of my top secret
password which I only use on that notebook.
After a couple of hours of google research and sysinternals-diagnostics
I found that LSASS writes the following registry keys whenever I change
HKLM\Security\Policy\Secrets\DefaultPassword\CurrVal
HKLM\Security\Policy\Secrets\DefaultPassword\CupdTime
HKLM\Security\Policy\Secrets\DefaultPassword\OldVal
HKLM\Security\Policy\Secrets\DefaultPassword\OupdTime
I swear that autologon, which could be a reason for storing the
password, was never enabled.
Removing DefaultPassword and serveral other registry keys under
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon such as
AltDefaultUserName
DefaultUserName
and setting restrictive security option, e.g., not showing the name of
the last user who logged in did not help. All these keys were created
again, together with DefaultPassword.
Now I'm stuck. I do not want to have my password in decryptable form
anywhere in the system, neither in the registry nor in any kind of
"protected" storage.
As soon as I type in my password the system should hash it an forget
it.
Any pointers on how to get rid off
HKLM\Security\Policy\Secrets\DefaultPassword (beware this is not
DefaultPassword under Winlogon)?
Thank you
Clavigo

[c***@gmx.at]

I used Cain, which did not crack the hash but intercepts lsass.exe
which reveals my password in split second. The whole case is about
LSA secrets. May I cite
http://www.ryanstevens.co.uk/default.aspx?date=2005-01-25

"The LSA Secrets are encrypted on disk and decrypted by the OS when the
machine boots. They are then held in clear text in the LSA process
memory space while the system is running."

My problem is that I don't want to have my login password stored as LSA
Secret named "DefaultPassword", because as Cain demonstrates This is
not done by my Windows 2000 system and should not be done by XP either
this is insecure.

Image the mess if my wife would crack my computer an sees that it is
not her name but that of our dog I use to protect my data ;-)

[c***@gmx.at]

Paragraph before last should read "... because as Cain demonstrates
this is insecure. Moreover such an LSA entry is not made by my Windows
2000 system and should not made by XP either."

[Joe Richards [MVP]]

I used Cain to look at my LSA secrets and I had none of my passwords listed in
there. There must be something specific on your machine that you are doing that
is causing your password to go in there.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Post by c***@gmx.at
I used Cain, which did not crack the hash but intercepts lsass.exe
which reveals my password in split second. The whole case is about
LSA secrets. May I cite
http://www.ryanstevens.co.uk/default.aspx?date=2005-01-25
"The LSA Secrets are encrypted on disk and decrypted by the OS when the
machine boots. They are then held in clear text in the LSA process
memory space while the system is running."
My problem is that I don't want to have my login password stored as LSA
Secret named "DefaultPassword", because as Cain demonstrates This is
not done by my Windows 2000 system and should not be done by XP either
this is insecure.
Image the mess if my wife would crack my computer an sees that it is
not her name but that of our dog I use to protect my data ;-)

[c***@gmx.at]

Post by Joe Richards [MVP]
There must be something specific on your machine that you are doing

that

Post by Joe Richards [MVP]
is causing your password to go in there.

It's definitely not me, doing something special, but maybe some bogus
process could be intersted in having the password stored at this
location.

[Joe Richards [MVP]]

Yeah, I don't think you purposely stuck it there, but I expect there is some
piece of software installed that needs the clear text version of your password
and jammed it into the secrets. This certainly isn't the case for the base OS.
It will require trying to track down what it is that doing this. It could be an
interesting project. I don't believe the secrets are written by the process, it
has been a while since I looked but I think you call a special secrets function
and lsass writes it. This means you can't do a simple registry trace.


joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Post by c***@gmx.at

Post by Joe Richards [MVP]
There must be something specific on your machine that you are doing

that

Post by Joe Richards [MVP]
is causing your password to go in there.

It's definitely not me, doing something special, but maybe some bogus
process could be intersted in having the password stored at this
location.

[c***@gmx.at]

XPPro SP2 and all patches are installed now; Microsoft Baseline
Security Analyzer shows green checkmarks for all security related
items. However lsass still write my password into the LSA secrets.

Can anybody give me some pointers what tools I could use to track down
what software forces lsass to behave that way?

Clavigo

Post by Joe Richards [MVP]
Yeah, I don't think you purposely stuck it there, but I expect there is some
piece of software installed that needs the clear text version of your password
and jammed it into the secrets. This certainly isn't the case for the base OS.
It will require trying to track down what it is that doing this. It could be an
interesting project. I don't believe the secrets are written by the process, it
has been a while since I looked but I think you call a special secrets function
and lsass writes it. This means you can't do a simple registry trace.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Post by c***@gmx.at

Post by Joe Richards [MVP]
There must be something specific on your machine that you are doing

that

Post by Joe Richards [MVP]
is causing your password to go in there.

It's definitely not me, doing something special, but maybe some bogus
process could be intersted in having the password stored at this
location.

[Steven L Umbach]

Bizarre. Try booting into safe mode to see if it happens. If it does not
then some startup application is causing it to happen. Maybe someone could
help more if you could post the entries for your LSA secrets so that it
would show more info. Here is what mine looks like. --- Steve

=================================

=== Cain's LSA Secrets Dumper ===

=================================



0083343a-f925-4ed7-b1d6-d95d17a0b57b-RemoteDesktopHelpAssistantAccount

47 00 69 00 2D 00 36 00 55 00 6C 00 43 00 43 00 G.i.-.6.U.l.C.C.

6B 00 39 00 4D 00 30 00 43 00 6E 00 00 00 k.9.M.0.C.n...



0083343a-f925-4ed7-b1d6-d95d17a0b57b-RemoteDesktopHelpAssistantSID

01 05 00 00 00 00 00 05 15 00 00 00 D9 31 F8 42 .............1.B

13 16 10 09 DB EB 0C 50 E8 03 00 00 .......P....



20ed87e2-3b82-4114-81f9-5e219ed4c481-SALEMHELPACCOUNT

02 00 00 00 ....



91110409600011D38

00 00 06 00 00 00 00 00 ........



c261dd33-c55b-4a37-924b-746bbf3569ad-RemoteDesktopHelpAssistantEncrypt



DefaultPassword



DPAPI_SYSTEM

01 00 00 00 CD 39 31 C3 E6 02 55 5D 86 B8 02 1E .....91...U]....

F9 93 D5 0E F2 76 B6 B0 91 98 33 27 9E F8 BD BE .....v....3'....

62 4A 4A 73 35 57 CD B6 AC D5 2B 87 bJJs5W....+.



G${ED8F4747-E13D-47bc-856B-5CEFE1A81A7F}

82 49 2F 87 C3 47 FB 4F B1 8C 8E 45 7C 45 F1 2C .I/..G.O...E|E.,



L$HYDRAENCKEY_28ada6da-d622-11d1-9cb9-00c04fb16e75

52 53 41 32 48 00 00 00 00 02 00 00 3F 00 00 00 RSA2H.......?...

01 00 01 00 45 6E F1 84 88 51 38 C4 EB 46 3E 3B ....En...Q8..F>;

42 5D 51 5F 08 89 68 E3 D2 A7 D6 F2 5A 53 5E 19 B]Q_..h.....ZS^.

E7 A4 79 32 AB CB CE 85 76 35 A3 77 0D 81 FC 8A ..y2....v5.w....

5A F5 44 83 B1 84 4B 6D 64 B4 3D 22 3C E2 5A FA Z.D...Kmd.="<.Z.

22 7B 85 BC 00 00 00 00 00 00 00 00 B1 94 BF 07 "{..............

87 13 7B B1 6E D8 71 BE D7 8A 81 5A 13 81 6C 87 ..{.n.q....Z..l.

15 49 5C 78 12 F8 F8 26 61 E8 CB ED 00 00 00 00 .I\x...&a.......

D5 E7 0F 8D B2 3E 8C 2C AD 23 45 3B 23 E1 23 5B .....>.,.#E;#.#[

4C D5 23 15 27 9B CD C6 7B 13 C0 03 28 EE F3 CA L.#.'...{...(...

00 00 00 00 31 B9 A9 83 47 E2 C8 1D 04 88 E9 B0 ....1...G.......

6A 4B F7 37 C3 E5 EA A9 40 68 F6 47 BB 88 CA 27 ***@h.G...'

05 6B 4D 2E 00 00 00 00 65 5C 03 0A 10 FC 4C B2 .kM.....e\....L.

D4 76 66 6D A9 61 17 C1 07 53 E4 0B B8 EA 82 96 .vfm.a...S......

7D EE DA E9 45 51 F4 63 00 00 00 00 95 EB 32 06 }...EQ.c......2.

8F 81 02 4D EE 18 C3 77 B5 25 E4 DE EF 6F 1C B2 ...M...w.%...o..

2B 65 FC 4B 35 E2 8A 98 65 48 E7 5A 00 00 00 00 +e.K5...eH.Z....

01 90 9D 4C 6D E8 2E 7F 99 07 C6 11 B9 15 4D 6C ...Lm.........Ml

FF 2B 3E 08 94 98 F5 93 5C 0D E7 DB 16 A1 60 AE .+>.....\.....`.

FA D3 B0 B9 DB FB 32 42 BC 36 5A 54 3E B9 5A 77 ......2B.6ZT>.Zw

EE 6A 24 99 F3 B3 43 45 A8 62 93 7C 88 D5 1B 26 .j$...CE.b.|...&

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00 00 00 00 00 00 00 00 00 00 00 00 ............



L$RTMTIMEBOMB_1320153D-8DA3-4e8e-B27B-0D888223A588

80 CD 11 F5 60 01 C5 01 ....`...



L${6B3E6424-AF3E-4bff-ACB6-DA535F0DDC0A}

2B B0 51 23 15 BB 4F A1 FE 1C C0 F8 8D 2C 5F 79 +.Q#..O......,_y

D4 7D F0 20 BC 29 06 94 48 43 3A 6E 5F B6 57 9B .}. .)..HC:n_.W.

02 B9 93 CC 40 EC F6 F9 52 B1 EF 7C BB C7 90 82 ***@...R..|....

E7 A0 34 59 6F EA 6E 0F ..4Yo.n.



NL$KM

76 5A DA 80 63 43 3E 59 E7 9C 25 05 51 B7 2E F0 vZ..cC>Y..%.Q...

B1 A4 02 70 D5 05 95 4E BF CF 1C B5 84 C3 85 33 ...p...N.......3

9E E2 E1 3B C3 96 2C 3E BD 8C D8 2E 41 84 2F 9D ...;..,>....A./.

FE 9C 9C 8F F7 60 28 8D 87 04 25 B1 B0 72 26 53 .....`(...%..r&S



RasDialParams!S-1-5-21-1123561945-152049171-1343024091-1003#0

32 00 35 00 38 00 37 00 34 00 33 00 30 00 00 00 2.5.8.7.4.3.0...

31 00 36 00 30 00 30 00 00 00 30 00 00 00 00 00 1.6.0.0...0.....

00 00 00 00 00 00 00 00 30 00 00 00 00 00 ........0.....



RasDialParams!S-1-5-21-1123561945-152049171-1343024091-1005#0

32 00 32 00 33 00 36 00 37 00 39 00 38 00 33 00 2.2.3.6.7.9.8.3.

00 00 31 00 36 00 30 00 30 00 00 00 36 00 31 00 ..1.6.0.0...6.1.

00 00 31 00 39 00 32 00 2E 00 31 00 36 00 38 00 ..1.9.2...1.6.8.

2E 00 31 00 2E 00 32 00 35 00 31 00 00 00 00 00 ..1...2.5.1.....

61 00 64 00 6D 00 69 00 6E 00 69 00 73 00 74 00 a.d.m.i.n.i.s.t.

72 00 61 00 74 00 6F 00 72 00 00 00 00 00 00 00 r.a.t.o.r.......

31 00 00 00 00 00 1.....



RasDialParams!S-1-5-21-4262006437-3606277189-2421192973-1631#0

32 00 31 00 38 00 30 00 35 00 38 00 30 00 35 00 2.1.8.0.5.8.0.5.

00 00 31 00 36 00 30 00 30 00 00 00 30 00 00 00 ..1.6.0.0...0...

00 00 00 00 00 00 00 00 00 00 30 00 00 00 00 00 ..........0.....



RasDialParams!S-1-5-21-839522115-507921405-1202660629-1109#0

32 00 31 00 38 00 30 00 35 00 38 00 30 00 35 00 2.1.8.0.5.8.0.5.

00 00 31 00 36 00 30 00 30 00 00 00 36 00 31 00 ..1.6.0.0...6.1.

00 00 00 00 2A 00 00 00 61 00 64 00 6D 00 69 00 ....*...a.d.m.i.

6E 00 69 00 73 00 74 00 72 00 61 00 74 00 6F 00 n.i.s.t.r.a.t.o.

72 00 00 00 00 00 00 00 31 00 00 00 35 00 31 00 r.......1...5.1.

38 00 30 00 34 00 00 00 31 00 36 00 30 00 30 00 8.0.4...1.6.0.0.

00 00 36 00 31 00 00 00 00 00 2A 00 00 00 61 00 ..6.1.....*...a.

64 00 6D 00 69 00 6E 00 69 00 73 00 74 00 72 00 d.m.i.n.i.s.t.r.

61 00 74 00 6F 00 72 00 00 00 00 00 00 00 31 00 a.t.o.r.......1.

00 00 00 00 ....



SAC

12 00 00 00 02 00 00 00 78 00 00 00 D9 A2 CF CB ........x.......

E2 32 2C 50 07 E3 45 9B 30 67 51 7B D7 6D BB C1 .2,P..E.0gQ{.m..

C4 F6 50 05 A2 FE 76 0F 4D F6 D7 1D 02 62 C5 1A ..P...v.M....b..

1F 8D 58 19 66 E0 8A 2E 2F 05 CC B2 1C CA D6 FB ..X.f.../.......

A6 C4 14 32 41 E4 CD DF 05 07 70 5B C7 B3 E4 DB ...2A.....p[....

A5 56 A8 37 29 5E F8 BE 3B C0 03 3C 9A E6 A9 5E .V.7)^..;..<...^

17 19 E5 47 2F 97 EB E9 E1 FE 0C D9 B2 E4 BA B2 ...G/...........

A6 7D 33 47 1B BF 0C E7 0A 84 09 DC 67 A3 A6 4C .}3G........g..L

30 EB 41 57 50 00 00 00 3B FF 8D 72 0C E7 B7 01 0.AWP...;..r....

B2 8E 8B AF 28 67 22 70 3E D3 F4 9E 3B 9E B5 E6 ....(g"p>...;...

7A 0C 45 F1 DD 72 91 17 4F F9 4D CB F7 04 88 05 z.E..r..O.M.....

30 CC C5 40 D2 52 B1 A7 CA 87 05 F8 F1 91 F9 E6 ***@.R..........

C8 27 06 5E CF 9F 8E 7E 33 6F D2 D0 86 AF 00 80 .'.^...~3o......

68 A8 48 5F 23 21 C3 2F h.H_#!./



SAI

12 00 00 00 02 00 00 00 03 00 00 00 CF 1D CA 1F ................

94 80 2C 67 48 3D B4 46 80 9F 94 9D 11 E5 B3 54 ..,gH=.F.......T

62 82 43 F1 A0 51 92 7D FD 74 DE 1D 9A 98 D2 5F b.C..Q.}.t....._

11 0A F2 45 76 C8 5D 74 E7 A2 13 AF DC 01 A7 55 ...Ev.]t.......U

8C 34 84 B6 44 9F 44 2D 19 F7 61 01 12 10 47 6D .4..D.D-..a...Gm

27 80 08 C8 BA 41 D7 86 AD 71 34 2E FD 90 A4 23 '....A...q4....#

6B FC CF 56 67 C2 91 11 5F E5 57 82 98 05 11 9F k..Vg..._.W.....

54 94 4D 0F CB 7F 10 48 67 1A 89 58 C3 AA FA 52 T.M....Hg..X...R

51 59 67 7F BE D9 59 F9 7C 40 98 33 DC 4A D5 10 QYg...Y.|@.3.J..

BA 1A 9D 2B C0 BE 7E DC B5 77 80 10 BE E3 F9 EB ...+..~..w......

B1 62 2A B8 C9 5E BF F3 54 3C 08 7E F4 1C 71 5D .b*..^..T<.~..q]

A2 3D ED CD 1E 1B 28 59 E5 15 7A 29 E2 75 4D 2F .=....(Y..z).uM/

88 3E AB D2 5D B5 4F 1E CF B2 99 0B 01 00 00 00 .>..].O.........

6F DA BE C5 ED 1D 3E D0 B3 78 6B D0 F1 EA C1 71 o.....>..xk....q

B9 B1 C2 D6 07 58 E1 E3 A9 AA 23 8E 87 61 2F 8F .....X....#..a/.

E7 03 06 24 65 8F 7E 69 06 7F D4 AA AB 12 E3 D7 ...$e.~i........

5A 0C D1 AF 0F A6 F5 AE DB 1A 22 08 66 28 A7 98 Z.........".f(..



_SC_ALG



_SC_Dnscache



_SC_LmHosts



_SC_MSDTC



_SC_RpcLocator



_SC_SSDPSRV



_SC_upnphost



_SC_WebClient

Post by c***@gmx.at
XPPro SP2 and all patches are installed now; Microsoft Baseline
Security Analyzer shows green checkmarks for all security related
items. However lsass still write my password into the LSA secrets.
Can anybody give me some pointers what tools I could use to track down
what software forces lsass to behave that way?
Clavigo

Post by Joe Richards [MVP]
Yeah, I don't think you purposely stuck it there, but I expect there is some
piece of software installed that needs the clear text version of your password
and jammed it into the secrets. This certainly isn't the case for the base OS.
It will require trying to track down what it is that doing this. It could be an
interesting project. I don't believe the secrets are written by the process, it
has been a while since I looked but I think you call a special secrets function
and lsass writes it. This means you can't do a simple registry trace.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Post by c***@gmx.at

Post by Joe Richards [MVP]
There must be something specific on your machine that you are doing

that

Post by Joe Richards [MVP]
is causing your password to go in there.

It's definitely not me, doing something special, but maybe some bogus
process could be intersted in having the password stored at this
location.

[Joe Richards [MVP]]

Build a raw new machine. Check it. Then slowly add you apps until you see it
occur. Alternatively, you can look for some sort of API SPY type app that
watches all API calls and looks for the ones specific to setting the LSA Secret
calls. I don't know of anything like that off hand though.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Post by c***@gmx.at
XPPro SP2 and all patches are installed now; Microsoft Baseline
Security Analyzer shows green checkmarks for all security related
items. However lsass still write my password into the LSA secrets.
Can anybody give me some pointers what tools I could use to track down
what software forces lsass to behave that way?
Clavigo

Post by Joe Richards [MVP]
Yeah, I don't think you purposely stuck it there, but I expect there is some
piece of software installed that needs the clear text version of your password
and jammed it into the secrets. This certainly isn't the case for the base OS.
It will require trying to track down what it is that doing this. It could be an
interesting project. I don't believe the secrets are written by the process, it
has been a while since I looked but I think you call a special secrets function
and lsass writes it. This means you can't do a simple registry trace.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Post by c***@gmx.at

Post by Joe Richards [MVP]
There must be something specific on your machine that you are doing

that

Post by Joe Richards [MVP]
is causing your password to go in there.

It's definitely not me, doing something special, but maybe some bogus
process could be intersted in having the password stored at this
location.

[Karl Levinson, mvp]

Unless I'm mistaken, this is not really a vulnerability. Try to get your
wife's password when logged in as you, or try to get your password when
logged in as your wife. You already know your password, so someone running
with your privileges isn't gaining much with this trick.

Additionally, I'm guessing you are logged in as administrator, so that you
have the SEDebug privilege in order to attach to the LSASS process? Does
this work when you are not logged in as administrator? If not, then one way
to fix this, if you are still convinced it is a vulnerability, would be to
control who is an administrator and who has SEDebug privilege, because these
people have full control of your computer, with or without LSASS.

I've been told that the locally cached credentials are quite secure, much
more secure than the local SAM password hashes. The SAM password hashes are
generally not as strongly encrypted as the cached credentials. Unless I'm
mistaken, I also think that the cached information you are discussing is
encrypted with a secret encryption key that only your account has access to.
Windows should have no need to decrypt the credentials of other users, and I
am sure Microsoft is very aware of this fact.

I also don't believe there's any way to change this, this is just the way
Windows and other operating systems work. Your OS needs to cache your
credentials in some way so that you dont' have to re-enter your password
every time you access a local or network drive, system or resource. If this
was as trivial to discover as you believe, I am confident the world would be
screaming about this.

I believe the book Hacking Exposed - Windows has a section on this, so you
might check that out as well.

If your wife is a power user, or an administrator, or has unrestricted
physical access to your computer or hard drive, then she already has the
ability to gain full access to your computer, whether it was running Windows
or Linux. Without physical security, there is no security.

Post by c***@gmx.at
I run Windows XP SP1 on a single user notebook (no domain account).
Recently I did a few security check and was shocked about Cain
(www.oxid.it/cain.html) showing me the plain text of my top secret
password which I only use on that notebook.
After a couple of hours of google research and sysinternals-diagnostics
I found that LSASS writes the following registry keys whenever I change
HKLM\Security\Policy\Secrets\DefaultPassword\CurrVal
HKLM\Security\Policy\Secrets\DefaultPassword\CupdTime
HKLM\Security\Policy\Secrets\DefaultPassword\OldVal
HKLM\Security\Policy\Secrets\DefaultPassword\OupdTime
I swear that autologon, which could be a reason for storing the
password, was never enabled.
Removing DefaultPassword and serveral other registry keys under
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon such as
AltDefaultUserName
DefaultUserName
and setting restrictive security option, e.g., not showing the name of
the last user who logged in did not help. All these keys were created
again, together with DefaultPassword.
Now I'm stuck. I do not want to have my password in decryptable form
anywhere in the system, neither in the registry nor in any kind of
"protected" storage.
As soon as I type in my password the system should hash it an forget
it.
Any pointers on how to get rid off
HKLM\Security\Policy\Secrets\DefaultPassword (beware this is not
DefaultPassword under Winlogon)?
Thank you
Clavigo

[c***@gmx.at]

Karl, in principal you are right but there are other aspects to
consider. In my opinion this case is not a matter of access security
but of keeping secrets. My password should only be known by me until
the moment I login or change it, then it should be hashed by a
trustworthy system process, compared with a stored hash and forgotten
by the system.

As I mentioned earlier, Windows 2000 does not have this
"DefaultPassword" and other XP systems also do not have it. On all
those systems, Cain has not access to the plain text of the password,
even not with SEDebug privilege, it would have to crack it, which would
last years with my long password.

I will not trust my XP Pro anymore as long as my most secret password
can be retrieved as plain text by a user which has SEDebug privilege
and accesses the registry.

Because I'm sure that Microsoft has also not intended that, I suspect a
malfunction of LSASS or a misconfiguration of my XP.

[c***@gmx.at]

... excuse my terrible typos. It's rather late here in Europe and this
password indiscretion competely discombobulated me.

[c***@gmx.at]

Post by Karl Levinson, mvp
Unless I'm
mistaken, I also think that the cached information you are discussing is
encrypted with a secret encryption key that only your account has access to.
Windows should have no need to decrypt the credentials of other users, and I
am sure Microsoft is very aware of this fact.

LSA Secrets can be retrieved and decrypted by any user with
SeDebugPrivilege right. I checked this (what a funny password my wife
has - I would not speak it out loud and she not either ;-)

[Karl Levinson, mvp]

Post by c***@gmx.at
LSA Secrets can be retrieved and decrypted by any user with
SeDebugPrivilege right. I checked this (what a funny password my wife
has - I would not speak it out loud and she not either ;-)

Fair enough, I see your points. Regarding your problem on this one
computer, could it be that TweakUI is installed, and that it might have some
problem that is causing it to create that registry value? That registry
value you speak of appears to be associated with TweakUI.

However, I still feel that, as the Cain documentation states, "this requires
an account with the SeDebugPrivilege user right. By default only
Administrators have this right." If your wife is already an administrator
on your computer, she already has the ability to grab the SAM and crack your
password hash that way [although you state it is long enough for cracking to
not be trivial], or back up the SAM, change your password, log in as you,
then restore the SAM to put the password back. As admin, she already has
access to all of your files as well. You can prevent this by either making
her a non-admin, or by revoking the SEDebug privilege via group policy so
that settings reapply every 30 minutes or so, although a knowledgeable admin
would know how to restore this privilege. I'm not crazy about this design,
but Microsoft does admin that SEDebug is a very powerful privilege that
permits users to become administrator. Microsoft KB makes this argument:
"This is by design. Members of the local Administrators groups are trusted
users that have the ability to access any information that can also be
accessed by the operating system itself."

http://support.microsoft.com/default.aspx?scid=KB;en-us;q184017

[Roger Abell]

While you make a good point here Karl, if Joe is not correct that this is
due
to some installed application that is intercepting and storing the
passwords,
then what we have here is a case of all Windows documentation going back
many versions not speaking straight when they state that the password is not
stored but only an irreversible hash.
--
Roger

Post by Karl Levinson, mvp

Post by c***@gmx.at
LSA Secrets can be retrieved and decrypted by any user with
SeDebugPrivilege right. I checked this (what a funny password my wife
has - I would not speak it out loud and she not either ;-)

Fair enough, I see your points. Regarding your problem on this one
computer, could it be that TweakUI is installed, and that it might have some
problem that is causing it to create that registry value? That registry
value you speak of appears to be associated with TweakUI.
However, I still feel that, as the Cain documentation states, "this requires
an account with the SeDebugPrivilege user right. By default only
Administrators have this right." If your wife is already an administrator
on your computer, she already has the ability to grab the SAM and crack your
password hash that way [although you state it is long enough for cracking to
not be trivial], or back up the SAM, change your password, log in as you,
then restore the SAM to put the password back. As admin, she already has
access to all of your files as well. You can prevent this by either making
her a non-admin, or by revoking the SEDebug privilege via group policy so
that settings reapply every 30 minutes or so, although a knowledgeable admin
would know how to restore this privilege. I'm not crazy about this design,
but Microsoft does admin that SEDebug is a very powerful privilege that
"This is by design. Members of the local Administrators groups are trusted
users that have the ability to access any information that can also be
accessed by the operating system itself."
http://support.microsoft.com/default.aspx?scid=KB;en-us;q184017

[Karl Levinson, mvp]

I agree, sort of. However, even if they "only" stored the hash, that's just
as bad as storing the password, since you can re-send the hash to
authenticate like a replay attack, at least with Netbios over TCP/IP if not
also kerberos as well.

Jesper Johannson and others at Microsoft explained cached credentials and/or
LSA secrets as being a hash of a hash. That description doesn't really make
much sense to me, because I would think a hash of a hash would be pretty
much useless for any sort of authentication, except perhaps if you force the
user to re-authenticate locally and wish the local workstation to confirm
the authentication locally only.

http://download.microsoft.com/download/D/1/E/D1E7F6E0-C336-4121-8A6A-2A3CF5C8B921/Windows_Passwords_JesperJohansson.pdf

I still stand by my feeling that while this does sound like a poor design,
it's also largely your fault if you grant someone untrusted the SEDebug
permission and/or local admin privileges. Both of these are very dangerous
[and in the case of SEDebug, largely unnecessary] privileges. It's a
sub-optimal design that may have been mis-documented, but with a trivial and
fairly effective workaround.

Post by Roger Abell
While you make a good point here Karl, if Joe is not correct that this is
due
to some installed application that is intercepting and storing the
passwords,
then what we have here is a case of all Windows documentation going back
many versions not speaking straight when they state that the password is not
stored but only an irreversible hash.
--
Roger

Post by Karl Levinson, mvp

Post by c***@gmx.at
LSA Secrets can be retrieved and decrypted by any user with
SeDebugPrivilege right. I checked this (what a funny password my wife
has - I would not speak it out loud and she not either ;-)

Fair enough, I see your points. Regarding your problem on this one
computer, could it be that TweakUI is installed, and that it might have

some

Post by Karl Levinson, mvp
problem that is causing it to create that registry value? That registry
value you speak of appears to be associated with TweakUI.
However, I still feel that, as the Cain documentation states, "this

requires

Post by Karl Levinson, mvp
an account with the SeDebugPrivilege user right. By default only
Administrators have this right." If your wife is already an

administrator

Post by Roger Abell

Post by Karl Levinson, mvp
on your computer, she already has the ability to grab the SAM and crack

your

Post by Karl Levinson, mvp
password hash that way [although you state it is long enough for

cracking

Post by Roger Abell
to

Post by Karl Levinson, mvp
not be trivial], or back up the SAM, change your password, log in as you,
then restore the SAM to put the password back. As admin, she already has
access to all of your files as well. You can prevent this by either

making

Post by Karl Levinson, mvp
her a non-admin, or by revoking the SEDebug privilege via group policy so
that settings reapply every 30 minutes or so, although a knowledgeable

admin

Post by Karl Levinson, mvp
would know how to restore this privilege. I'm not crazy about this

design,

Post by Karl Levinson, mvp
but Microsoft does admin that SEDebug is a very powerful privilege that
"This is by design. Members of the local Administrators groups are trusted
users that have the ability to access any information that can also be
accessed by the operating system itself."
http://support.microsoft.com/default.aspx?scid=KB;en-us;q184017