Update reg checks when DC and CA are separate #20563
Conversation
|
|
||
| @registry_values | ||
| rescue StandardError => e | ||
| vprint_warning("Failed to query registry values: #{e.message}") |
There was a problem hiding this comment.
While testing, I noticed that for some reason, whenever there's failure anywhere in this function, it will return the error message and the following code might loudly (for example, when DNS query fails):
[-] Auxiliary failed: TypeError no implicit conversion of Symbol into Integer
[-] Call stack:
[-] /home/ms/git/metasploit-framework/modules/auxiliary/gather/ldap_esc_vulnerable_cert_finder.rb:1082:in `[]'
[-] /home/ms/git/metasploit-framework/modules/auxiliary/gather/ldap_esc_vulnerable_cert_finder.rb:1082:in `block in run'
[-] /home/ms/.rvm/gems/ruby-3.2.5/gems/net-ldap-0.19.0/lib/net/ldap.rb:646:in `block in open'
[-] /home/ms/.rvm/gems/ruby-3.2.5/gems/net-ldap-0.19.0/lib/net/ldap.rb:718:in `block in open'
[-] /home/ms/.rvm/gems/ruby-3.2.5/gems/net-ldap-0.19.0/lib/net/ldap/instrumentation.rb:19:in `instrument'
[-] /home/ms/.rvm/gems/ruby-3.2.5/gems/net-ldap-0.19.0/lib/net/ldap.rb:713:in `open'
[-] /home/ms/.rvm/gems/ruby-3.2.5/gems/net-ldap-0.19.0/lib/net/ldap.rb:646:in `open'
[-] /home/ms/git/metasploit-framework/lib/msf/core/exploit/remote/ldap.rb:147:in `ldap_open'
[-] /home/ms/git/metasploit-framework/lib/msf/core/optional_session/ldap.rb:53:in `ldap_connect'
[-] /home/ms/git/metasploit-framework/modules/auxiliary/gather/ldap_esc_vulnerable_cert_finder.rb:1048:in `run'
[*] Auxiliary module execution completed
| vprint_warning("Failed to query registry values: #{e.message}") | |
| vprint_warning("Failed to query registry values: #{e.message}") | |
| return |
There was a problem hiding this comment.
same error i am also facing i think it might be error in modules some is missing by our side let me try it again and i will help you out here brother.
| end | ||
| end | ||
|
|
||
| ca_entry = ca_servers.find { |ca| ca[:name].casecmp?(datastore['CA']) } |
There was a problem hiding this comment.
Would it make sense to have possibility to query all CAs? I'm not sure how many there can be and if it makes sense, but I'm thinking if it is possible, some users might wanna have all information rather than individually select each CA.
There was a problem hiding this comment.
I was also wondering about this. Based on my understanding from the second paragraph of your PR description, it seems like we should be checking each CA server so we can identify when one or more may be vulnerable. I'd probably want to see the certificate template not marked with the technique if all CA servers don't have the applicable configuration. If one or more do though, marking the template as vulnerable then maybe noting the server's with the necessary misconfiguration in the notes would be helpful.
There was a problem hiding this comment.
That absolutely makes sense. Thanks for bringing that up. I think I've made the necessary changes and have documented the testing in this comment here: #20563 (comment)
Please let me know if you have any comments or suggestions
jheysel-r7
force-pushed
the
fix/mod/ldap_esc/ca_reg_values
branch
from
a076a04 to
74d229e
Compare
ldap_esc_vulnerable_cert_finderNow each CA in the domain is queried for their The other two registry keys that affect template exploitability ( The certificate template named: The certificate template name The notes section indicates which CA will issue the misconfigured template. esc_update_ldap_objectThe esc_update_ldap_object now also properly accounts for the possibility of their being multiple separate Certificate Authorities by resolving the CA IP and updating the LDAP objects on the domain controller before requesting the certificate from the CA. Note the It should read: As it's contacting the CA not the DC for the cert. I think I might change that. Ensuring everything works when DC and CA on same server:ldap_vulnerable_cert_finder: Note currently the Scenario 1 and 2 for esc16 are separated by and elsif so we only report 1 in the event both are true to avoid having duplicate ESC16 entries in the notes. That could be fixed. esc_update_ldap_object working with DC and CA on the same server: |
Release NotesThe |
5 participants
Originally when the
RUN_REGISTRY_CHECKSdatastore option was added to theldap_esc_vulnerable_cert_findermodule, the module would only check the registry of the Domain Controller defined in therhostvalue. This provides incorrect results in cases where the Certificate Authority is installed on a server separate from the Domain Controller.If the two systems are separated, the Domain Controller will hold:
StrongCertificateBindingEnforcementregistry valueCertificateMappingMethodsregistry valueAnd the Certificate Authority will hold:
DisableExtensionListregistry valueEditFlagsregistry valueIf the CA is installed on the DC then all the info needed resides on the DC. To solve the issue when they are separate the module now requires the user to define the datastore option
CA( just like theicpr_certmodule) whenRUN_REGISTRY_CHECKSis set to true. The module reaches out to the DC via LDAP and a newadds_get_ca_serversmethod which returns a list of containing thenameanddnshostnameof all the CA servers connected to the DC. Then thednshostnameof all the CA's are resolved and then using the same credentials, a WMI connection is established and the registry keys are pulled from each CA.Verification
Installed on the same system:
msfconsoleuse auxiliary/gather/ldap_esc_vulnerable_cert_finderset RUN_REGISTRY_CHECKS trueset CA msflab-DC-CAInstalled separately:
msfconsoleuse auxiliary/gather/ldap_esc_vulnerable_cert_finderset RUN_REGISTRY_CHECKS trueset CA msflab-CA-CAExample output when testing a CA installed on a machine separate from the DC: