Skip to content

Errors with new LDAP parameters #20184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
smashery opened this issue May 14, 2025 · 0 comments
Open

Errors with new LDAP parameters #20184

smashery opened this issue May 14, 2025 · 0 comments
Labels

Comments

@smashery
Copy link
Contributor

I've seen a few issues with the new datastore parameter names for LDAP (LDAPPassword, LDAPUsername, LDAPDomain) created in #19606. While the modules accept the old values due to the fallbacks attribute, the modules' help files now tell users to set the new values; e.g.:

   Used when making a new connection via RHOSTS:

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   LDAPDomain                     no        The domain to authenticate to
   LDAPPassword                   no        The password to authenticate with
   LDAPUsername                   no        The username to authenticate with
   RHOSTS                         yes       The target KDC, see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
   RPORT         389              no        The target port

However, when setting these values directly in some modules, they don't work:

msf6 auxiliary(gather/asrep) > run rhost=20.248.208.9 ldapdomain=msf.local ldappassword=Pass123$ ldapusername=low.admin action=ldap tARGET_USER=low.admin
[*] Running module against 20.248.208.9
[-] Auxiliary aborted due to failure: bad-config: Must provide a username for connecting to LDAP
[*] Auxiliary module execution completed

Whereas it continues to work fine with the existing values:

msf6 auxiliary(gather/asrep) > run rhost=20.248.208.9 domain=msf.local password=Pass123$ username=low.admin action=ldap tARGET_USER=low.admin
[*] Running module against 20.248.208.9

$krb5asrep$23$low.admin@MSF.LOCAL:5968c1e0faa981a652f6e309...

This is because, while the mixins respect the new parameters, the modules themselves often still refer to the legacy versions (e.g. USERNAME, etc.).

We see the same issue when changing password:

msf6 auxiliary(admin/ldap/change_password) > run rhost=20.248.208.9 ldapdomain=msf.local ldappassword=Pass123% ldapusername=low.admin action=ldap tARGET_USER=low.admin new_password=Pass1234% action=CHANGE verbose=true
[*] Running module against 20.248.208.9
[-] Auxiliary aborted due to failure: bad-config: Must set USERNAME when changing password
[*] Auxiliary module execution completed

In the shadow credentials module, some niche error messages aren't shown as a result (e.g. "By default, only computer accounts can modify their own properties (not user accounts).")
The vmware_vcenter_vmdir_auth_bypass module uses datastore['username'] too, in what looks like an edge case exploitation path - I don't have a vulnerable version to check, but I'm pretty sure this should change as well.

The more complicated one is cve_2022_26923_certifried - this has both versions of the parameter (e.g. LDAPPassword and PASSWORD, etc.) in the options list. The module uses SMB as well as LDAP. I see other modules like get_naa_credentials have deregistered LDAP options when it would double up with another protocol. Would that be appropriate here - deregister all the ldap versions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

1 participant