Difficulties around GSSAPI/Kerberos support during experiments with MS-NNS

[Macmod]

I recently implemented a library for ADWS, a protocol built on top of Microsoft's NegotiateStream protocol, and used go-msrpc's ssp package to handle GSSAPI. I'm aware that's not the main purpose of this repo, but it's so useful that it would be a waste not to use it. I'm not an expert on Kerberos, but I found interesting behavior:

I tried to follow the spec for NNS directly with GSSAPI, and it did not work immediately (the server closed the connection). So I made a simple .NET program to capture a flow of the official .NET library call using Kerberos, and this was the result:

The EC is set to zero, but for some reason the code for aes_cts_hmac_sha1.go always sets it to 16.

The baseline RFC4121 specifies that:

In Wrap tokens with confidentiality, the EC field SHALL be used to
encode the number of octets in the filler, as described in section
4.2.4.
In Wrap tokens without confidentiality, the EC field SHALL be used to
encode the number of octets in the trailing checksum, as described in
section 4.2.4.

In 4.2.4 it also states the following about the "text to be encrypted":

Filler octets MAY be inserted between the plaintext data and the "header". The values and size of the filler octets are chosen by implementations, such that there SHALL be no crypto-system residue present after the decryption.

From what I take it suggests that the inner filler (padding) is implementation-specific, but as far as I could check AES-CTS-HMAC-SHA1 shouldn't need padding, as the algorithm handles padding by itself. It shouldn't matter really if the extra padding just goes in and out, but for mysterious reasons, the only way I could get NNS to work was setting EC to zero and adding Signature to UnwrapEx. I'm not sure whether this is a bug or not, but it seems worth discussing.

[oiweiwei]

Signature in Unwrap/Wrap missed is a bug, (it's not used in MSRPC, so it was missed). EC value is more complicated topic, it seems like it was required to be 16 always for WrapEx/UnwrapEx (I was cross checking with heimdal library, but again, as we don't care about plain Wrap/Unwrap, perhaps we can think of something.

[oiweiwei]

So basically the problem is MSRPC cannot rely on padding of AES-CTS for some reason, but I need to brush up on this

[Macmod]

That was quick! Thanks for your thoughts @oiweiwei. I'm still trying to understand this thing myself, but I'm sure you'll have more context. I'll keep you posted if I find anything else worth noting.

[Macmod]

(I forgot to update "Size" in my branch, but you get the idea)

[oiweiwei]

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/e94b3acd-8415-4d0d-9786-749d0c39d550

Pad: For AES-SHA1 ciphers using GSS_WrapEx, the extra count (EC) must not be zero. The sender should set extra count (EC) to 1 block - 16 bytes. The recipient must follow the extra count (EC) field in the wrap header to know how many of the decrypted bytes are just padding and must be discarded from the result.

I think this gives some explanation.

https://github.com/heimdal/heimdal/blob/abd35b246a7ab3b304c3ca918e52240154b87008/lib/gssapi/krb5/cfx.c#L166

heimdal code, here EC is set to checksum length ??

[Macmod]

I have a repo with working examples locally, I'll share it here in a bit

[oiweiwei]

The RFC says it's really supposed to be checksum length when confidentiality is off (or the "implementation-specific" filler otherwise), my scenario has confidentiality + signing on

So the problem is that RFC implies one thing, but given that I've implemented thing to match WrapEx semantic in MS-KILE it doesn't work with plain Wrap (as its defined in RFC). That's how I understand it wrt to EC.

[oiweiwei]

Now I'm starting to remember... (maybe) the problem was that msrpc packets were already padded enough to contain no crypto residual, so 16 is just a block size we need to add to ensure thar pad is non-zero (as per MS-KILE) requirement, and contains no crypto residual (hence full block is a pad = 16)

[oiweiwei]

For Wrap there is no such requirement (MS-KILE is for WrapEx). So, we need to split Wrap and WrapEx flows. (Wrap must comply with RFC)

[Macmod]

Here you go:
https://github.com/Macmod/sopa

It's very experimental so many features may have bugs, but it should allow for basic testing with:

# with or without -k
$ ./sopa query --dc 192.168.88.22 -u <user> -p <pw> -d <domain> --filter '(objectClass=computer)'

There's a replace in there pointing to my fork of go-msrpc, if you remove the replace you can replicate the issue

[oiweiwei]

@Macmod so found a way how to make it work for both msrpc and sopa. #104. though I'm not sure about zero size payloads, let me know if you will find anything.

[Macmod]

It worked perfectly, thanks again @oiweiwei, you're the best 🥇

[oiweiwei]

deleted comment made me stand up from the sofa :) you're welcome, hope it didn't break anything in rpc flow (though i've tested it through with various combinations - dce-style=true/false header-sign=true/false mutual-auth=true/false enc-types=rc4-hmac/aes

[Macmod]

deleted comment made me stand up from the sofa :) you're welcome, hope it didn't break anything in rpc flow (though i've tested it through with various combinations - dce-style=true/false header-sign=true/false mutual-auth=true/false enc-types=rc4-hmac/aes

Don't worry, I was just being dumb and running go build without ./cmd/sopa. My bad: P

[Macmod]

I'll add an acknowledgement for you in go-adws and in sopa. Great work!