Security Basics mailing list archives

Re: ADS Password Storage Protection


From: Neil <neil () voidfx net>
Date: Sat, 15 Jul 2006 02:14:01 +0530

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rolando_ruiz () jetaviation com wrote:
I'm looking for best practice ways of protecting access to password
storage in Active Directory. I have some immediate questions:

Where exactly are passwords kept?
Are these passwords kept in plain text?
How can I protect these passwords from being hacked? (Encryption,
restrictions, etc...)

Thank you in advanced 

________________________________

Jet Aviation Holdings, Inc.
Rolando Ruiz


Unless I am mistaken, passwords are stored hashes in
%systemroot%\ntds\ntds.dit on the domain controllers.

So no, not plain-text.  Windows uses a one-way hashing algorithm to hash
the password when the password is set and stores that; and then takes a
hash of the password supplied with the client authenticates.  It
compares the supplied authentication password hash to the hash it made
and stored when the password was set.  If the hashes match, then the
passwords must match (in theory).  On the other hand, since only a
one-way hash is stored, there is no way to derive the password itself
from the hash, and so the password is theoretically secure if the hashes
are compromised.

Except for two things: generally, there are a number of likely passwords
a person will use.  For example, their name.  Or the word "password"
(though a lot of people have learned not to do that now).  Most of all,
I see people leaving their password to what the administrator resets it
to.  The other exception is that it is possible to do a dictionary or
brute force attack, in which another computer tries to hash every
possible word from a wordlist or every possible character combination
respectively, and compare that to the stored password hashes until it
finds a match.  John the Ripper, a well known cracker, can do 1,743,539
crypts per second on NT LM hashes on my (fairly modest) computer.
That'll go through any short length password pretty damn fast.  As Roger
said before me, going long is your best bet.  Use a phrase, a short
sentence you can remember easily.

Securing the AD is largely a matter of securing the server itself.
Firstly you need to ensure that the DCs are physically secure, or else
an attacker can take one offline, extract the ntds.dit file, extract the
hashes and run the attacks outlined above.

Disabling the less secure algorithms will help (which Roger also
mentioned), namely LM and NTLMv1.  Be aware that this may break some
legacy applications and Windows Embedded devices.

Use the principle of least privilege liberally here.  Only the bare
minimum staff should have administrative access to the AD and the DC
servers.  Try to avoid giving domain administrator privileges when you
can instead give more limited accounts, or restrict the accounts to
administer only certain sections (and hence aren't domain admins).

Related to the above, separate administrative accounts from your normal
desktop accounts.  If you're running as a domain administrator on your
desktop, you're giving an attacker many more opportunities to gain
domain administrator access to your domain.  Those hashes we spoke of
earlier are often cached to decrease login time and, more importantly,
so that roaming laptop users can log in when they are away from the
network.  Those cached hashes can be dumped and cracked as well.

Rename the Administrator account.  Its security-through-obscurity, so
not good as a standalone measure; but in the context of a holistic
security approach, you're adding just one more small stumbling block to
an attacker.  Though its pretty easy for most attackers to translate the
SID straight to the real Admin account.

Naturally, you're firewalling your DC, running antivirus, and not doing
anything foolish, like using telnet to connect to your server (and
especially not using domain admin credentials).

Hopefully this will help.  If you need more information, I think you
will find plenty on the Internet, as well as published books.

- -Neil.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEuAIROsIj4a0+XVMRAoesAJ946ByGANx93beTpj/oOr4F0bRCpQCgq4rM
VgdSUVEJeWTMxgMuwocIpxg=
=7wVk
-----END PGP SIGNATURE-----

---------------------------------------------------------------------------
This list is sponsored by: SensePost

Hacking, like any art, will take years of dedicated study and  
practice to master. We can't teach you to hack. But we can teach you  
what we've learned so far. Our courses are honest, real, technical  
and practical. SensePost willl be at Black Hat Vegas in July. To see  
what we're about, visit us at: 

http://www.sensepost.com/training.html
---------------------------------------------------------------------------


Current thread: