Ethereal-dev: Re: [Ethereal-dev] Fix for NTLMSSP decryption support with DCE/RPC auth padding
On Mon, Jul 21, 2003 at 09:09:25AM -0400, Devin Heitmueller wrote:
> I don't see why not. Of course, I'm starting to question whether this
> is "auth padding" or if perhaps this is really "stub padding". Bear
> with me for a second. In most cases of padding, I believe you pad AFTER
> a specific field. Since the authentication follows the stub, couldn't
> one argue that this is really padding to the stub, and not for the
> authentication? Is there something in a spec somewhere that refers
> specifically to it as "auth padding",
Yes:
http://www.opengroup.org/onlinepubs/009629399/chap13.htm
See the "Common Authentication Verifier Encodings" section, which says:
The common authentication verifier is defined as the following
structure:
typedef struct{
/* restore 4 byte alignment */
u_int8 [size_is(auth_pad_length)] auth_pad[]; /* align(4) */
u_int8 auth_type; /* :01 which authent service */
u_int8 auth_level; /* :01 which level within service */
u_int8 auth_pad_length; /* :01 */
u_int8 auth_reserved; /* :01 reserved, m.b.z. */
u_int32 auth_context_id; /* :04 */
u_int8 [size_is(auth_length)] auth_value[]; /* credentials */
} auth_verifier_co_t;
The auth_pad field is required to restore 0 mod 4 alignment following
the stub data, if any. It consists of 0, 1, 2 or 3 null bytes.
Perhaps Microsoft "embraced and extended" that field to specify padding
to make the stub data a multiple of 16 bytes for NTLMSSP (I think I
mentioned that possibility in mail on this topic a while ago), but the
DCE RPC 1.1 spec, at least, seems to indicate that it's there to align
the fields of an "auth_verifier_co_t" on a 4-byte boundary.
> > Also, if the stub *is* encrypted, is the *decrypted* stub also padded
> > with that many bytes? If so, the relevant decrypted stub bytes should
> > also be marked as padding.
>
> Yes, and in encrypted traces, it does just this. In an encrypted
> trace, selecting the auth padding field highlights the last N bytes of
> the decrypted NTLMSSP block
OK, that's there.
> (which is zeros).
Not always - in a capture that I think you sent out, named
"new_nt4w_to_nt4s_passchange_abcd_to_efgh", in frame 26 the 12 bytes of
padding aren't all zero.
I might, however, be inclined to show that frame with the NTLMSSP
verifier, followed by encrypted stub data, decrypted stub data, and
padding, and then show after that the SAMR dissection (as I see the
encryption as part of DCE RPC, not of SAMR, and would expect the
protocol-atop-DCERPC part of the tree for an encrypted packet to look
the same as it would if that data hadn't been encrypted).
