LDAPS Channel Binding for NTLM and Kerberos

[zeroSteiner]

Background

In 2020, Microsoft started adding options to harden the conifugraiton of LDAP on AD DS servers (domain controllers). These settings included channel binding and signing requirements. Microsoft posted an article here with additional details.

This pull request adds channel binding information to Metasploit's NTLM and Kerberos authentication for the LDAP protocol. This enables users to authenticate to domain controllers where the hardened security configuration setting is in place (LdapEnforceChannelBinding = 2). Prior to these changes, when a user attempted to authenticate to an LDAPS service where channel binding was required, the authentication attempt would fail with an error that the credentials were invalid. This error is of course misleading because the credentials are correct, but authentication failed for other reasons. With these changes in place, the authenticaiton will succeed without any additional changes from the user.

Implementation

The channel binding is the MD5 hash of the gss_channel_bindings_struct which itself includes a hash of the peer's TLS certificate. The hashing algorithm of the peer's certificiate is "almost always SHA256" but can be different in certain scenarios as described here. The channel binding token is the same for NTLM and for Kerberos, however it's placed in different locations of the negotiation frames. For NTLM it's an additional AV_PAIR structure, while for Kerberos, it's included in the checksum field of the AP-REQ structure.

The actual authentication logic was moved into dedicated adapter classes, which register themselves with the Net::LDAP library as rex_ntlm and rex_kerberos. This cleans up the code a bit, makes it reusable but most importantly is necessary to expose the connections #peer_cert for the channel bindings.

This PR also adds some updates to the error handling for a few of the LDAP modules to avoid stack traces for various connection related errors.

Testing Steps

• [x] Set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding registry setting to 2 for "Always"
  • At this point, authentication should fail when targing the domain controller over LDAPS (RPORT=636 and SSL=true)
• [x] Use a module that performs LDAP authentication such as auxiliary/gather/ldap_query
• [x] Set the generic options as appropriate (RHOSTS, USERNAME, PASSWORD, DOMAIN)
• [x] Test the module still works with LDAP and NTLM authentication (run LDAP::Auth=ntlm RPORT=389 SSL=false)
• [x] Test the module works with LDAPS and NTLM authentication with channel binding (run LDAP::Auth=ntlm RPORT=636 SSL=true)
• [x] Test the module still works with LDAP and Kerberos authentication (run LDAP::Auth=kerberos RPORT=389 SSL=false)
• [x] Test the module works with LDAPS and Kerberos authentication with channel binding (run LDAP::Auth=kerberos RPORT=636 SSL=true)

References

The following are various resources that were valuable references while implementing these changes.

• https://support.microsoft.com/en-gb/topic/2020-2023-and-2024-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a
• https://github.com/WinRb/rubyntlm/blob/master/lib/net/ntlm/channel_binding.rb
• https://www.rfc-editor.org/rfc/rfc1964.html
• https://github.com/cannatag/ldap3/pull/1087
• https://github.com/diyan/pywinrm/issues/161
• https://twitter.com/HackAndDo/status/1422220593668280323
• https://learn.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication

[Neustradamus]

To follow!

[adfoster-r7]

It's a shame we can't add this to our automated ldap/samba tests - https://wiki.samba.org/index.php/Configuring_LDAP_over_SSL_(LDAPS)_on_a_Samba_AD_DC

Samba doesn't implement LDAP Channel binding as required by the 2020 LDAP channel binding and LDAP signing requirements for Windows. Instead, in 2016 with CVE-2016-2112 we recognised the with no cryptographic connection between the NTLM response or Kerberos token and the TLS layer, that a relay attack was possible.

Samba has chosen to simply deny such sessions by default.

[zeroSteiner]

Marked this as blocked because I think we'll want to land #19127 which will create conflicts. At that point, I'll rebase this work on top of those changes.

[zeroSteiner]

I ran through all the combinations I could think of using this resource script against a DC which required signing and channel binding. Everything I expected to work did work. Cases that failed were expected to fail for the following reasons:

• Anytime the authentication is set to plaintext or schannel, authentication will fail because neither signing nor channel binding work with those authentication mechanisms
• LDAP::Signing=required and SSL=true fails because you can't sign an LDAPS connection to AD DS, the domain controller will reject it
• LDAP::Signing=disabled fails because the server is configured to require signatures, at this time channel binding can't be disabled through a datastore option in the same way but maybe a LDAP::ChannelBinding option would be a good idea

ldap_test.rc

``` run LDAP::Auth=plaintext LDAP::Signing=disabled RPORT=389 SSL=false run LDAP::Auth=plaintext LDAP::Signing=disabled RPORT=636 SSL=true run LDAP::Auth=plaintext LDAP::Signing=auto RPORT=389 SSL=false run LDAP::Auth=plaintext LDAP::Signing=auto RPORT=636 SSL=true run LDAP::Auth=plaintext LDAP::Signing=required RPORT=389 SSL=false run LDAP::Auth=plaintext LDAP::Signing=required RPORT=636 SSL=true run LDAP::Auth=kerberos LDAP::Signing=disabled RPORT=389 SSL=false run LDAP::Auth=kerberos LDAP::Signing=disabled RPORT=636 SSL=true run LDAP::Auth=kerberos LDAP::Signing=auto RPORT=389 SSL=false run LDAP::Auth=kerberos LDAP::Signing=auto RPORT=636 SSL=true run LDAP::Auth=kerberos LDAP::Signing=required RPORT=389 SSL=false run LDAP::Auth=kerberos LDAP::Signing=required RPORT=636 SSL=true run LDAP::Auth=ntlm LDAP::Signing=disabled RPORT=389 SSL=false run LDAP::Auth=ntlm LDAP::Signing=disabled RPORT=636 SSL=true run LDAP::Auth=ntlm LDAP::Signing=auto RPORT=389 SSL=false run LDAP::Auth=ntlm LDAP::Signing=auto RPORT=636 SSL=true run LDAP::Auth=ntlm LDAP::Signing=required RPORT=389 SSL=false run LDAP::Auth=ntlm LDAP::Signing=required RPORT=636 SSL=true ```

[jheysel-r7]

Release Notes

Add channel binding information to Metasploit's NTLM and Kerberos authentication for the LDAP protocol. This enables users to authenticate to domain controllers where the hardened security configuration setting is in place