Why You Should Upgrade To NT4 SP4 or NT5

[lkcl () SAMBA ORG (Luke Kenneth Casson Leighton)]

this issue, if discovered back in august 1997 when the original posting
came out from paul ashton and myself 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 posted to ntbugtraq a few
months back, by todd sabin et al. at netect / bindview of SYSKEY?  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 me?  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, the ISBN number is at
the end of this message.  so i will not go into detail here, i 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, i'm 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??  i mean, 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?

[i'm having some difficulty keeping my language to normal terms, here.
every time i recount this tale, i get to this point and _still_ don't
believe it].

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.

a classic example of... no, never mind, i'm not going to say it.  ok, to
hell with it, yes i will.

THIS IS WHY YOU DON'T LET PEOPLE DESIGN PROPRIETARY SECURITY SYSTEMS, THEY
SCREW IT UP.

ahem. sorry about that.

so, what has been done about this?  well, in nt4 sp4 there was added a
system which, for lack of documentation on the subject from the authors, i
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, ISBN no at end of message.
source code, 98% complete implementation, as there is a single section of
8 bytes that i 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 i am
sure, a Giant Leap Forward.

interesting side note 1: if you use NT5, the bits negotiated are something
weird like 0x7ff001ff, which i 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.

so, if you got to the end of this message and you are still using NT4 SP3
or below, i can only ask, why???

all the best,

luke

<a href=" mailto:lkcl () samba org" > Luke Kenneth Casson Leighton    </a>
<a href=" http://cb1.com/~lkcl";  > Samba and Network Development   </a>
<a href=" http://samba.org";      > Samba Web site                  </a>

ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals