Fix up URI switching for stageless

[OJ]

Stageless Windows HTTP/S Meterpreter sessions were failing to migrate because the internal implementation of URI switching was only updating the current URI that was in use for the HTTP/S comms, and not updating the transport configuration that was being maintained behind the scenes. This meant that stageless sessions would create a transport configuration block for migration that was invalid, and the result was nasty crashes.

This PR contains code that changes this behaviour so that it doesn't crash. It:

• Moves the URI copying outside of the dispatch loop. This means that the response to the URI switch goes back down the same channel as the one it was requested on.
• Modifies the transport's configuration block to include the new URI so that migration configuration stubs are generated correctly.

  Verification

  Pre-patch

Without this patch, this is what would happen on migrate:

meterpreter > migrate 552
[*] Migrating from 3420 to 552...

[*] 10.1.10.35:49182 (UUID: a48d3799ae791c89/x86=1/windows=1/2015-06-27T08:20:40Z) Redirecting stageless connection ...
[*] 10.1.10.35:49183 (UUID: a48d3799ae791c89/x86=1/windows=1/2015-06-27T08:20:40Z) Attaching orphaned/stageless session ...
[*] Meterpreter session 4 opened (10.1.10.40:8443 -> 10.1.10.35:49183) at 2015-06-27 19:03:48 +1000

[-] Error running command migrate: Rex::RuntimeError No response was received to the core_enumextcmd request.
meterpreter > 
meterpreter > exit
[*] Shutting down Meterpreter...

[*] 10.1.10.35 - Meterpreter session 1 closed.  Reason: User exit
msf exploit(handler) > [-] Failed to load extension: No response was received to the core_loadlib request.

As you can see, rather messy. You can see that MSF thinks it's a new session coming back in when it's not, and things get very out of whack.

The crash on Windows was horrible too.

Post-patch

And with this PR implemented, we get:

meterpreter > migrate 348
[*] Migrating from 2024 to 348...
[*] Migration completed successfully.
meterpreter > sysinfo
Computer        : WIN-S45GUQ5KGVK
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x64/win64
meterpreter > exit

Steps

For each of windows/meterpreter_reverse_http, windows/meterpreter_reverse_https, windows/x64/meterpreter_reverse_http and windows/x64/meterpreter_reverse_https:

• [x] Create a payload (stageless obviously).
• [x] Set up the appropriate listener.
• [x] Establish a session.
• [x] Migrate to another process.
• [x] Confirm that this doesn't crash any more.

Sorry for the failures! @hmoore-r7 and @bcook-r7 I'd appreciate your eyes over this. Thanks!

[metasploit-public-bot]

Test FAILED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/206/ Test FAILED.

[metasploit-public-bot]

Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/207/ Test PASSED.

[void-in]

@OJ Does this crash required a particular setup? Because clearly I have been using stageless meterpreter and migrating without any problem. Tested on Windows 7 x64 yesterday. Migrated to an 64 bit process and everything worked completely fine.

[OJ]

This problem only exists when the stageless payload does what it should do and use :init_connect for the initial stage URL. So you wouldn't see this problem appear because of the issue here: https://github.com/rapid7/metasploit-framework/pull/5618

Now that the above PR has been landed, you will see this problem occurring, and so this becomes important.

Cheers!

[void-in]

@OJ Ah thanks a lot for clarification. Didn't see the PR at msf end. Good work.

[OJ]

Thanks @void-in. I should have mentioned it in the original submission! I'm glad you asked the question.

Cheers.

[bcook-r7]

Migrates like a champ, thanks.

[OJ]

Thanks mate. Appreciate you looking at stuff on your weekend.