You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. LDAPPasswordandPASSWORD, 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?
The text was updated successfully, but these errors were encountered:
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.:However, when setting these values directly in some modules, they don't work:
Whereas it continues to work fine with the existing values:
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:
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 usesdatastore['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
andPASSWORD
, etc.) in theoptions
list. The module uses SMB as well as LDAP. I see other modules likeget_naa_credentials
have deregistered LDAP options when it would double up with another protocol. Would that be appropriate here - deregister all theldap
versions?The text was updated successfully, but these errors were encountered: