-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJT0CeVAAoJEJMMBVMNnmqO/7AP/0CBRHjtgiR9VnFKSQ+iWTQV
iPNMBevn0mpSRq/gpoKCeFBZ6b+YQYrOLXDKVk62VV9LCslkr/P8LW8ul+m+JtB0
mM6V5esUXM1XhgGEyTnTLRx6BR/WQU1RHlb56ae3nZjQlwCuH/5zEmcy5toZxpsY
6HO46zE0GGBoLr/VgyYlfT08bfoQ+ICyJN0H5ixoovCc3iW0K1MNqLMfdani8zBJ
gYJaMysV7XtepumWWQMSC+b/EuertdXXzWDy2bwe0Q3cQXNXzrkPAvtMqucWG+gy
783OLKCPtVoEZiX87xAptkwmVCRdNGPclaWH7YRZDAh1tqBfRQUg72V/TIrOHCP1
/lYO7yp5pBQg+1UNnpH+xI2YePFfYdHpYDNT5FSQGOnQjJg30ll4SqCm7cVmo2h5
BRSYXkPCsQeXGaFarxGERNb8e+qN/WzSrHzY45tQw8mDuhg94tlf3VtDag3FXxhj
zCxd6bu+tdboVm7FERS85T46kxzmeIycZ4p+Sf7d8gXitl2RKbBdKFNDi1gzeK1T
yN7bDl4sL7qtDgZLXjFrnyC8vXyAqIrAgmFr2JywMBRm6TiCGQvgnrs+sScU3RFU
W2tblGbKQq+CwDeC59uQPqxRkm72SMUrKX9448VEQ+9XbKE3TMQ5Q4qCxmnw31Op
aJ0QgKJz8thZgafZc89I
=e1z9
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCgAGBQJT4pb8AAoJEA+Ckxyj7hsHn+8P/3FlEYCmoqQ/JzsVtmP3Yi4Q
gBRva+crY831mCCQXFrPJBvWfmy5HOzVh+Zh7zWF0GQ1WuuMppHfR5ARFVwmiDs3
qwndhXwziDzBnznf0JKSgT5eJsH23s/ots1lyWymKJvPuT6hn6MRAHUawgnNmYR9
ttnawmHvCM9Iha2oz3nmkLcNd+83bdBfEWi5l8AQ7jJxwMC2/8VPpMscVVwXqPzd
CoQugAYZW5VeaEiGio5+19Ix9EPkIDvs6wnfGBtfPfeaOIDZV4XOFoIFUtEeZd5o
olvEpYvdqscy4Qujzn4C++3wX3bUxkIbHTJHgrKmlD83dI7Cu1JH716G+yfLoJo0
pQBWTGeWYKEh6leK/9J5Bo1/tOJ/ylbcbvH0Y0tmdu4icHar6uYe1QBrCB9xIdh1
F+xo4guYnVo616DXJQSwjIye83b5dBxACrfA3bqCnFVFgTM5jXGV1cqiBgs9Dl++
tIDPgUJkCe/bIdQ7PntlGRzxKihHahlxhCa++YaGKqSq7gXie8Rl4qgloIrbfNZ/
z3XsoOLNdbMGO7ip88Zjwq4Khj5WZu7ijfCtXO7GU1UJZL1tJ2yK2ic7ZDLc251Y
8EGMSTG53+6yvZYFtWMZeQzjwD2cpuF04dOmHOKi6KGJJ7KRPhn6gpsbc6U1mbH9
AjGcfOzhhcsY+WAQ7OG+
=Pjob
-----END PGP SIGNATURE-----
Merge tag '2014072301' into staging/electro-release
Conflicts:
Gemfile.lock
modules/post/windows/gather/credentials/gpp.rb
This removes the active flag in the gpp.rb module. According to Lance,
the active flag is no longer used.
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.
Newer releases of File have a much different output when given a jar
file. Adjust regex per egyp7's suggestion to close bug 8792 on redmine.
Failure/Error: verify_bin_fingerprint(format_hash, bin)
expected: /zip/i
got: "/dev/stdin: Java archive data (JAR)\n" (using =~)
Tested and confirmed working with file 5.17 on Gentoo Linux.
SEERM #4821
while looking into what it would take to fix bug 4821, I found that there are no specs
for any of the other methods in command dispatcher. I have attempted to add stubs for a
few of the methods and tested a few of the help outputs.
[#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.
[#47979793]
[#48414569]
Even though using Timecop locally on OS X makes the `should == <Time>`
work, it fails on travis-ci, so try using `should
be_within(1.second).of(<Time>)` instead.
[#46491831]
The root element was web_page in the source for example that tests that
import_msf_web_vuln_element creates an Mdm::WebVuln. The root element
name did not actually matter for the example, but it looked like an
error and was confusing to read the setup that root element was web_page
instead of the correct web_vuln.
[#46491831]
Move Msf::DBManager#import_msf_xml into
Msf::DBManager::ImportMsfXml#import_msf_xml and include
Msf::DBManager::ImportMsfXml to cut down size of the infamous db.rb.
Break up #import_msf_xml to have separate methods for parsing web_forms,
web_pages, and web_vulns. The method for
web_vulns, #import_msf_web_vuln_element is needed so that it can be overridden in
Pro to handle the Pro-only changes to Mdm::WebVuln.
[Fixes#38426061, #38097411]
Msf::Modules::Loader::Directory#read_module_content may calculate a non-existent
module_path that gets passed to File.open causing an Errno::ENOENT exception
to be raised when using the module cache with a module that has been
moved to a new path (as is the case that originally found this bug) or
deleted. Now, the exception is rescued and read_module_content returns
an empty string (''), which load_module detects with
module_content.empty? and returns earlier without attempting to module
eval the (empty) content.
As having Msf::Modules::Loader::Directory#read_module_content rescue the
exception, meant there was another place that needed to log and error
and store an error in Msf::ModuleManager#module_load_error_by_path, I
refactored the error reporting to call
Msf::Modules::Loader::Base#load_error, which handles writing to the log
and setting the Hash, so the error reporting is consistent across the
loaders.
The exception hierarchy was also refactored so that
namespace_module.metasploit_class now has an error raising counter-part:
namespace_module.metasploit_class! that can be used with
Msf::Modules::Loader::Base#load_error as it requires an exception, and
not just a string so the exception class, message, and backtrace can be
logged.
Msf::Modules::Loader::Archive#each_module_reference_name tried to check
the enabled types for the module_manager by accessing the
enabledment_by_type Hash, which is protected. Instead, it should use
the public type_enabled? method.
Add specs to test all of Msf::Modules::Loader::Archive while testing
each_module_reference_name. In order to properly test that modules
could be found in archives, I had to produce a fastlib archive, so there
is now a spec for FastLib.dump and FastLib.load. Some specs are marked
pending as I found a bug in FastLib, which has a work-around. The bug
is filed in PivotalTracker as
https://www.pivotaltracker.com/story/show/38730815 and the pending tests
include the URL also in their tags.
[Fixes#37630057]
Modules were always being detected as having file changes because the
parent_path directory, instead of the actual module_path, was being
passed to module_manager.file_changed?, which caused the modification
times to not match.
To ensure this change fixes the ambiguous module warnings, a full spec
for Msf::Core::Modules::Loader::Base has been written.
spec/msf has moved to spec/lib/msf to match conventional spec layout and
allow for the spec/support directory to not be confused as a lib
subdirectory being tested.
Brandon Turner
darkbushido
David Maloney
James Lee
HD Moore
Lance Sanchez
Luke Imhoff
navs
Rick Farina (Zero_Chaos)
Timothy Swartz
sinn3r
Tab Assassin
Meatballs
William Vu