From: Luke Kenneth Casson Leighton [lkcl@SAMBA.ORG] Sent: Sunday, June 04, 2000 3:38 PM To: BUGTRAQ@SECURITYFOCUS.COM Subject: Why You Should Upgrade To NT4 SP4 or NT5 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 Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals