bruteforce_speed isn't always required, because the speed checker
already handles nil (and presumes the user wants the fastest possible).
See also MSP-11842
This implements just for telnet, but assuming this strategy is kosher,
it's not too painful to add for the rest of the LoginScanner using the
old defaults used by `AuthBrute`.
See #3904, @dmaloney-r7 or @jlee-r7
MSP-11671
Add command line option --defer-module-loads to msfconsole. It will
stop `Msf::Ui::Console::Driver` from calling
`framework.modules.init_module_paths` AND
`framework.modules.refresh_cache_from_database`. This flag is only
meant to speed up msfconsole boot when modules do not need to accessed,
such as during cucumber testing of command help or command line options.
MSP-11147
Sometime travis-ci is showing leaked threads even when
'Msf::Framework#threads cleaner' is being used, so I'm adding the
`Thread#status` to the data printed about the Thread to see if the
sometimes leaked threads have an odd status. There's still a chance
that there will be a race-condition between when I call Thread.list and
I ask for each Thread's status that the VM could finish aborting a
Thread so that status I print isn't the same as the one that caused the
Thread to be returned in Thread.list.
MSP-11605
`Rex::ThreadFactory.provider` needs to be set in
`Msf::Framework#initialize`, but setting it directly to
`Msf::Framework#threads` eliminates the laziness of
`Msf::Framework#threads`. In order keep `framework.threads` lazy,
`framework` is wrapped in a
`Metasploit::Framework::ThreadFactoryProvider`, which responds to
`spawn`, which is needed by `Rex::ThreadFactory`, by calling
`framework.threads.spawn`, which lazily initialized `framework.threads`
when the first thread needs to be spawned.
MSP-11147
When using Rubymine's debugger, the tests would run and say there were
no tests and no break points would be hit. It was determined that this
was due the Rubymine's debugger injecting itself into RUBYOPTS and only
working if it's first in RUBYOPT, which means that
'metasploit:framework:spec:threads:suite' must inject '-Ilib
-rmetasploit/framework/spec/threads/logger' at the end of RUBOPT instead
of the beginning.
This change adds two new Rex exceptions and changes the local comm to raise the right one depending on the circumstances. The problem with the existing model is
that failed binds and failed connections both raised the same exception. This change is backwards compatible with modules that rescue Rex::AddressInUse in additi
on to Rex::ConnectionError. There were two corner cases that rescued Rex::AddressInUse specifically:
1. The 'r'-services mixin and modules caught the old exception when handling bind errors. These have been updated to use BindFailed
2. The meterpreter client had a catch for the old exception when the socket reports a bad destination (usually a network connection dropped). This has been updat
ed to use InvalidDestination as that was the intention prior to this change.
Since AddressInUse was part of ConnectionError, modules and mixins which caught both in the same rescue have been updated to just catch ConnectionError.
Have 'metasploit/framework/spec/threads/suite/logger' generate a UUID
for each Thread. This UUID is printed on the "BEGIN Thread.new caller"
line and is assigned as a thread-local variable,
'metasploit/framework/spec/threads/logger/uuid'. In `after(:suite)`,
the log can be parsed to map the caller back to each UUID and then only
the UUID of the still existing threads is used to look up the caller and
print their stacktraces. This means only leaked threads callers will be
printed.
MSP-11147
Even with leaked threads, there may be no log if the suite is run
without `rake spec`, such as when `rspec` is used directly to run a
subset of specs.
MSP-11147
Merge to get framework instance cleanup, which should clean up a lot of
thread leaks too.
Conflicts:
Rakefile
lib/metasploit/framework/spec.rb
spec/spec_helper.rb
MSP-11147
Detect thread leaks in a `before(:suite)` configured by
`Metasploit::Framework::Spec::Threads::Suite.configure!` and fail if any
leaks are found.
By putting the db group into the metasploit-framework-db.gemspec,
bundler no longer automatically required 'metasploit/credential' and
'metasploit_data_models' because gems, such as metasploit-framework-db,
are expected to explictly require their dependencies.
MSP-11130
Have a task, 'metasploit:framework:spec:constants:each:clean' run before
`rake spec` that removes the previous
`log/metasploit/framework/spec/constants/each.log` so that the user doesn't
have to manually remove the load when removing
`Metasploit::Framework::Spec::Constants::Each.configure!` from
`spec/spec_helper.rb`.
MSP-11130
Instead of writing `1` to the file and then printing a verbose message
in the spec task action, log the verbose message and just print the log
in the spec task action, so other tools can just look at the log when
not using `rake spec`.
NOTE: Failing specs due to unnecessary
`Metasploit::Framework::Spec::Constants::Each.configure!`
MSP-11130
When removing `Metasploit::Framework::Spec::Constants::Each.configure`
from spec/spec_helper.rb,
`Metasploit::Framework::Spec::Constants::Each.define_task` will see the
`log/remove-cleaner` from the last run unless it is manually removed.
MSP-11130
Some constants can be leaked before suite if module are loaded during
spec loading, such as if a framework instance in made in the context
body of a spec instead of in a before callback.
MSP-11130
Print to stderr the full description of the example when
`Metasploit::Framework::Spec::Constants.configure!`'s `before(:each)`
cleans constants as it may clean constants that are leaked from the
class level at parse time.
MSP-11130
Fail `rake spec` if
`Metasploit::Framework::Spec::Constants::Each.configure!`'s
`before(:each)` does not clean all leaked constants and if should be
removed so that it does not interefore with future specs.
MSP-11130
`Metasploit::Framework::Spec::Constants::Each.configure!` will set up an
`after(:each)` callback that will fail the example if there are leaked
constants. Leaked constants are cleaned up to prevent misattribution.
MSP-11130
`Metasploit::Framework::Spec::Constants::Suite` extracts out
`LOG_PATHNAME`, `configure!`, and `define_task` as those piece are
specific to handling constant leaks for the entire suite. This is in
preparation for `Metasploit::Framework::Spec::Constants::Each`.
MSP-11130
Constants from library Modules or Classes should not be reported as
leaked since they have been required and should be persistent between
spec runs.
MSP-11130
Extract method to convert child constant names to module full names so
it can be reused 'Metasploit::Framework::Spec::Constants tracker' shared
context.
MSP-11130
Instead of printing the leaked constants to stderr, log them to
`log/leaked-constants.log`. In task action for spec, read
`log/leaked-constants.log`. If it exists, print each leaked constants
(and it appropriate it's module full name) and then exit with 1. If the
file does not exist, do nothing.
MSP-11145
**NOTE: Failing specs**
Add a tool for reading `log/untested-payload.log` and
`framework.payloads` to determine `context`s to add
`spec/modules/payloads_spec.rb` to test the untested payloads.
MSP-11145
Extract the spec task action which errored out if
`log/untested-payloads.log` exists to
`Metasploit::Framework::Spec::UntestedPayloads.define_task`.
This commit contains three fixes as requested on PR
#4003. Those include:
+ Removing extraneous puts statement
+ Checking for valid response
+ SSL support.
Sometimes msfconsole takes a little while to start.
This adds a fairly common ASCII spinner to the startup sequence.
I haven't spec'ed it, and the code organization isn't great, so consider
this PR more of a cry for help than something immediately landable.
That said, it works for me.
Previous code was not using any sort of exception handling
for parsing the response body. I have added a rescue block
for JSON errors to remedy this problem.
I have added a login scanner for the Buffalo Linkstation
NAS. I have been testing against version 1.68 of the
firmware. Also included are some specs for this module.
The previous commits for this Jenkins CI module relied on an
obsolete pattern. Consequently, it was necessary to write
this module as a LoginScanner and incorporate the appropriate
specs so that the tests will run properly.
if the initial connection from the SMB LoginScanner fails
it wouldn't set the target information on the result. this could cause
smb_login to throw a stack trace when it calls invalidate_login
MSP-11343
This means we don't bomb out with an unhandled exception, instead
continuing attempting logins against the host even though it will never
succeed. Next up: verify state before running scan!()
MSP-11153
Restore the config/database.yml backed up to
config/database.yml.cucumber.bak in the db:config:restore task, which is
made a dependency of the environment rake task so that
config/database.yml is restored before Rails tries to use it in the
environment task. This specifically, allows for rake cucumber to be
interrupted when the config/database.yml has been moved to
config/database.yml.cucumber.bak and a subsequence rake cucumber to
succeed and restore config/database.yml, but any task that depends on
environment will restore the config/database.yml.
MSP-11153
Test the following paths in order and only return them if the path
exists:
1. MSF_DATABASE_CONFIG environment variable
2. ~/.msf4/database.yml
3. <project>/config/database.yml
add loginscanner class for IPBoard with specs
this should replicate the functionality originally written
by Chris Truncer, but move it into a testable, reusable class
On August 15, shuckins-r7 merged the Metasploit 4.10.0 branch
(staging/electro-release) into master. Rather than merging with
history, he squashed all history into two commits (see
149c3ecc63 and
82760bf5b3).
We want to preserve history (for things like git blame, git log, etc.).
So on August 22, we reverted the commits above (see
19ba7772f3).
This merge commit merges the staging/electro-release branch
(62b81d6814) into master
(48f0743d1b). It ensures that any changes
committed to master since the original squashed merge are retained.
As a side effect, you may see this merge commit in history/blame for the
time period between August 15 and August 22.
this works fine when calling any framework binaries
from their path as CWD. if you call tehm from another path
you will get an incorrect root which can cause certain things to load
incorrectly
Signed-off-by: David Maloney <DMaloney@rapid7.com>
MSP-11046
`ActiveSupport::OrderedOptions` automatically create an attribute for
any missing keys, so when `options.console.resource` was used it would
return `nil` instead of the erroring. The correct option name was
`options.console.resources` (note the pluralization).
MSP-10998
It's compacting of the version parts into a single float doesn't work
with APIMinor over 10, so replace with Gem::Version, which compares
parts correctly.
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.
MSP-10905
`Metasplot::Framework::Require.optionally` can be used to optionally
require a library and then issue a warning if the require fails or run a
block when it succeeds.
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
the only scenario in our final else that
would have a realm in the credential is the
http case in which case we want the realm to be there
still. otherwise the credential in this case has no
realm anyways so there is no need to strip one off
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