[cifs-protocol] [REG:110071868986368] unused bytes after while decoding bkrp requests
Bryan Burgin
bburgin at microsoft.com
Tue Aug 10 11:03:03 MDT 2010
Hi, Matthieu,
Just a quick update. I have a pending TDI with the BKRP team to verify our findings that these bytes are unused and should be ignored if received.
Your other three issues we're distributed to other team members and they are contacting you separately.
Bryan
From: Bryan Burgin
Sent: Monday, July 26, 2010 9:36 AM
To: 'mat at samba.org'
Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: RE: [REG:110071868986368] unused bytes after while decoding bkrp requests
Hi, Matthieu,
I made some progress on this last week, but I wanted to close in on a few loose ends before I sent any conclusions. But, let me indicate where I am.
Below is the buffer you provided:
640c2747 c72f9b49 ac5b0e37 cdce899a # 00000000 d.'G./.I.[.7....
74010000 02000000 00010000 58000000 # 00000010 t...........X...
bd8bdca1 3f743e47 8d000a47 42df76bd # 00000020 ....?t>G...GB.v.
30e59a15 1b59b81e b6b82ad0 9f30aab3 # 00000030 0....Y....*..0..
129a9855 63d211e4 4100db37 9cd98663 # 00000040 ...Uc...A..7...c
a1301d8c f4250016 e2c1b036 89108356 # 00000050 .0...%.....6...V
ad8f0b11 6020c407 8177c1d4 957d81e8 # 00000060 ....` ...w...}..
cca6bfc5 f5238d29 2e9c8d21 ffc3b7c3 # 00000070 .....#.)...!....
ba1435ec 6f502414 17835fdc bc2ad9f6 # 00000080 ..5.oP$..._..*..
eef94f63 160afc93 b4a24c10 cf285455 # 00000090 ..Oc......L..(TU
7ea747db 2496e4dd 5f4c0c4d c817c953 # 000000a0 ~.G.$..._L.M...S
db589803 f6f919ec 56b08df5 399dfbea # 000000b0 .X......V...9...
59ddeb3d a0af1b7c e18522d2 1945a814 # 000000c0 Y..=...|.."..E..
2a8f263d 3e4fc84d b5b4eb49 6b16c25f # 000000d0 *.&=>O.M...Ik.._
a73b1ed3 25e984c0 30d956f7 1589d5ac # 000000e0 .;..%...0.V.....
409614ed 02cf6603 eef579a3 c64e59fe # 000000f0 @.....f...y..NY.
0107da5f d1b8d6e3 15287883 4bf65bd6 # 00000100 ..._.....(x.K.[.
b010b774 5faaaac4 4f53e71f fde4aba3 # 00000110 ...t_...OS......
bbf3985c 47ea2ba5 bfa1bea2 3b3b136a # 00000120 ...\G.+.....;;.j
aa5e85dd fbdf5c8e 0fc49edf 43b7b8aa # 00000130 .^....\.....C...
0117f6d4 93cb35b9 9f572aed 8d6fdc4d # 00000140 ......5..W*..o.M
9cae9f2a 45c9bbf5 488a3e98 6293b820 # 00000150 ...*E...H.>.b..
770e8f24 7516122e 7bf0b961 1dee8f2a # 00000160 w..$u...{..a...*
edfbed39 41ba7391 680c214b 9d2e133b # 00000170 ...9A.s.h.!K...;
4a5a9683 744d5234 74010000 00000000 # 00000180 JZ..tMR4t.......
8ae31371 02f43671 02402800 307cde3d # 00000190 ...q..6q.@(.0|<mailto:...q..6q.@(.0|>.=
5d16d111 ab8f0080 5f14db40 01000000 # 000001a0 ]......._..@<mailto:......._..@>....
045d888a eb1cc911 9fe80800 2b104860 # 000001b0 .]..........+.H`
02000000 # 000001c0 ....
I was focused on your specific question regarding the apparent extra 52 bytes. I found the code where I believe this structure is allocated and it appears that we do some rounding-up as we determine how many bytes to allocate. And then, when we encrypt and send the buffer, the total allocation is transmitted.
It begins with BACKUPKEY_RESTORE_GUID
47270C64-2FC7-499B-AC5B-0E37CDCE899A:
640c2747 c72f9b49 ac5b0e37 cdce899a # 00000000 d.'G./.I.[.7....
It then contains what appears to be the length of the remaining buffer (0x174/372). This caught my attention and I'll discuss this in a bit.
74010000 ........ ........ ........ # 00000010 t...............
Followed with 372(0x174) bytes starting with three DWORDS:
-- Version 2: BACKUPKEY_RECOVERY_BLOB_VERSION_VISTA
-- 0x100 (256): length of Encryption Secret
-- 0x58 (88): length of Access Check
........ 02000000 00010000 58000000 # 00000010 t...........X...
-- GUID-Key:
bd8bdca1 3f743e47 8d000a47 42df76bd # 00000020 ....?t>G...GB.v.
-- The encrypted secret (for 256 bytes):
30e59a15 1b59b81e b6b82ad0 9f30aab3 # 00000030 0....Y....*..0..
129a9855 63d211e4 4100db37 9cd98663 # 00000040 ...Uc...A..7...c
a1301d8c f4250016 e2c1b036 89108356 # 00000050 .0...%.....6...V
ad8f0b11 6020c407 8177c1d4 957d81e8 # 00000060 ....` ...w...}..
cca6bfc5 f5238d29 2e9c8d21 ffc3b7c3 # 00000070 .....#.)...!....
ba1435ec 6f502414 17835fdc bc2ad9f6 # 00000080 ..5.oP$..._..*..
eef94f63 160afc93 b4a24c10 cf285455 # 00000090 ..Oc......L..(TU
7ea747db 2496e4dd 5f4c0c4d c817c953 # 000000a0 ~.G.$..._L.M...S
db589803 f6f919ec 56b08df5 399dfbea # 000000b0 .X......V...9...
59ddeb3d a0af1b7c e18522d2 1945a814 # 000000c0 Y..=...|.."..E..
2a8f263d 3e4fc84d b5b4eb49 6b16c25f # 000000d0 *.&=>O.M...Ik.._
a73b1ed3 25e984c0 30d956f7 1589d5ac # 000000e0 .;..%...0.V.....
409614ed 02cf6603 eef579a3 c64e59fe # 000000f0 @.....f...y..NY.
0107da5f d1b8d6e3 15287883 4bf65bd6 # 00000100 ..._.....(x.K.[.
b010b774 5faaaac4 4f53e71f fde4aba3 # 00000110 ...t_...OS......
bbf3985c 47ea2ba5 bfa1bea2 3b3b136a # 00000120 ...\G.+.....;;.j
-- The Access Check (for 88 bytes)
aa5e85dd fbdf5c8e 0fc49edf 43b7b8aa # 00000130 .^....\.....C...
0117f6d4 93cb35b9 9f572aed 8d6fdc4d # 00000140 ......5..W*..o.M
9cae9f2a 45c9bbf5 488a3e98 6293b820 # 00000150 ...*E...H.>.b..
770e8f24 7516122e 7bf0b961 1dee8f2a # 00000160 w..$u...{..a...*
edfbed39 41ba7391 680c214b 9d2e133b # 00000170 ...9A.s.h.!K...;
4a5a9683 744d5234 ........ ........ # 00000180 JZ..tMR4........
Following the 372 (0x174) bytes, I see the length again and zero
........ ........ 74010000 00000000 # 00000180 ........t.......
Which you identified as:
> data_in_len : 0x00000174 (372)
> param : 0x00000000 (0)
> dump OK
In your original mail.
Lastly, I see the unused 52 bytes at the end:
[extra 52 bytes starts here]
8ae31371 02f43671 02402800 307cde3d # 00000190 ...q..6q.@(.0|<mailto:...q..6q.@(.0|>.=
5d16d111 ab8f0080 5f14db40 01000000 # 000001a0 ]......._..@<mailto:......._..@>....
045d888a eb1cc911 9fe80800 2b104860 # 000001b0 .]..........+.H`
02000000 # 000001c0 ....
I'm fairly certain that these 52 trailing bytes are unused and should be ignored. But, I got side tracked looking at what appears to be a length field immediately following the BACKUPKEY_RESTORE_GUID and that it appears to be replicated immediately following the buffer as if they were bookends.
Let me fully read the message you just sent as it has a couple of questions. I wanted to share with you the status of where I was on your original question.
Bryan
-----Original Message-----
From: Matthieu Patou [mailto:mat at samba.org]
Sent: Sunday, July 25, 2010 1:55 PM
To: Bryan Burgin
Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: Re: [REG:110071868986368] unused bytes after while decoding bkrp requests
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|<mailto:.@(.0|>.=
> [0010] 5D 16 D1 11 AB 8F 00 80 5F 14 DB 40 01 00 00 00 ]....... _..@<mailto:_..@>....
> [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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100810/380e9b23/attachment-0001.html>
More information about the cifs-protocol
mailing list