[SeeRM #823], where Stephen was asking for SSL compression for
Meterpreter -- this isn't that, but it's at least now possible for other
Metasploit functionality.
Basically the updated version is more explicit. If a moethod doesn't
return anything but might raise an error, then we focus on that.
Also use . to # for instance methods.
* Updated descriptions to be a little more descriptive.
* Updated store_loot calls to inform the user where the
loot is stored.
* Removed newlines in print_* statments -- these will screw
up Scanner output when dealing with multiple hosts.
Of the fixed newlines, I haven't see any output, so I'm not sure what
the actual message is going to look like -- I expect it's a whole bunch
of newlines in there so it'll be kinda ugly as is (not a blocker for
this but should clean up eventually)
This lands Meterpreter binaries as of commit e77c87cd
The compare view is the easiest way to see what's different since the
last update:
9e33acf...e77c87cd
Not seeing a lot of bugs being ref'ed there, sadly.
If MSF can not match the visible IP address of a Meterpreter session
to an interface--it will attempt to find an IP address associated
with a default route and use it as the session's address.
This commit fixes the logic associated with this process. The old
logic only considers one IP address per Interface, even though an
Interface may have multiple addresses/masks associated with it.
This flaw led to situations where MSF would favor an IPv6 link-local
address over the IPv4 address associated with the default route,
solely because the IPv4 address was not the first value in the
addresses array.
[FixRM #7259]
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.