Metasploit::Credential::Core#to_credential will set the parent to the original core objext
Metasploit::Framework::Credential#to_credential also sets the parent to itself.
This is more like the behavior of the old AuthBrute mixin, where a
scanner module was expected to return :next_user in the block given to
each_user_pass when it successfully authenticated.
The advantage is a reduced number of attempts that are very unlikely to
be successful since we already know the password. However, note that
since we don't compare realms, this will cause a false negative in the
rare case where the same username exists with different realms on the
same service.
MSP-10686
made the one true enumerator of credentials
for the login_scanner.
also covered the wierd http case where it can have a realm key
but no default realm.
Metasploit::Framework::Credential and Metasploit::Credential::Core
need to be consumable by the login scanners. the easiest way to do this
was to create a shared to_credential method on both that return Metasploit::Framework::Credential
MSP-9912
* Genericizes HTTP a bit to make these kinds of HTTP-based scanners
simpler and easier
* Adds support for default ports to HTTP. This should probably be
rafactored up into Base
* Removes spec that complains about port being unset (which now fails
because defaults ensure it's always set)
MSP-9606
In order to support Metasploit::Credential correctly,
metasploit-framework needs to support Metasploit::Concern, which does
all its magic using a Rails::Engine initializer, so the easiest path is
to make metasploit-framework be able to use Rails::Engines. To make
Rails::Engine use Rails::Engine, make a dummy Rails::Application
subclass so that all the initializers will be run when anything requires
msfenv.
[#47720609]
Msf::PayloadSet#add_module does NOT return an annotated module class as
Msf::ModuleSet#add_module does because a payload module is defined as a
ruby Module instead of a ruby Class. Since add_module doesn't always
return an annotated_class, the logic in
Msf::ModuleManager#on_module_load needed to change to NOT use
annotated_class and create #add_module as return [void]. Thus, it is
necessary to pass in all the metasploit module metadata to
Msf::ModuleManager#cache_in_memory instead of assuming they can be
derived from the (payload) Module or (other) Class.
[#47720609]
Msf::ModuleManager#module_info_by_path was not being updated when a
module was loaded, so if a load_module was called again, say during
start up of prosvc, the module would reload even though there was no
change in the file because file_changed? couldn't find an entry for the
module's path in module_info_by_path.
[#47720609]
Fix some docs and variable names to make it clearer when methods are
expecting module instance and module classes. Change some 'name'
variables to 'reference_name' since that's the proper terminology.
[#50179803]
[SeeRM #7967]
[SeeRM #7870]
Because metasploit-framework runs migrations with the same process and
with the same connection as it later accesses the database, the column
information can become cached prematurely and be incorrect by the end of
the migrations. Fix the bad cache by automatically resetting the column
information for all model classes after the migrations have run.
[#50179803]
Move Msf::DBManager#migrate and the migrated attribute to
Msf::DBManager::Migration module to lower complexity of db_manager.rb
and in preparation for more migration related code on this branch.
[#49858419]
[SEERM #7958]
metasploit_data_models 0.14.3 relaxes the validation on
Mdm::Module::Detail#stance so it only needs to be in
Mdm::Module::Detail::STANCES if Mdm::Module::Detail#mtype is 'auxiliary'
or 'exploit' as framework only supplies a stance for those types when
using Mdm::Module::Detail.
darkbushido