COMMAND
kernel
SYSTEMS AFFECTED
WinNT 4
PROBLEM
Luke Kenneth Casson Leighton found following. This issue, if
discovered back in august 1997 when the original posting came out
from Paul Ashton and Luke regarding the nt domain member protocol,
which can be found in the ntbugtraq archives, would have caused
absolute mayhem.
Do you remember that extremely good analysis by Todd sabin et al.
at netect / bindview of SYSKEY? To remember, see:
http://oliver.efri.hr/~crv/security/bugs/NT/syskey.html
And how it outlined how insecure SYSKEY really is, because
essentially it reused the same cypher stream? Well, there's
another place where the same techniques can be applied, and this
time to data that goes over-the-wire, between BDCs and PDCs.
What, you don't believe? Well, have you upgraded all of your BDCs
and PDCs to at least Service Pack 4 or to NT5? Because if you
have, you can stop reading, unless you are curious or want to
scare your administrator colleagues who have not. Particularly
those who have been running Domain Synchronisation over the
internet, in order to keep the company alive across counties,
states or continents.
A specification of the NETLOGON protocol, including the PDC / BDC
synchronisation, has been available since January 2000, the ISBN
number is ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT
Domain Internals. So let's not go into detail here, we just
wanted to make it REALLY clear that you are as good as sending
your ENTIRE SAM database in cleartext over-the-wire if you do not
upgrade to at least NT4 SP4.
It goes something like this:
* NetReqChal - send 8-byte chal, receive 8-byte chal (generate
credential chain from shared secret: 16-byte trust account
password)
* NetAuthenticate2 - send 8-byte authenticator, receive 8-byte
authenticator (by this time, client and server are happy,
to 64-bits of accuracy, that they are who they say they are.
They have also generated a 16-byte session key, with the top
8 bytes set to all zeros).
* NetrSamLogin - send request for entire SAM database, receive
entire SAM database.
uh-oh, hang on, that's not in the original august 97 posting,
what's it doing here? Well, the data sent over-the-wire is pretty
much what you can find in the SAM section of the registry,
including the fact that the NT and LM #es are encrypted with the
RID of their user, concatenated 1.75 times to produce a 7-byte
DES key to enc.. blah blah, we are telling you nothing new, here.
What *is* new is that the LM and NT #es are not sent over-the-wire
in plaintext [*whew*], instead they are sent over-the-wire
encrypted with the 16-byte session key mentioned above.
*silence*.
You mean, the RC4 cypher stream is initialised with the 16-byte
session key, which was carefully set up from random data, and
used to encrypt all of the LM and NT #es as if they were stacked
end-to-end?
No.
They are encrypted by stacking each pair of #es together and
resetting the cypher stream each time. The cryptographically-aware
amongst you can answer the questions of those people trying to get
your attention to ask you why this is SO UNBELIEVABLY STUPID any
time, now. Just please, try to keep the sobbing and repeated
head-banging to a minimum... for now.
... because it gets worse.
So. Notwithstanding that it is possible to do standard
cryptographic analysis of this data, to come up with the NT and
LM #es, and notwithstanding todd sabin's excellent work, there is
a short-cut.
It is assumed that the domain in which you have a PDC and BDC, at
least one of which is SP3 or below.
It is also assumed that this Domain has been in operation for at
least a week, and that users are logging in.
Under these circumstances, there will be at least one machine that
has reset its Trust Account Password. As you are (or should be)
aware, the trust account password is encrypted with the old one.
*only the NT# is sent*.
That means that when this reaches the NT SAM database (registry),
that in the LM# field, guess what? The LM# field is set to 16
bytes of zeros. The NT# field is set, dutifully, to the NT#
encrypted with the RID of the Trust Account blah blah, but who
cares?? Think about it.
Ok. What happens when you XOR a cypher stream with all zeros, and
send it over-the-wire? in particular, what happens when that
same cypher stream is used repeatedly?
So, to decrypt all LM#es in a SAM database from a PDC / BDC sync,
you look for 16-bytes being identical in any two blocks. If both
of those account-names end in a $, chances are that those 16-bytes
can be XORed up and down the length of the LM# area to give you
every single LM# of every single user.
So now you run L0phtCrack for a while, and crack an easy password
or two. Now you go back to the _other_ column the NT# column.
with a little bit of work, you can find a single NT#. Then, you
can work out the NT#-DES-rid-encrypted, XOR it out of the
encrypted block: that gives you the part of the cypher stream for
the NT#es and you run up-and-down the NT# column and decrypt all
the NT #es, too.
Stunning.
In nt4 sp4 there was added a system which, for lack of
documentation on the subject from the authors, we have named /
heard named "the netlogon schannel", or "netlogon secure channel".
_brief_ documentation [because the analysis was incomplete at the
time of writing] available in book. Source code, 98% complete
implementation, as there is a single section of 8 bytes that we
only have the first sequence of a request/response, is in samba,
ftp://samba.org/pub/samba/alpha/samba-tng-alpha-2.5.tar.bz2 will
do the trick, look for rpc_client/cli_pipe_netsec.c and the
server-side impl. Is there, too.
This system uses negotiation flags in the NetAuthenticate2
function call to say, hi, i support netlogon schannel v1,
(0x400001ff) and the server says, funny that, so do i.
At this point, all traffic between the client and server is
encrypted on a second channel, using the 8-byte session key in a
complicated dance that, to my cryptographically untrained eye,
looks actually pretty sound. None of the blindingly stupid
mistakes appear to have been made, and it even uses HMAC_MD5 as
well as RC4. _and_ sequence numbers to calculate the actual
cypher stream to sign and seal the data, which is considered a
Giant Leap Forward.
Interesting side note 1: if you use NT5, the bits negotiated are
something weird like 0x7ff001ff, which we presume means, i support
netlogin schannel v1, v2, vthis and vthat, do you?. i.e. it looks
like Microsoft decided to arm themselves to the teeth on
cryptographic techniques, in the even that they might need them,
which is reassuring in a touching kind of way.
Interesting side node 2: there have been KB articles available for
some time that state how to *mandate* the use of the "netlogon
schannel" at both client and server end. This will have the
effect, if enabled, of rejecting non-encrypted netlogon session
requests.
Interesting side note 3: if you have any unused BDC accounts that
you added with SRVMGR.EXE "just in case you might need them",
remove them NOW. The combination of UDP traffic being used to
locate, and therefore spoof, an NT BDC, combined with the fact
that the default trust account password, when using SRVMGR.EXE and
_also_ when joining an NT BDC to a domain, is the name of the
server in lower-case, makes it incredibly easy for an attacker to
join their own bogus BDC to your domain and suck away your entire
SAM.
SOLUTION
If you got to the end of this advisory and you are still using NT4
SP3 or below, can we only ask, why???