* 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.
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.
So in the previous refactor, we made the dedicated method to parse
usernames and passwords from the split up config values. However, that
didn't work, because on a single iteration of the loop, you only have
access to a possible username OR password. The other matching key will
be another iteration of the loop. Because of this, no credential pairs
were being reported.
The only way I can see around this (maybe because I'm a ruby newb) would
be to iterate over configs, and if the user or password regex matches,
add the matching value to a hash, which is identified by a key for both
user & pass. Then upon completion of the loop, it'd iterate over the
hash, finding keys that had both user & pass values.