When using the Meterpreter Binaries gem to locate the path to the
meterpreter DLLs, it's not necessary to use File.expand_path on
the result because the gem's code does this already.
This commit simple removes those unnecessary calls.
Since Ruby 2.1, the respond_to? method is more strict because it does
not check protected methods. So when you use send(), clearly you're
ignoring this type of access control. The patch is meant to preserve
this behavior to avoid potential breakage.
Resolve#4507
response_timeout is a method specific to a meterpreter session, not
shell. So if the user is using a shell type payload, he will never
see a backtrace before interacting with the sessions.
When a meterpreter binary cannot be found, give the user some hint about what
went wrong.
```
msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.43.1
lhost => 192.168.43.1
msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.43.1:4444
[*] Starting the payload handler...
[*] Sending stage (770048 bytes) to 192.168.43.252
[*] Meterpreter session 1 opened (192.168.43.1:4444 -> 192.168.43.252:49297) at 2014-12-29 12:32:37 -0600
meterpreter > use mack
Loading extension mack...
[-] Failed to load extension: No module of the name ext_server_mack.x86.dll found
```
This is also useful for not scaring away would-be developers who replaced only
half (the wrong half) of their DLLs from a fresh meterpreter build and
everything exploded. Not that thats ever happened to me :)
The current logic times out every packet almost immediately, making it possible
for almost any non-trivial meterpreter session to receive duplicate packets.
This causes problems especially with any interactions that involve passing
resource handles or pointers back and forth between MSF and meterpreter, since
meterpreter can be told to operate on freed pointers, double-closes, etc.
This probably fixes tons of heisenbugs, including #3798.
To reproduce this, I enabled all debug messages in meterpreter to slow it
down, then ran this RC script with a reverse TCP meterpreter, after linking in
the test modules:
(cd modules/post
ln -s ../../test/modules/post/test)
die.rc:
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost 192.168.43.1
exploit -j
sleep 5
use post/test/services
set SESSION 1
run
Rather than literally returning the default Regex object, override the accessor
to return the string representation. This allows the RPC backend to properly
serialize the options hash values, since msgpack does not know how to serialize
a Regexp object. Fixes#3798.
To verify the fix, run the steps for issue #3798 and ensure that the module
options are returned instead of a backtrace. Also, ensure that the module
continues to work as expected:
```
$ ./msfconsole -q
msf > use auxiliary/scanner/http/scraper
msf auxiliary(scraper) > info
Name: HTTP Page Scraper
Module: auxiliary/scanner/http/scraper
License: Metasploit Framework License (BSD)
Rank: Normal
Provided by:
et <et@metasploit.com>
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
PATH / yes The test path to the page to analize
PATTERN (?i-mx:<title>(.*)<\/title>) yes The regex to use (default regex is a sample to grab page title)
Proxies no Use a proxy chain
RHOSTS yes The target address range or CIDR identifier
RPORT 80 yes The target port
THREADS 1 yes The number of concurrent threads
VHOST no HTTP server virtual host
override default attr for OptRegexp
Description:
Scrap defined data from a specific web page based on a regular
expresion
msf auxiliary(scraper) > set RHOSTS lwn.net
RHOSTS => lwn.net
msf auxiliary(scraper) > set RHOSTS 72.51.34.34
RHOSTS => 72.51.34.34
msf auxiliary(scraper) > set VHOST lwn.net
VHOST => lwn.net
msf auxiliary(scraper) > run
[*] [72.51.34.34] / [Welcome to LWN.net [LWN.net]]
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
```