Looks like we hit another bug involving variable scope in parameters passed down to run_simple via 'run_single'. Since 'run_single' doesn't actually even run a single invocation of a module, let's just unwind that function, and get the rest of the parameters passed down.
This also explicitly disables 'jobify' support for non-scanner aux modules with multiple targets, which I don't think we're ready for until we add the RHOSTS iteration to the module proper. Otherwise, we'll have an explosion of jobs in the current implementation.
Noted by @actuated, auxiliary/scanner/ipmi/ipmi_dumphashes was displaying an error when run against an IPMI endpoint that had a common hash. This was due to the services lookup in the database not extracting the first element of the results array.
```
[-] Auxiliary failed: NoMethodError undefined method `id' for #<Array:0x000055615614b970>
[-] Call stack:
[-] /home/bcook/projects/metasploit-framework/lib/metasploit/framework/data_service/proxy/credential_data_proxy.rb:27:in `block (2 levels) in create_cracked_credential'
[-] /home/bcook/.rvm/gems/ruby-2.6.1@metasploit-framework/gems/activerecord-4.2.11/lib/active_record/relation/delegation.rb:46:in `each'
[-] /home/bcook/.rvm/gems/ruby-2.6.1@metasploit-framework/gems/activerecord-4.2.11/lib/active_record/relation/delegation.rb:46:in `each'
[-] /home/bcook/projects/metasploit-framework/lib/metasploit/framework/data_service/proxy/credential_data_proxy.rb:25:in `block in create_cracked_credential'
[-] /home/bcook/projects/metasploit-framework/lib/metasploit/framework/data_service/proxy/core.rb:166:in `data_service_operation'
[-] /home/bcook/projects/metasploit-framework/lib/metasploit/framework/data_service/proxy/credential_data_proxy.rb:15:in `create_cracked_credential'
[-] /home/bcook/projects/metasploit-framework/lib/msf/core/auxiliary/report.rb:26:in `create_cracked_credential'
[-] /home/bcook/projects/metasploit-framework/modules/auxiliary/scanner/ipmi/ipmi_dumphashes.rb:317:in `report_cracked_cred'
[-] /home/bcook/projects/metasploit-framework/modules/auxiliary/scanner/ipmi/ipmi_dumphashes.rb:244:in `block (2 levels) in run_host'
[-] /home/bcook/projects/metasploit-framework/modules/auxiliary/scanner/ipmi/ipmi_dumphashes.rb:237:in `each'
[-] /home/bcook/projects/metasploit-framework/modules/auxiliary/scanner/ipmi/ipmi_dumphashes.rb:237:in `block in run_host'
[-] /home/bcook/projects/metasploit-framework/modules/auxiliary/scanner/ipmi/ipmi_dumphashes.rb💯in `each'
[-] /home/bcook/projects/metasploit-framework/modules/auxiliary/scanner/ipmi/ipmi_dumphashes.rb💯in `run_host'
[-] /home/bcook/projects/metasploit-framework/lib/msf/core/auxiliary/scanner.rb:111:in `block (2 levels) in run'
[-] /home/bcook/projects/metasploit-framework/lib/msf/core/thread_manager.rb:106:in `block in spawn'
[*] Auxiliary module execution completed
```
Peleus notes that when pulling more than a few RHOSTS targets from the database, MSF writes the intermediate results to a text file instead of leaving them in memory. The aux module check of instantiating a RangeWalker for validation is necessary but insufficient for validating 'file:' RHOSTS specifications.
This clones logic used in the 'check' method in exploit modules to be able to handle file: properly. I suspect this may need to be consolidated and implemented elsewhere tool.
This fixes a couple of bugs in #11176:
- RHOSTS is not always used in Aux modules, don't enforce it unless it's used.
- Be sure to pass the action to the run stub, since it's not a standard option.
Brendan Coles
William Vu
Brent Cook
Metasploit
Matthew Kienow
Clément Notin
Aaron Soto
Adam Cammack
Jeffrey Martin
Jacob Robles