[cifs-protocol] [REG:110071868986368] unused bytes after while decoding bkrp requests
Matthieu Patou
mat at samba.org
Sun Jul 25 14:55:21 MDT 2010
Hi Bryan
Any news on this subject ?
In the mean time I worked on the implementation of the protocol for the
samba project and have more questions now.
So page 31 of MS-BKRP.pdf state that the message format for exchange is :
NET_API_STATUS BackuprKey(
[in] handle_t h,
[in] GUID* pguidActionAgent,
[in, size_is(cbDataIn)] byte* pDataIn,
[in] DWORD cbDataIn,
[out, size_is(,*pcbDataOut)] byte** ppDataOut,
[out] DWORD* pcbDataOut,
[in] DWORD dwParam
);
I already asked if there is not some bytes after the dwParam.
After analyzing the out message I have the impression that before the
ppDataOut there is some kind of integer.
Here is the hex dump of an output message:
00000000 00 00 02 00 44 00 00 00 00 00 00 00 8d 65 cd e4
|....D........e..|
00000010 6c 93 62 22 48 e7 04 ff 0c 8f 0e 83 7a e4 dd d4
|l.b"H.......z...|
00000020 4b d1 8e 74 95 67 4f 85 be a5 9c b7 7f fd 39 2c
|K..t.gO.......9,|
00000030 54 bc a7 60 e4 e0 13 26 49 6f ca 35 ee bb 23 24
|T..`...&Io.5..#$|
00000040 51 d4 4e c9 37 1d f0 9e 83 69 bd 10 44 00 00 00
|Q.N.7....i..D...|
00000050 00 00 00 00 |....|
00000054
so from byte 4 (0x44 ) we have clearly (at least to me) the ppDataOut
variable that is NDR encoded (meaning that the size is specified before
on the wire) up to byte 4B then we have the size (pcbDataOut) (0x44 0x00
0x00 0x00) and then the return code.
I attach the out message extracted from the trace I sent last time.
With the following samba idl:
[public,nopush,nopull,noprint] WERROR bkrp_BackupKey (
[in,ref] GUID *guidActionAgent,
[in,ref] [subcontext(4)] uint8 *data_in,
[in] uint32 data_in_len,
[in] uint32 param,
[out] uint32 misc,
[out] DATA_BLOB secret,
[out] uint32 data_out_len
);
We have the following result while using our ndrdump tool:
pull returned NT_STATUS_OK
bkrp_BackupKey: struct bkrp_BackupKey
out: struct bkrp_BackupKey
misc : 0x00020000 (131072)
secret : DATA_BLOB length=68
data_out_len : 0x00000044 (68)
result : WERR_OK
dump OK
As I have also managed to get a correct
BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID exchange I also witnessed that on
the out message there is also "something" (that I named misc in our idl)
(see the get_key_out file which is the extraction of out message on a
BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request). As the certificate that I
extracted seems to be correct I pretty encline to think I am right as
first we are able to parse the NDR encoded data, and that the result
seems sensible.
Can you see if my analysis is correct and if so can you give us the
explanation of this "misc" parameter. If not, well please tell me the
correct way to parse the message.
Also I've got questions of what is explained in the document.
First in paragraph 3.1.4.1.3, it is stated
"The server MUST ignore the cbDataIn and pDataIn parameters. It MUST
return the RSA public key
from the ClientWrap key pair, in the format specified in section 2.2.1.
If no such key can be found or
created, the server MUST return an error."
The client is supposed to send a 2.2.2 Client-Side-Wrapped Secret struct
in the pDataIn variable, this struct contains also a version field and a
guid field.
Nothing is said about this fields, how should they be populated, can you
explain this ?
Second in paragraph 1.3.1 Call Flows, it is stated
"For the ClientWrap subprotocol, the Microsoft implementation of the
BackupKey Remote Protocol
server stores the following LSA global secret objects (note that the LSA
global secret names are
Unicode strings):
1. G$BCKUPKEY_PREFERRED: This contains the 16-byte GUID ([MS-DTYP]
section 2.3.2.2) of the
RSA key pair currently used for client-side secret wrapping.
2. G$BCKUPKEY_guid: Here, guid is the string GUID that identifies the
wrapping key, formatted as a
GUIDString ([MS-DTYP] section 2.3.2.3). The value of the secret object
is the server's ClientWrap
key pair, formatted as specified in section 2.2.5"
Should I conclude that in a given domain there is only "active" rsa key
on all the server or said in another way no matter which server is asked
at a given moment we will always receive the same GUID for the key ?
Also just to be sure this will be stored in the currentValue attribute
but it will be only accessible through a lsaQuerySecret call right ?
Regards.
Matthieu .
On 19/07/2010 03:06, Bryan Burgin wrote:
> [Mark and dochelp to bcc]
> [Adding case number& CaseMail]
>
> Hi Matthieu,
>
> I began looking at this for you to identify the trailing bytes you specified and to investigate tools to decode/parse the Backup Key request. I'll reply with more information as soon as I have more information to share.
>
> Bryan
>
> -----Original Message-----
> From: Mark Miller (MBD)
> Sent: Sunday, July 18, 2010 11:50 AM
> To: mat at samba.org; Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE: unused bytes after while decoding bkrp requests
>
> Hi Matthieu,
>
> Thank you for your question. A colleague will contact you to investigate this issue.
>
> Regards,
> Mark Miller
> Escalation Engineer
> US-CSS DSC PROTOCOL TEAM
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat at samba.org]
> Sent: Sunday, July 18, 2010 2:27 PM
> To: Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
> Subject: unused bytes after while decoding bkrp requests
>
> Dear dochelp team,
>
> I started to implement the backup key remote protocol for samba.
>
> Right now I'm a bit suspicious I got the data structure ok as when I parse some bytes with ndrdump I have ~52 bytes unused.
>
> From the attached capture called protected_storage.pcap I managed to extract and decrypt the payload (452 bytes + 12 bytes of padding) at packet 485.
> The payload is also attached to this email as protected_xtr.
>
> Here are the result of ndrdump
> mat at ares:/usr/local/src/samba4/source4$ ./bin/ndrdump protected_storage bkrp_BakuprKey in ~/protected_xtr pull returned NT_STATUS_OK WARNING! 52 unread bytes
> [0000] 8A E3 13 71 02 F4 36 71 02 40 28 00 30 7C DE 3D ...q..6q .@(.0|.=
> [0010] 5D 16 D1 11 AB 8F 00 80 5F 14 DB 40 01 00 00 00 ]....... _.. at ....
> [0020] 04 5D 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 .]...... ....+.H`
> [0030] 02 00 00 00 ....
> bkrp_BakuprKey: struct bkrp_BakuprKey
> in: struct bkrp_BakuprKey
> guidActionAgent : *
> guidActionAgent :
> 47270c64-2fc7-499b-ac5b-0e37cdce899a
> data_in: struct bkrp_client_side_wrapped
> version : 0x00000002 (2)
> encrypted_secret_len : 0x00000100 (256)
> access_check_len : 0x00000058 (88)
> guid :
> a1dc8bbd-743f-473e-8d00-0a4742df76bd
> encrypted_secret : DATA_BLOB length=256
> access_check : DATA_BLOB length=88
> data_in_len : 0x00000174 (372)
> param : 0x00000000 (0)
> dump OK
>
> To me the result looks sensible I'm just concerned that it seems to have some garbage at the end.
>
> I tried to analyze the frames with netmon 3.4 but it says that it's encrypted (and I didn't find a way to tell him to decrypt ...).
>
> So here is my question: is it normal that I found some trailing bytes ?
> do you have the capacity to parse the protected_xtr file and give us the result of the parsing with your tools ?
>
>
> Cheers, Matthieu.
>
--
Matthieu Patou
Samba Team http://samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: protected_xtr_out
Type: image/x-icon
Size: 84 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100726/65ba7ce6/attachment.ico>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: get_key_out
Type: image/x-icon
Size: 788 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100726/65ba7ce6/attachment-0001.ico>
More information about the cifs-protocol
mailing list