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-11669
Set output stream for RbReadline (rl_outstream) to the
Rex::Ui::Text::Output::Stdio, which will use translate the ANSI color
escapes to set_color calls in Windows.
Auxiiary modules already do this, but looks like we forgot to do the
same for post modules.
I also changed the error to allow "reason" in order to be more
informative about what the user should do.
Fix#4307
Rename UDP_SECRET to just SECRET, as it is used for more than just UDP
Rename and properly document GATEWAY option
Introduce an option to configure what UDP port will be probed
If the user supplies an invalid session (as in not on the session
list), it will cause a backtrace, because the setup method from
Msf::PostMixin isn't actually called.
We have thought about implementing this in a new OptSession instead.
But you can't use or even pass framework to option_container.rb, so
this is NOT possible.
The original PR was #3956.
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-11672
Pass `'DeferModuleLoads' => false` to `Msf::Simple::Framework.create` so
that `framework.modules.init_module_paths` is only called once (directly
in `Msf::Ui::Console::Driver#initialize`) instead of twice (in
`Msf::Simple::Framework.create` and `Msf::Ui::Console::Driver#initialize).
MSP-11672
Calling init_module_paths takes 6 seconds on my machine even when there are no
files to that are changed just because it takes that long to walk the
directories and gather the mtime for each file. Therefore, calling it
more than once should be avoided. Also, there is no reason to call it
twice as to add paths later, `modules.add_module_paths` should be used.
This allows HandlerSSLCert to be used to pass a SSL certificate into the Meterpreter handler. The datastore has to be passed into handle_connection() for this to work, as SSL needs to be initialized on Session.new. This still doesn't pass the datastore into Meterpreter directly, but allows the Session::Meterpreter code to extract and pass down the :ssl_cert option if it was specified. This also fixes SSL certificate caching by expiring the cached cert from the class variables if the configuration has changed. A final change is to create a new SSL SessionID for each connection versus reusing the SSL context, which is incorrect and may lead to problems in the future (if not already).
This change emulates the auto-generated snakeoil certificate from Ubuntu 14.04. The main changes including moving to 2048-bit RSA, SHA256, a single name CN for subject/issuer, and the removal of most certificate extensions.
Note that this does not apply to reverse_tcp meterpreter clients yet, as
they do not allow certificates to be supplied. I abstracted out the SSL
certificate generation and parsing methods so that we can address this
next.
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.
The exploit works with the URLs fixed, installs the APK, but hangs at the Installing...
screen and never actually launches. We tried opening the APK in a setTimeout() intent
URI, but the previously launched intent seemed unresponsive. Andre had the bright
idea of re-opening the previously launched intent with invalid args, crashing it and
allow us to launch the payload.
MSP-11614
`Msf::TaskManager` was only used for `Msf::DBManager#sink`, which was
removed because it was unused, so `Msf::TaskManager` can also be
removed.
MSP-11614
`Msf::DBManager::Sink` contains code for a `sink` that is a meant to
serialize database events, but it's unneeded because all database events
go directly through ActiveRecord, which handles threading.
MSP-11605
`Msf::Framework#threads?` returns whether `Msf::Framework#threads` was
ever initialized. If `Msf::Framework#threads?` is true, then threads
need to be cleaned up, while if it is false then no threads need to be
cleaned up from the current framework.
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-11605
Switch `Msf:Framework#db` from being set in `#initialize` to a custom
method that uses `||=` to lazily initialize the `Msf::DBManager` inside
a `synchronize` block to make it thread safe.
MSP-11605
Store options `Hash` passed to `Msf::Framework#new` in `#options` so
that lazily initialized children, such as DBManager, have access to
those options.
MSP-11605
Switch `Msf::Framework#sessions` from being set in `#initialize` to a
custom method that uses `||=` to lazily initialize the
`Msf::SessionManager` inside a `synchronize` block to make it thread
safe.
#4184
* Appears to have been overlooked somehow in the pre-BlackHat crunch
* V5 will not support credentials
* We are implementing full-workspace zip import/export for credentials
MSP-11605
Switch Msf::Framework#threads to a custom method that uses `||=` to
lazily initialize the `Msf::ThreadManager` inside a `synchronize` block
to make it thread safe.
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.
The merge_check_key method (found in Msf::Module::ModuleInfo)) uses
respond_to? to check is our object includes a merge_info_description
method before merging descriptions. The respond_to? method in 2.1.4
by default no longer checks private and protected methods, and this
is breaking our merge_check_key method.
Fix#4163
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.
This will fix issue #4119. A bug in the find_first method in rex
SMB.
When the SMB client requests a TRANS2_FIND_FIRST2 for retriving
information about what items a directory has, the server returns
a response that contains an SID - a search identifier for the
transaction. If the SMB client wants more data, it must send a
TRANS2_FIND_NEXT2 request with the same SID. And then the server
will continue sending more until it runs out.
The root cause of this bug is that after the TRANS2_FIND_FIRST2
request is sent, our SMB's find_first method forgets the SID at
the end of the loop (out of scope).
Minor changes to comments
Updated URLs
Added Fedora ROP, cleaned up
Fixing URLs again, typos
Added support for Archlinux (new target)
Added support for OpenSuse (new target)
Tincd is now a separate file, uses the TCP mixin/REX sockets.
Started ARM exploiting
Style changes, improvements according to egyp7's comments
Style changes according to sane rubocop messages
RSA key length other than 256 supported. Different key lengths for client/server supported.
Drop location for binary can be customized
Refactoring: Replaced pop_inbuffer with slice
Refactoring: fail_with is called, renamed method to send_recv to match other protocol classes,
using rand_text_alpha instead of hardcoded \x90,
Fixed fail command usage
Version exploiting ARM with ASLR brute force
Cleaned up version with nicer program flow
More elegant solution for data too large for modulus
Minor changes in comments only (comment about firewalld)
Correct usage of the TCP mixin
Fixes module option so that the path to drop the binary on the server is not validated against the local filesystem
Added comments
Minor edits
Space removal at EOL according to msftidy
There has been Meterpreter work done as well to support this. But this
commit allows for a new 'getsid' command which tells you the sid of the
current process/thread. This can be used for things like determining
whether the current process is running as system. It could also be used
for golden ticket creation, among other things.
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.
- Adding add_host() Although Report host exists, this is a
straightforward method to metasploit-credential::creation::add_host()
- Add workspace.id to the responses of db.current_workspace and
db.workspace and db.get_workspace
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.
Minor tweaks after the PR from @kernelsmith
Remaining items:
1. Handle empty session IDs correctly, for example 'sessions -d' or 'sessions -k'
2. Find a method of explaining the range options in the help text
3. Retest all changed code areas
4. Edit PR Summary to reflect changes to the scope
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.
- Added check for un-detach-able sessions
- Added back the check for session.interactive? when detaching sessions
- Collapse build_jobs_array and build_sessions_array to build_range_array
- Added check for empty or invalid parameters to detach and kill [session | job]
- Reworked session id sanity check around line 1660
- RuboCop/Style guide change: Array.new -> []
- Misc RuboCop/Style guide spacing changes
* Add RPORT as a regular option, define rport
* Add CPORT as an advanced option, define cport
* Change CHOST to an advanced option
* Use a more sane THREADS value since hosts are scanned in batches
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.
This makes it somewhat easier to use FTP server exploit modules in
somewhat more restrictive networks, where you might only have a few
inbound ports to choose from.
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.
Instead of the eventual target where our proxy chain will connect. In
the usual case (no Proxies set), this will be the same output as before.
When proxies are given, the user will see that the first proxy
connection is actually what failed.
MSP-11126
Fully-qualify `Msf::MODULE_TYPES`, `Msf::MODULE_ANY`,
Msf::MODULE_ENCODER`, `Msf::MODULE_EXPLOIT`, `Msf::MODULE_NOP`,
`Msf::MODULE_AUX`, `Msf::MODULE_PAYLOAD`, `Msf::MODULE_POST` so that
their usage isn't dependent on nested lexical scoping.
MSP-11152
When `Msf::DBManager::Import::MetasploitFramework` is included in
`Msf::DBManager::Import`, it's child namespace of
`Msf::DBManager::Import::MetasploitFramework::Zip becomes resolvable as
`Zip` in `Msf::DBManager::Import` methods, so need to use `::Zip` to
cause `Zip` to be resolved from rubyzip gem.
MSP-11152
Constant was unqualified in some of the reorganized Msf::DBManager code
because that code was take advantage of the old nested lexical scope
that included `Msf`.
MSP-11126
`Msf::Module::Author` was already aliased to `Msf::Author`. This just
moved `Msf::Module::Author` to that alias to free up
`Msf::Module::Author` so it can be used for a concern for
`Msf::Module`'s author methods.