Fix: auxiliary/kerberos_enumusers stops after first match

[layderv]

kerberos_enumusers stops after the first valid user:

[*] 192.168.1.2:88 - KDC_ERR_PREAUTH_REQUIRED - Additional pre-authentication required
[+] 192.168.1.2:88 - User: "us3r" is present
[-] Auxiliary failed: NoMethodError undefined method `id' for nil:NilClass
[-] Call stack:
[-]   /usr/share/metasploit-framework/modules/auxiliary/gather/kerberos_enumusers.rb:96:in `report_cred'
[-]   /usr/share/metasploit-framework/modules/auxiliary/gather/kerberos_enumusers.rb:77:in `block in run'
[-]   /usr/share/metasploit-framework/modules/auxiliary/gather/kerberos_enumusers.rb:65:in `each'
[-]   /usr/share/metasploit-framework/modules/auxiliary/gather/kerberos_enumusers.rb:65:in `run'
[*] Auxiliary module execution completed

and it stops there.

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• use gather/kerberos_enumusers
• Set options; make sure the target has at least one valid username that can be found, not at the end of the list USER_FILE
• Verify the module keeps running after the first user has been found
• Verify the module does NOT stop after the first user has been found

[bcoles]

For whoever reviews this PR: if this is a bug (likely), then the same code pattern should also be reviewed elsewhere.

# grep -rn "myworkspace\.id" modules/
modules/post/solaris/escalate/srsexec_readline.rb:99:      workspace_id: myworkspace.id,
modules/post/windows/escalate/golden_ticket.rb:189:        workspace_id: myworkspace.id)
modules/auxiliary/gather/xerox_pwd_extract.rb:161:      workspace_id: myworkspace.id,
modules/auxiliary/gather/kerberos_enumusers.rb:96:      workspace_id: myworkspace.id,
modules/auxiliary/gather/konica_minolta_pwd_extract.rb:232:      workspace_id: myworkspace.id,
modules/auxiliary/gather/xerox_workcentre_5xxx_ldap.rb:277:      workspace_id: myworkspace.id,
modules/auxiliary/gather/lansweeper_collector.rb:118:      workspace_id: myworkspace.id,
modules/auxiliary/analyze/jtr_mssql_fast.rb:100:    Metasploit::Credential::NonreplayableHash.joins(:cores).where(metasploit_credential_cores: { workspace_id: myworkspace.id }, jtr_format: ['mssql', 'mssql05', 'mssql12']).each do |hash|

For modules which use the Auxiliary::Report mixin, myworkspace_id is considered the "safe" approach to access myworkspace.id.

lib/msf/core/auxiliary/report.rb :

  # This method safely get the workspace ID. It handles if the db is not active
  #
  # @return [NilClass] if there is no DB connection
  # @return [Integer] the ID of the current Mdm::Workspace
  def myworkspace_id
    if framework.db.active
      myworkspace.id
    else
      nil
    end
  end

[layderv]

Thanks @bcoles - should I go ahead and modify the others as well?

[bcoles]

Thanks @bcoles - should I go ahead and modify the others as well?

If you like, but only for modules which use the Auxiliary::Report mixin.

Also, modules/auxiliary/analyze/jtr_mssql_fast.rb should be avoided, as it will conflict with existing open PRs.

If the use of myworkspace.id is a bug, then it may or may not also exist in these mixins:

# grep -rn "myworkspace\.id" lib/
lib/msf/core/auxiliary/brocade.rb:58:      workspace_id: myworkspace.id,
lib/msf/core/auxiliary/report.rb:84:      myworkspace.id
lib/msf/core/auxiliary/juniper.rb:33:      workspace_id: myworkspace.id,
lib/msf/core/auxiliary/juniper.rb:152:      workspace_id: myworkspace.id,
lib/msf/core/auxiliary/cisco.rb:42:      workspace_id: myworkspace.id,
lib/msf/core/db_export.rb:151:    @creds = Metasploit::Credential::Core.with_logins.with_public.with_private.workspace_id(myworkspace.id)

I'd prefer not to touch the libs unless this issue can be confirmed as a bug and tested to ensure no adverse effects.

[wvu]

Yes, myworkspace_id is the correct approach. Thank you!

[wvu]

Release Notes

This fixes several modules to use myworkspace_id instead of myworkspace.id, the former of which will check if the database is connected first, whereas the latter will crash if not connected.