COMMAND
kernel
SYSTEMS AFFECTED
WinNT
PROBLEM
Luke Kenneth Casson Leighton found following. NT admin password
change algorithms expose user plaintext passwords. Eye-catching
line, huh? Well, under specific circumstances, unfortunately,
it's true.
Conditions required if using NTLMv1 (LmCompatibilibyLevel=0)
follows. NT admin runs USRMGR.EXE or SRVMGR.EXE and either adds
a new user, workstation or changes a user's password. The
encrypted-password-block goes over-the-wire in full view, i.e.
self-encrypyted but otherwise sticking out like a sore thumb (it's
516 bytes long).
The algorithm used is described in detail in the book mentioned at
the end of this message, but basically it uses what is termed a
"User Session Key" as a straight RC4 key to encrypt a 516-byte
block, mostly random data, with the user's plaintext UNICODE
password and the length of the password, at the end of the block
(if you're getting bored of how frequently microsoft uses RC4 as
a cypher stream and keeps resetting it, get used to it, it appears
to have been pretty much standard practice at the time this stuff
was developed).
NT admin's user session key is: MD4(Administrator's NT#).
So, let's get this straight. You are sniffing network data
(assuming of course that this is possible: most networks are
switched, these days, right?). You capture a couple of 516-byte
blobs from a bored administrator who is adding workstations by
rote to a domain. You XOR the two blocks together, and the last
few bytes are, well, basically, a classic academic exercise in
cryptographic decoding of XORed plaintext.
Let's go through it with you, it's kinda fun.
- if the last 4 bytes of the XORed data-blocks are zero, then the
length of the two passwords are the same.
- if they are non-zero, then you know the difference-in-length.
This might not be useful, until you realise that the passwords are
stored in UNICODE. ascii converted to UNICODE goes like this:
byte, zero, byte, zero....
So, to take a guess (to an accuracy of 255 times out of 256) at
how long one of the passwords is, you skip every other byte and
count the number of zero bytes in the XORed data-blocks.
Then, you can work out, from the XORed lengths, what the length
of the _other_ password was ... but you needn't have gone to all
that trouble, because guess what? If you'd looked at the data
two packets beforehand, you would have seen a SamrCreateUser()
function - oh, that's DCE/RPC \PIPE\samr opcode 0x32, for those
of you who do not have your Windows NT [or samba, for that matter]
source code memorised. And as we all know, workstations added
with SRVMGR.EXE and when joined to a domain (except NT5 wksta)
set the initial password to the name of the workstation.
_However_, this simple fact allows us to work the math from the
other angle: namely, that knowing that _one_ use of
SamrSetUserInfo (opcode 0x3a) can be used to decrypt another, if
one of the plaintext passwords is well-known.
So. To cope, when using LMcompatibilityLevel=0x0 on NT domains,
with the issue of password-changes by administrators going and
pretty much sending the passwords plaintext, and assuming that you
_care_ about security:
1) use switched networks (i.e avoid possibility of unauthorised
network traces being taken)
2) if you see an administrator using SRVMGR.EXE or USRMGR.EXE on
anything other than a secured line, or preferably only on the
console, sack them instantly OR:
3) for every single password change or new user create, change
the administrator's password, as it is basically useless if
used twice.
That includes changing the administrator's password. So if you
change the administrator's password remotely, you have to change
the administrator's password.
What about NTLMv2 (LmCompatibilitylevel=0x5)? Basically the same
thing, except that Microsoft got really sophisticated with NTLMv2,
and to untrained eye, it looks pretty good. It uses HMAC_MD5
three times, making it at least ... um... [quick math, md4 = 4
loops, md5 = 64. 64/4=tired,6am,hmmm.2^6/2^2=2^4 easier to do sub
than div 16*3=48] 48 times more computationally expensive to
brute-force than NTLMv1.
And then there's the "User Session Key", which is calculated from
random information generated in the MS-CHAP sequence, too, which
is really impressive.
Consequences: the "User Session Key" is generated on a
per-connection basis. this means that if you want to keep the
administrator's password secure, then unlike when using NTLMv1,
you only [only] have to drop the connection in between each
remote use of USRMGR.EXE or SRVMGR.EXE or join-NT4-host-to-domain.
To do this, first terminate USRMGR.EXE / SRVMGR.EXE, then pull up
a command-prompt and type:
net use
If there is a \\mypdc\ipc$ connection shown, then do:
net use \\mypdc\ipc$ /del
If it bitches at you and says it's in use, go close all those damn
explorer.exe windows you left lying around, all the _other_
remote-access programs that you leave open as part of your
day-to-day job and which could be hijacked and used for all kinds
of horrible stuff, such as spoofing SamrCreateUser() and
SamrSetUserInfo calls to create accounts like MrHacker (Full name:
Anonymouse Hacker The New Administrator In Town) ... unless, of
course, you are using switched networks and/or SMB signing, or
have gone the whole hog on NT5 and are now using IPsec... assuming
of course that IPsec (a documented protocol) and SMB signing (an
undocumented protocol) are secure, at which point, we are off the
deep end.
SOLUTION
Upgrade to NT5.