win2k3 to win98

[seatec]

Hi Chris,

thanks for your reply. When I first read it I thought "he wants me to
rtfm. great reply". I have (and also read) your book and done my fare
share of basic cifs auth coding. I know the davenport site, but I didnt
know the ms link. That one was nice, and finally helped me find the
solution.

Where winxp(and earlier) uses the plaintext --(DES)--> LM hash
--(DES)--> Ntlm hash scheme, Win2k3 uses the passwords md4 hash
--(DES)--> Ntlm hash. So the first step is different, the second is not.

What really confused me is that winxp and win2k3 sent exactly the same
packet, but a different password hash, and both actually worked.

Thanks for pointing that ms link out to me. It's sunday night and I
spent many hours on this problem this weekend. Seeing it solved before
the time ran out(too busy during the week) made my day(well, night).

seatec

Christopher R. Hertel wrote:
> Seatec:
> 
> Start here:
> 
>   http://ubiqx.org/cifs/SMB.html#SMB.8
> 
> That should get you most of the way from the old LM hash through NTLM, LMv2,
> and NTLMv2.
> 
> Once you've covered that, you may want to look at:
> 
>   http://www.microsoft.com/technet/technetmag/issues/2006/08/SecurityWatch/
> and
>   http://davenport.sourceforge.net/ntlm.html
> and, of course, Wikipedia.
> 
> The basic problem is that authentication is a moving target.  Microsoft,
> quite reasonably, has to keep introducing stronger authentication methods
> and defaulting to stricter requirements.  Newer systems may, for instance,
> require Kerberos authentication.
> 
> I hope that helps.
> 
> Chris -)-----
> 
> seatec wrote:
>> Hi everyone,
>>
>> after talking to Kai Blin on irc for half a night and part of the day he
>> pointed me to the list.
>>
>> I wrote a little pseudo-cifs server about 2 years ago, which works fine
>> for smbclient, XP (SP2) and others. It doesn't offer much, but it
>> negotiates the challenge/response authentication scheme
>>
>> The client password gets uppercased, padded with zeros to 14 bytes,
>> split into two halves of 7 bytes, 2 eight byte DES keys are created out
>> of those. These 2 keys are used to encrypt a static string -> 2 LM hashes.
>> Those two 16 byte lm hashes are padded with 5 zeros to 21 bytes, split
>> into 3 chunks, DES key creation, those are used to encrypt the challenge
>> -> 24 byte ntlm hash. Thats the scheme we are talking about.
>>
>> 2 nights ago I noticed it doesnt work for win2k3. Knowing the plaintext
>> password and seeing the challenge on the wire, I can create the hash,
>> and I can see smbclient or XP send exactly what I created. Win2k3 also
>> sends a 24 byte hash, but that one is completely off.
>>
>> Whats even more strange: I setup a win98 in vmware and made win2k3
>> connect to a share. I see the whole session negotiation, challenge/hash
>> exchange and everything, and again the hash "should be" different than
>> win2k3 is sending. But not only is the hash I see on the wire different,
>> win98 even accepts that hash and allows the client to log in with it.
>>
>> I don't have the slightest idea what kind of hash win2k3 is sending, and
>> why it works.
>>
>> Last night I compared the pcap of a winxp logging into my little pseudo
>> server with a win2k3 logging in. Both clients send the same flags, the
>> same fields(different account and machine names. but that shouldnt
>> matter), the same everything. As the plaintext password is the same and
>> the challenge for this testcase was static, they should both send the
>> same hash. smbclient sends what xp sends. win2k3 also sends a 24 byte
>> hash, but it's different.
>>
>> If anyone could tell me what kind of hash win2k3 is sending there I'd be
>>  grateful. I can provide pcaps, plaintext password, hash, session
>> key(challenge), ...
>>
>>
>> seatec
>