Finding an MS flaw.

Setting: A large network, educational or corporate, on a domain.
Domain: Windows Server 2003
Client OS: Windows XP Professional SP2

Upon locking a client PC, I can unplug the network cable, and still be able to unlock the system. This means that the client is not validating my password against the server. Where on a WinXP system is a domain user's password stored?

There has to be a way to exploit this...assuming it hasn't been done already.

If anyone has any info on the subject, enlighten me.

Thanks
A_T

User domain passwords are cached on machines that that user logs in on. Go to support.microsoft.com and do a search for cached credentials. Unless you can break the encryption you are not going to be able to get the password itself as it is only saved as a hash, which is also encrypted. When you login it re-hashes your password and checks the newly created hash against the stored hash. This is by-design...

If it could be exploited I'm sure somebody would have done it by now as Windows2000 works the same way.

You can disable password caching by using GPO and setting the number of cached passwords to 0.

Thanks for the response. I don't see *myself* cracking the password hashes on my own...but I would like to see where they are stored as they could be cracked with other software. It'd be nice to write a short app to retrieve all the info.

A_T

For most purposes you can almost always assume that domain related cached passwords used with NTLM or kerberos are stored in the SAM database.

If you have admin privileges or can boot the machine with a cd you can get the hashes and then use something like lophtcrack to try and crack them. The main reason that using strong passwords is so important.

I've seen SAM files...and I've cracked them. I've only seen local users in there.

A_T

Hey Hey,

You might want to check out these two sites.

http://msmvps.com/bradley/archive/2004/12/20/26452.aspx

This site refers to cached domain credentials and security threats they pose as well as protection... it's fairly basic and a short read but it should give you some details..

http://www.chiark.greenend.org.uk/pi...ry/023149.html

This thread is older but it demonstrates that another security risk that cached domain credentials can pose and provides mention that a tool has been created that dumps this hashes.... however it doesn't provide that tool..

They may help to point you in the direction of whatever you are looking for.


Peace,
HT

Hmmm,

To go back to your original post:

Quote:

---

Upon locking a client PC, I can unplug the network cable, and still be able to unlock the system. This means that the client is not validating my password against the server.

---

If you have unplugged the network cable, how on earth can the client validate your password against the server...............by carrier pigeon? :D ...................you have turned it into a stand alone machine?

AFAIK the "lock" is stored on the server, and I do not believe that it is stored with the password. I must admit that I have not tried it with Server 2003, but with NT4 it seemed to be held against the user profile. You got a message something like "cannot establish network connection, do you want to use locally stored information?"

The acid test is: after booting the machine in stand alone mode, can you access the network.........I know that the answer with NT4 Server is "no" because it would require you to log in to the network and discover the lock.

I believe that the locking is on the server side even now, as your experiment seems to prove. The profile moves from the client to the server if the user makes changes. This is intentional, as Microsoft assume that you would want to be able to perform local tasks (wrrd processing etc) if the network went down.

The question then becomes "where is the lock stored on the server".............if it is in the user profile then you need a mechanism to send it back down to the client. If it is stored elsewhere you would need to delete the user profile on the client?

Just a few thoughts

:)

There is a potential security weakness, but this should only be if the perpetrator gained physical access, grabbed the SAM file and cracked it. Otherwise your server will be owned in next to no time, and the game is over.

I am not sure of the current buzzword, but they used to be "roaming profiles" which allowed users to use any machine on the site. If that were disabled then the user could only use their credentials from their allocated machine. This would considerably mitigate the potential vulnerability.

I am afraid it is the old trade- off between security and functionality.

Nihil, you are making a confusion with "roaming profiles" and "cached credentials" - they are diferent things. I think you want to say cached credentials.

Axess, this is not a flaw. it was made by design. I can tell you why.

A lot of laptop users (on novell networks) always had complained about they coudnt lock they computers, unplug it from network, carry to another place, plug it, and reconnect. Netware doesnt allow that.

So MS, did it (IMO) in a smart way: after validation, MS network doesnt need persistent connection, because they use a "trust relationship schema", where servers trust to computers (because all workstations must join the domain before anyone can log in there) to store temporary credentials during user session. This mechanism is called "cached credentials".

However, they can pose a threat to system: someone may crack the cached credentials (never saw a tool to do that but its possible). Thats why most companies just dont allow that cached credentials stay PERSISTENT (as mohaughn state on his/her post.)

But even you turn that parameter to zero (no persistent cached credentials) , Windows network still cache TEMPORARY credentials during logon sessions. Thats why you can unlock without network. Its doesnt pose an additional threat; that credential will be erased when you logged off.

But it helps A LOT on network traffic. :)

And its its good for other features, such as mapped network drivers. (File) Servers dont need to maintain persistent connection with the stations: if you access a network drivers and it is disconnect, windows simply reconnects (using cached credentials IF NECESSARY) and give you the access. Nice, isnt it?

I just did some doublechecking and I was indeed wrong about the SAM thing. Not sure where I got that from, but I was pretty sure I read that in an MS article yesterday.. but I can't find it now..

So now I'm pretty sure that these passwords are syskeyed and stored in the registry... I read something earlier that was theorizing that they are stored in hklm\security\cache. There are eleven entries there NL$1 through NL$10. I have my pword caching disabled and they are all 00'ed out. Other than NL$Control.

You'll have to use regedt32 and change the permissions on the hklm\security hive to allow your user account to view it. Otherwise only system can view that hive. Make sure that change the permissions back when you are done.

It should be pretty easy to test and see if that is indeed the password caching.. create a new domain user and then log in with that user account.. See if all of the entries shift down by one and are a new one appears.. Of course this is probably just a pointer to somewhere else in the LSA secrets that the true hashes are actually stored...

http://support.microsoft.com/default...b;en-us;199071

Note the very bottom of the article where it says this-

"Secret Name Type of Information
G$$DOMAINNAME Trust to domain DOMAINNAME
G$<other name> Other global secret
$MACHINE.ACC Machine account password for this computer
NL$xx Cached logon credentials
*ServiceName* Information stored by that service"

Although this could also just be regular cached application passwords.. But it seems strange that they would use that portion of the registry for application passwords... worth checking out though.

Hopefully I'll remember to check tomorrow. I have to see login in as Admin, and find the key. I wonder if different domain servers change that type of thing..., or if it's WinXP that takes care of all that.

Thanks alot for the info.
A_T