Fix #16684, Set @peer_info in #initialize

[zeroSteiner]

Closes #16684

The #tunnel_peer method caches the value in the @peer_info attribute. If #rstream is closed when this is called, it'll raise an exception and return the address '127.0.0.1' which is incorrect. The #rstream is only open for a short period of time when serving an HTTP request, which means that if the information was not cached while the socket was opened, it's unavailable.

It would appear as though commit 38688e1 introduced in PR #14844 changed where #tunnel_peer is called for the first time. After that change, the socket is already closed in the case of the reverse_http transport, leading to the address '127.0.0.1' being incorrectly reported as the remote host.

This change fixes the issue by updating #initialize to proactively set @peer_info if #rstream is provided. This will ensure that the information is set for later use. If it fails for some reason then @peer_info will be left unset and #tunnel_peer will attempt to set it again. This should account for cases of #rstream being set later. I don't know of any cases of this happening but it seems like something worth accounting for.

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• Use an exploit or something to get a Meterpreter session using a reverse_http(s) handler
• See the correct peer address and not 127.0.0.1

Demo

Unpatched on the left, patched on the right.

[adfoster-r7]

For a linux reverse http payload

Before

msf6 payload(linux/x64/meterpreter_reverse_https) > sessions

Active sessions
===============

  Id  Name  Type                   Information             Connection
  --  ----  ----                   -----------             ----------
  1         meterpreter x64/linux  kali @ 192.168.123.128  192.168.123.1:8443 -> 127.0.0.1 (::1)

After

msf6 payload(linux/x64/meterpreter_reverse_https) > sessions

Active sessions
===============

  Id  Name  Type                   Information             Connection
  --  ----  ----                   -----------             ----------
  1         meterpreter x64/linux  kali @ 192.168.123.128  192.168.123.1:8443 -> 192.168.123.128:55730 (192.168.123.128)

[adfoster-r7]

I tested the shell -> meterpreter -> ssh_login via pivoting scenario to see if the IP would appear in the information column as well, but it looks like that bug is unrelated to this PR

msf6 auxiliary(scanner/ssh/ssh_login) > sessions

Active sessions
===============

  Id  Name  Type                   Information               Connection
  --  ----  ----                   -----------               ----------
  1         shell cmd/unix                                   10.9.0.198:4444 -> 10.10.23.120:41792 (10.10.23.120)
  2         meterpreter x86/linux  www-data @ 172.28.101.50  10.9.0.198:4433 -> 10.10.23.120:44870 (172.28.101.50)
  3         shell linux            SSH kali @                10.9.0.198-10.10.23.120:53032 -> 172.17.0.1:22 (172.17.0.1)

Edit: Directly running ssh against a target with metasploit 6.2.x:

msf6 auxiliary(scanner/ssh/ssh_login) > run ssh://user:password@127.0.0.1:2222

[*] 127.0.0.1:2222 - Starting bruteforce
[+] 127.0.0.1:2222 - Success: 'user:password' 'uid=1000(user) gid=1000(user) groups=1000(user) Linux 8af0e445ed70 5.10.0-kali3-amd64 #1 SMP Debian 5.10.13-1kali1 (2021-02-08) x86_64 x86_64 x86_64 GNU/Linux '
[*] SSH session 5 opened (127.0.0.1:36933 -> 127.0.0.1:2222) at 2022-09-20 06:36:34 -0400
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/ssh/ssh_login) > sessions

Active sessions
===============

  Id  Name  Type         Information  Connection
  --  ----  ----         -----------  ----------
  5         shell linux  SSH kali @   127.0.0.1:36933 -> 127.0.0.1:2222 (127.0.0.1)

Metasploit 5.0.101 works

msf5 auxiliary(scanner/ssh/ssh_login) > sessions

Active sessions
===============

  Id  Name  Type         Information                         Connection
  --  ----  ----         -----------                         ----------
  1         shell linux  SSH user:password (127.0.0.1:2222)  127.0.0.1:36793 -> 127.0.0.1:2222 (127.0.0.1)

Looks like the commit before 38688e1 works

And 38688e1 itself works, so not a blocker

Edit: Looks like that missing SSH information was broken by #15831

Double edit: PR up: #17041

[adfoster-r7]

Release Notes

Fixes a bug where the sessions command would show the connection as coming from losthost 127.0.0.1, instead of the correct peer host address for reverse_http Meterpreter sessions