How to Exploit a Remote File Inclusion (RFI)

Remote File Inclusion (RFI) is a vulnerability very similar to LFI (Local File Inclusion). The difference is that while LFI allows you to include local files, RFI allows you to include remote files.

This is obviously super sketchy, because if we as attackers set up a web server, we can take advantage of the victim machine’s RFI to make it load and interpret a malicious file we’re hosting as if it were its own.

Let’s set up the vulnerability locally:

First of all, we create the PHP file that will host the file inclusion:

This is a simple code where from a GET request, the server will receive a value through the file parameter and will include the file with that name on the page.

With this code, if we access the URL:

• http://localhost/index.php?file=/etc/hosts

It will load the hosts file. However, we need to enable it to also accept URLs. To do this, we go to the PHP configuration, which we can find with:

Since in my case I’m going to set up the web server using the PHP command itself, I’ll edit the configuration file from the second line.

Inside this file, we need to search for the allow_url_include variable:

By default, the value of this variable will be Off, so we simply change it to On and that’s it.

With this done, we simply set up the web server with the php command:

• php -S localhost:80

We can verify that the file and web server work correctly, since the LFI works. This happens because LFI and RFI share the same PHP code, so by verifying that LFI works we know everything is correct.

Now, on another machine, I’m going to host the malicious file (a webshell) and set up a web server:

Right now this machine, which is a Debian with IP 192.168.118.131, is sharing the sikushell.php file.

So if I now from the vulnerable web server, change the /etc/hosts for the Debian web server address, I should receive a GET request:

Indeed, on the server side I receive the GET request, and on the client side I can view everything it’s sharing. Now, in addition to specifying the web server, let’s navigate to the sikushell.php file:

It seems to exist, but it doesn’t show us anything. This is because it’s waiting for the cmd parameter, which is what we specified in the malicious file:

Note how when concatenating the new cmd parameter to all the others, we used an ampersand (&). This is because the question mark that always corresponds to the first parameter is already being used by the file parameter.

It seems that the malicious file is being interpreted correctly and we’re executing commands. If we see which machine we’re on, we can see that we’re on the Kali, in other words, the vulnerable web server:

We’re executing commands locally using a remote file. This is basically a Remote File Inclusion.