NTLM support for the LDAP capture capabilities

[JustAnda7]

This PR is a follow up to #18125

This PR aims to increase the scope of capturing authentication details from LDAP clients by supporting NTLM Authentication.

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• use auxiliary/server/capture/ldap
• Set the SRVHOST,SRVPORT if required.
• Change the CHALLENGE to another value if necessary
• Verify the working of the feature using NTLM Authentication.
• Verify that the credentials are stored in the database appropriately

Note Points

• This was observed on Metasploit v6.2.
• Additional testing is required to ensure the handling of various cases of Authentication. (Would like some suggestions on testing)

[jmartin-tech]

Some notes from GSoC sync conversations:

Desired adjustments:

Shift Auth code into Rex::Proto::LDAP::Auth
* Add specs for PDU processing and return class with a type that offers context of auth type

Server class refactor to allow registration/filter of callback based on PDU type
* This could be expanded to allow for multiple modules to listen on LDAP service
* This could enable adding filtering criteria for when the callback should be passed to capture
or some other module that is listening for other specific reasons.

Idea for future processing, allow capture module to be configured for specific response patterns for bind (not required)

Possible configurations to support:
* ResultCodeSuccess to all cases
* ResultCodeInvalidCredentials - No Anonymous Auth
* Mixed ResultCodeSuccess to Anonymous and ResultCodeInvalidCredentials all others
* Random ResultCodeSuccess to Anonymous and random success/failure reasons for others

[jmartin-tech]

As discussed previously, the implementation here for #on_dispatch_request() can be pushed down into the LDAP server as default functionality and the authentication processing can then become shared capability provided by the LDAP server class.

Authentication processing looks to be directly related to a BindRequest PDU and a parser and processor for these request can return an object that the service would use to determine the "credential" data to be stored.

Consider this means that each method in the server class need to be scoped to be independent of Framework output helpers like print_status or those helpers need to be injected into the server object.

[jmartin-tech]

Thanks for the updated revisions, I added some comments about possible utilization of Net::NTLM::Message::* classes for parsing the messages instead of implementing parser methods in Auth. (This is optional but I think will reduce the code required significantly.)

This PR will need rspec for Rex::Proto::LDAP::Server and Rex::Proto::LDAP::Auth at a minimum.

[jmartin-tech]

Check the type on auth_provider, might be even better to raise an ArgumentError when value is not nil and not of type Rex::Proto::LDAP::Auth.

[JustAnda7]

Any further changes required ?

[jmartin-tech]

Testing shows this is working well for simple auth with the revision to capture/ldap.rb regarding :post_pdu , however NTLM auth does not succeed.

With all the changes I am suggesting to evaluate mechanism during SASL auth attempts ldapsearch expectations still result in a decode error:

$ ldapsearch -H ldap://server.example.com -Y ntlm -U admin -b 'dc=server,dc=example,dc=com'
SASL/NTLM authentication started
ldap_sasl_interactive_bind: Decoding error (-4)
        additional info: SASL(-5): bad protocol / cancel: server didn't issue valid NTLM challenge

Digging into the type2 message generated in Ruby seems to be valid so I suspect something is not quite right in the serialization for the Net::LDAP::PDU::BindResult being returned to ldapsearch.

[jmartin-tech]

@JustAnda7 I have posted a PR that resolves the issues I had in testing. I will hold off a couple days for you to test if you would like to. After that if not already merged, I will merge directly here so I can land this release the new functionality for upstream.

[JustAnda7]

I have merged the PR. You can go ahead and land the branch on upstream. So far I think it works well and good.

[jmartin-tech]

Just a note, this option is not used by the implementation.

Looking at where it came from, I suspect this is from intention to mimic http_nltm behavior. For now I will just remove this options during land of this PR.

[jmartin-tech]

Release Notes

This PR adds support for LDAP capture of NTLM authentication and adds a default implementation for LDAP BindRequest, SearchRequest, UnbindRequest, as well as a default action for unsupported requests.