[cifs-protocol] [Pfif] MS-NRPC: AES Schannel problems
Hongwei Sun
hongweis at microsoft.com
Thu Sep 17 10:22:52 MDT 2009
Metze,
Yes, your initial observation is right. Checksum is only 8 bytes and the cofounder follows with 8 bytes of checksum. I filed a request to update the document.
I will look at the code and compare it with the documentation and Windows implementation. I will let you know.
Thanks!
Hongwei
-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze at samba.org]
Sent: Thursday, September 17, 2009 11:17 AM
To: Hongwei Sun; pfif at tridgell.net; cifs-protocol at samba.org; Nick Meier; Guenther Deschner
Subject: Re: [Pfif] MS-NRPC: AES Schannel problems
Hi Hongwei,
Nick just told me that Windows seems to have a bug there and I tried to "reproduce" this bug in our code, but I still can't get windows to accept signed or sealed traffic from us.
See the attached capture:
Frames 178 and 179 are with signing
Frames 330 and 331 are with sealing
You can take a look at my code here (see the top 5 commits) http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel
metze
> -----Original Message-----
> From: Stefan (metze) Metzmacher [mailto:metze at samba.org]
> Sent: Wednesday, September 16, 2009 1:46 PM
> To: Hongwei Sun
> Cc: pfif at tridgell.net; cifs-protocol at samba.org; Nick Meier; Guenther
> Deschner
> Subject: Re: [Pfif] MS-NRPC: AES Schannel problems
>
> Hi Hongwei,
>
>> I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used. I filed a request to add the information into 3.1.4.4 of MS-NRPC. I also noticed that in mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential. Please let us know if you have resolved the issue and if we can provide further help.
>
> Yes, he does and we got that part working. Thanks!
> using AES_cfb8_encrypt() instead of AES_cfb128_encrypt().
>
> However we have the next challenge, the Netlogon SSPI provider.
>
> I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't work.
>
> Looking at the frame 308 and the following in w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap.
>
> I think there's a bug in w2k8r2 in the docs.
>
> The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values.
>
> It seem that the checksum is still 8 byte and the confounder directly follows. The last 24 bytes are just uninitalized memory.
>
> They are:
> Frame 308:
>
> 32 00 2e 00 33 00 31 00
> 2e 00 39 00 2e 00 32 00
> 31 00 34 00 00 00 00 00
>
> Frame 310:
>
> 35 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 02 00 00 00 00 00
>
> Frame 311: (I think it's random because the pdu is so long and point
> memory in other aeas)
>
> 51 03 21 9b 41 84 cc 90
> e7 e8 70 1c 52 60 55 5a
> 64 0c 6a 17 be 07 de 80
>
> Looks like a unicode string instead of parts of a checksum and a confounder.
>
> metze
>
>> Meanwhile, I provide some sample values that I captured from debugger
> for you to verify your logic.
>> OWF Password :
>>
>> 13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3
>>
>> Client Challenge:
>>
>> 25 63 e3 5f 69 e1 5a 24
>>
>> Server Challenge:
>>
>> 9C 66 5F 90 D9 83 DF 43
>>
>> Session Key calculated:
>>
>> c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70
>>
>> Client Credential:
>>
>> 58 6a df 53 ef 72 78 d9
>>
>> Server Credential
>>
>> E1 41 62 09 B2 3E 57 51
>>
>
> It would be great if you could add this values to the docs.
>
> metze
>
More information about the cifs-protocol
mailing list