Things like browser exploits don't have remote host options
which is what auto targeting relies on, so it does not make sense
to include the auto-targeting in these exploits
7837
the target selection actually adjust the datastore
as if a user selected the target, this prevents
a mismatch between the target and the target index
MS-2325
if the module authour added an automatic target
we skip our routine, to let the module's own automatic targeting
take over as it likely be better
MS-2325
This streamlines the check for whether the currently-selected payload is
compatible on assignment. Rather than building the entire list of
compatible payloads, and seeing if what the user typed is in it (and
making multiple giant lists on the way), we simply check the module the
user typed directly.
reimplement HD's work on a session interrupt handler
so that if an exploit fails the handler does not continue
waiting for a session that will never come
MS-385
Fix#6371
When a browser fails to bind (probably due to an invalid port or
server IP), the module actually fails to report this exception from
exception, the method calls exploit.handle_exception(e). But since
handle_exception is not a valid method for that object, it is unable
to do so, and as a result the module fails to properly terminate
the module, or show any error on the console. For the user, this will
make it look like the module has started, the payload listener is up,
but there is no exploit job.
Rex::BindFailed actually isn't the only error that could be raised
by #job_run_proc. As far as I can tell registering the same resource
again could, too. With this patch, the user should be able to see this
error too.
Since the exploit object does not have access to the methods in
Msf::Simple::Exploit, plus there is no other code using
handle_exception and setup_fail_detail_from_exception, I decided
to move these to lib/msf/core/exploit.rb so they are actually
callable.
The fail_with for an exploit is used differently than a non-exploit,
so it would be nice to document about this. Also, be strict about
the reason for the exploit one, because this can affect other
components of Metasploit.
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.
So Metasploit uses the term "exploit" to describe something, a module
or an action, that results popping a shell. A check normally doesn't
pop a shell, so avoid that language.
An example of the biggest confusion module developers face is not
actually knowing the difference between Detected vs Appears vs
Vulnerable. For example: a module might flag something as a
vulnerable by simply doing a banner check, but this is often
unreliable because either 1) that banner can be fooled, or 2)
the patch does not actually update the banner. More reasons may
apply. Just because the banner LOOKS vulnearble doesn't mean it is.
Also replaces dead code in lib/msf/core/exploit/local.rb with what was
actually being used for the Exploit::Local class that lived in
lib/msf/core/exploit.rb.
While it makes lots of sense to bring check to all modules, of course
some modules will not be able to actually use it. Namely modules like
nop and payload modules. If you're feeling creative, you could probably
come up with semantically similar checks for those, too.
Brent Cook
Brent Cook
David Maloney
William Vu
wchen-r7
James Lee
jvazquez-r7
Fernando Arias
Christian Mehlmauer
root
Luke Imhoff
Meatballs
Tab Assassin
HD Moore
Tod Beardsley