recently, netect / bindview posted a review of the syskey system and how
the RC4 cypher stream was reset each time. standard RC4 attack analysis
shows that XORing two obfuscated passwords together results in the XOR
cypher stream dropping out, and you have the two XORed password. further
attack analysis can decrypt the passwords.
i am looking to implement an equivalent mechanism to SYSKEY, however i do
not have the relevant security skills to say whether a proposal is secure
or not.
i will outline the requirements, first, and then a possible proposal.
1) the SAM database may be accessible read-only (for example on NT, using
REGEDT32 or PWDUMP or PWDUMP2) it should not be possible to decrypt the
passwords, even though it is possible to obtain a binary or over-the-wire
copy of the SAM database.
2) a mechanism to encrypt or decrypt the passwords should be reasonable
fast so that any updates do not result in simultaneous accesses to the SAM
database locking each other out for significantly [relatively] long
periods of time.
the idea i came up with is this:
1) create a syskey key. it can be any length. this is privately stored /
protected.
call this syskeyN
2) take the binary data of the user's profile (on NT, see
HKLM\SAM\Sam\Domains\Account\Users\000001f4\V for an example: this is the
administrator account. you will need to add permissions to access
HKLM\SAM: remember to remove them afterwards!)
this binary data is also known as the NDR of the user's profile.
microsoft's SAM developers and DCOM / DCE/RPC developers know exactly what
this is.
make a copy of the NDR data, and zero out the part with the password.
call ths usr21Z
3) use HMAC_MD5T64 to generate an RC4 key. the definition of HMAC_MD5T64
is basically that it's a version of HMAC_HD5 except that instead of, at
the start of the algorithm, if the key is > 64 bytes, you truncate it
instead of using MD5(key).
sooo, i said that the syskey key can be any length, but it can actually
only be <= 64 bytes.
unless microsoft fixes their version of HMAC_MD5, which is currently not
compliant with rfc 2104.
4) the rc4 key, K is calculated:
K = HMAC_MD5T64(syskeyN, usr21Z);
5) the encrypted passwords LM# and NT# are calculated:
E(LM#) = rc4(K, LM#)
E(NT#) = rc4(K, NT#)
6) the encrypted passwords are subsituted back into the NDR data.
the result is that the password hashes can only be decrypted if the secret
key, syskey, is known, even if a copy of all the binary NDR user data is
available.
notes
1) LM# and NT# could, for backwards-compatibility, in fact be the
DES-RID-wrapped-1.75-times versions of LM# and NT#, in step 5, above.
2) MD5 is 16 times more computationally expensive than MD4. are there
any better/simpler algorithms?
3) do you _really_ need to do this:
lock SAM database. obtain user binary data (usr21). calculate key,
enc-pwdds, store data, unlock SAM database.
i think so, in which case notes 2) becomes a problem if the algorithm is
slow.
4) usr21Z contains timestamps (8-byte NT format) on when the password was
last changed, _and_ when the user last logged in, _and_ when the user last
logged off. the data is therefore constantly changing, and each change
will require a new update to the encrypted password field (syskey2).
comments, please! especially on whether the usr21Z data is sufficient to
produce variations in the per-user key, particularly as the various
time-stamps keep changing.
thx,
luke (samba team)
p.s the definition of # is actually "octothorpe" - an eight-sided
figure.
it is pronounced, everywhere except in the u.s, as "hash". for those
people in the u.k who have ever tried to use a u.s. keyboard or listened
to automated telephone instructions, shift-3 and the button underneath 9
on a telephone _is_, to americans, the pound symbol.
<a href="mailto:lkcl@samba.org" > Luke Kenneth Casson Leighton
</a>
<a href="http://www.cb1.com/~lkcl"> Samba and Network
Development </a>
<a href="http://samba.org" > Samba Web site
</a>
<a href="http://www.iss.net" > Internet Security Systems,
Inc. </a>
<a href="http://mcp.com" > Macmillan Technical
Publishing </a>
ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals
