smcintyre-r7
commented
2 weeks ago I pushed up some changes to adjust the REQUIRE_SIGNING option to an enum. The new option defaults to signing and sealing opportunistically, but also has explicit settings for required and disabled.
- :green_circle: Tested Windows Server 2022 LDAP, LDAPS, with NTLM, Plaintext
- :green_circle: Tested Windows Server 2008 LDAP with NTLM
- I tested this one to see what would happen if the server didn't support signing and sealing. Turns out Server 2008 supports it by default, so everything was fine. Now I'm installing a Server 2000 instance to see if it too works just fine.
Neustradamus
cdelafuente-r7
This implements LDAP signing (technically encryption and signing) for both NTLM and Kerberos. LDAP modules should set
LDAP::Signingto eitherautoorrequiredto use it; I've setautoas the default, since most legitimate clients would do the same. When set toauto,LDAP::Signinghas no effect when using auth other than NTLM or Kerberos. In this case, signing is used opportunistically based on the authentication mechanism. Setting it todisabledshould have the same behaviour as before, which will be needed if we implement relaying. Finally, when set torequired, the library will sign traffic, as well as raise an exception if an authentication mechanism is used which is incompatible with signing, e.g.plaintext.This required some monkey patching of the
ruby-net-ldaplibrary, to intercept calls toread(or technicallyread_ber) andwrite- we transparently do the encryption or decryption and pass it back.One weird constraint here is that the 3rd party library pulls BER objects off the network one at a time, thus if a packet contains multiple BER objects, a single call to
read_berwould leave the packet half-unread. This doesn't jive super well with a packet-based decryption routine, so we emulate this by effectively batching up the reads of all BER objects in a decrypted packet, and just remembering them for the next time it's called (this is in reference tober_cache).The other thing worth pointing out is that RC4_HMAC behaves weirdly. As noted in one of the comments:
The RC4 spec (RFC4757) section 7.3 implies that RC4-HMAC only needs one byte of padding, although it doesn't come straight out and say it. Some protocols (LDAP, at least on a DC) complain if you give it more than a single byte of paddding. Other protocols (DRSR) complain if you don't align it perfectly with an 8-byte boundary. The MS-RPCE spec is a little vague on why exactly that might be, but we can at least show empirically that it is happy if you just give it an 8-byte aligned encrypted stub. Yet other protocols are happy whatever the padding (WinRM).
Even more perplexing is that when I decrypted the comms of the Microsoft's built-in cryptdll.dll for DRSR over RC4 (as called by Mimikatz), it seemed to use a completely different padding (and possibly checksum) mechanism. Rather than being PKCS#5-padded once decrypted, it just had a bunch of null bytes at the end (which would never be valid PKCS#5). I couldn't find what spec this was following. But regardless, it accepts the PKCS#5 behaviour, which matches both the RFCs as I could interpret them, and other implementations. In fact, when reading through other tools, the commented-out lines here seem to imply that others may have been similarly perplexed by the behaviour: https://github.com/skelsec/asyauth/blob/4c6fa5e51ac07237cc53f450df11d66803ea2b40/asyauth/protocols/kerberos/gssapi.py#L243-L251
So the approach I've taken is just to provide both behaviours: 1-byte by default (which is my best interpretation of the spec) and PKCS#5 (which fits the behaviour of DCERPC), and the RC4_HMAC encryption routine can be parameterised.
If using LDAPS, the LDAP Server Signing Requirements are satisfied, even without our new signing/encryption. In fact, the DC will straight up fail if you try to do both, as seen in this error message we encountered:
So we prevent this invalid config with an error message before sending any packets to the server.
Verification
Run the following tests, ensuring that there is coverage of old systems (e.g. 2008/2012) and newer systems (2019/2022). Verify that the encryption is doing what it should be doing using Wireshark.
Note that when coercing specific kerberos algorithms, you might need to clear the kerberos cache in between test cases. This is because of a separate bug, #19126
LDAP::Signingset toauto- KerberosLDAP::Signingset torequired- KerberosLDAP::Signingset toauto- NTLMLDAP::Signingset torequired- NTLMLDAP::Signingset torequired(when using NTLM or Kerberos) fails withbad-configLDAP::Signingset toauto(when using something other than NTLM or Kerberos) attempts to continue (it will fail against a Windows DC, but this is important for non-Windows LDAP servers)Demo
First a failing case (
LDAP::Signing = disabled):Then the happy path:
I've tested most of the test cases against Server 2008, Server 2012, Server 2022.