From: Luke Kenneth Casson Leighton [lkcl@SAMBA.ORG] Sent: Sunday, June 04, 2000 4:34 PM To: BUGTRAQ@SECURITYFOCUS.COM Subject: NT admin password change algorithms expose user plaintext passwords eye-catching subject line, huh? well, under specific circumstances, unfortunately, it's true. as it's now early morning, i shall be reasonably brief. conditions required if using NTLMv1 (LmCompatibilibyLevel=0): - 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. i'll 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, microsoft finally fixed this YESSS!) 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. - NTLMv2 (LmCompatibilitylevel=0x5). basically the same thing, except that microsoft got really sophisticated with NTLMv2, and to my 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 - scratch that, i think it _is_ doc'd) are secure, at which point, i am off the deep end. been meaning to get SMB signing for a while. except there's not very much demand for it in the samba community. you know, i think it _is_ actually documented, somewhere. i have some vague recollection of seeing it on the CIFS lists, some time back... 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