Local File Inclusion

 

1. Course Description

 

This Kali Linux training course is a hands-on lab guide. To clarify certain steps in the labs, theory will be integrated, and the most valuable articles will be recommended. This approach ensures a strong theoretical foundation while engaging in practical experimentation.

Note: Due to the high cost of setting up cloud hosts for the lab, the number of attempts will be limited. Each lab session is restricted to no more than six attempts.

2. Learning Methods

 

The “Kali Linux” series on the Experiment Platform includes five training programs. This program focuses on techniques for attacking web applications. The course includes 20 labs, each with detailed steps and screenshots. It is particularly suited for students with basic Linux knowledge who want to quickly get started with Kali penetration testing.

The key to learning is frequent practice and active questioning. Launch the lab and follow the given steps, ensuring you understand the details behind each step.

If there are recommended materials at the start of a lab session, make sure to read them before proceeding. Theoretical knowledge is a necessary foundation for effective practice.

3. Overview of This Section

 

In this lab, we’ll get a basic understanding of Kali Linux and penetration testing concepts. You will complete the following tasks in sequence:

• Introduction to Local File Inclusion
• Attempting Local File Inclusion
• Advanced Local File Inclusion
• Mitigation of Local File Inclusion

4. Recommended Reading

 

The following materials are recommended for this lab:

1. Introduction to File Inclusion Vulnerability

5. Introduction to File Inclusion

 

5.1 Overview of File Inclusion Vulnerabilities

 

File Inclusion vulnerabilities, also known as “File Inclusion,” are a very common type of vulnerability. These vulnerabilities often affect websites that rely on script execution. The issue arises when a web application constructs the path to executable code using an attacker-controlled variable, allowing the attacker to execute files of their choice at runtime.

Unlike the common Directory Traversal Attack, which only accesses unauthorized files and leads to information leakage, File Inclusion vulnerabilities can directly affect the executable files, potentially disrupting the entire website’s functionality.

File Inclusion vulnerabilities are typically divided into two categories:

• Local File Inclusion (LFI): Includes files located locally on the server.
• Remote File Inclusion (RFI): Includes files hosted on remote servers.

These issues frequently occur when a specific functionality is modularized, requiring the inclusion of a file or reference to external code for use. This problem is common in programming languages like PHP and JSP. Such issues can also occur with SSI, though it is less common.

5.2 Setting Up the Environment

 

This lab will focus on understanding LFI (Local File Inclusion) and the type of information it can retrieve. We will use the DVWA environment to conduct our experiments.

Similar to previous exercises, first, start the target machine, open DVWA, and set the security levels to “low”:

On the lab desktop, double-click the Xfce terminal to open it:

Use the command sudo virsh start Metasploitable2 to start the virtual machine:

Wait about 4 minutes for the virtual machine to fully start, then open Firefox on the desktop:

Navigate to the target machine’s IP address 192.168.122.102:

Once the target machine starts successfully, accessing its IP address should display such a page.

Click on DVWA to enter its login page. The default login credentials are admin and password, after which you will land on a page like this:

To perform the simplest attack, set the security level to “low.” Start by going to the security configuration page:

Then, set the security level to “low”:

When you see the change in the “Level” display at the bottom of the page, it means the modification was successful:

6. Initial Testing of File Inclusion

 

This experimental platform is built on a PHP/MySQL architecture. By leveraging PHP’s special functions, you can dynamically include files using URLs. However, if the origin file isn’t thoroughly validated, attackers could exploit this vulnerability, enabling them to read or execute arbitrary files and commands.

Important: After PHP version 5.2.0, the configuration option allow_url_include was introduced, while earlier versions (before 4.3.4) relied on allow_url_fopen. In PHP 5.x, allow_url_include is disabled by default, while this parameter was enabled by default in earlier PHP versions.

PHP provides the following inclusion functions:

• include(): Includes and executes a file. If the file is not found or the path is incorrect, a warning will be issued, but execution will continue.
• include_once(): Behaves like include(), but prevents the same file from being included multiple times.
• require(): Includes and executes a file. If the file is not found or the path is incorrect, it immediately halts execution.
• require_once(): Works like require(), but avoids including the same file multiple times.

Files included with these functions will execute their contents if they follow PHP syntax guidelines. If the included file doesn’t adhere to PHP syntax, its content will be displayed directly on the page.

Let’s test this functionality using the environment provided by DVWA. Upon inspection, we see this interface:

The page informs us that modifying the value of the GET parameter can include files. At this point, we don’t know which files are available or whether the server uses Linux or Windows. We can enter a random parameter to observe the outcome, which will produce this error:

Analyzing the error message reveals two important details:

• The platform runs on Linux, not Windows, since Windows doesn’t have a /var/www/ directory structure.
• The root directory for the application is /var/www/dvwa.

In PHP, websites typically include a robots.txt file in the root directory. This file provides search engines instructions on which directories or content should have restricted access.

Let’s enter the following URL into the browser:

http://192.168.122.102/dvwa/vulnerabilities/fi/?page=../../robots.txt

Pressing Enter displays the following result:

Earlier, we used a relative path, but we could use an absolute path to achieve the same result:

http://192.168.122.102/dvwa/vulnerabilities/fi/?page=/var/www/dvwa/robots.txt

This works as expected, returning the same result.

Additionally, we can access the website’s PHP configuration file using this method:

http://192.168.122.102/dvwa/vulnerabilities/fi/?page=/var/www/dvwa/php.ini

Moreover, we can view the detailed PHP configuration for the system by accessing the phpinfo file:

http://192.168.122.102/dvwa/vulnerabilities/fi/?page=/var/www/dvwa/phpinfo.php

From this page, we can obtain a wealth of information, ranging from the PHP core version to the location of the API interface configuration files. Scrolling down reveals the values of all configuration parameters. This eliminates much of the trial-and-error work caused by certain configuration parameters being disabled or vulnerabilities being patched in higher versions, thus significantly improving our efficiency.

As we discussed earlier, the parameters allow_url_include and allow_url_fopen are of particular interest. We can check whether these two parameters are enabled:

If these are not the primary issues, things take a turn for the worse when a file is included:

 http://192.168.122.102/dvwa/vulnerabilities/fi/?page=/proc/self/environ 

From this file, we can extract user session information and the user-agent. With this information, we can take various actions:

Let’s check the source code:

The root issue stems from the fact that no protections or filters are in place, giving attackers the opportunity to access all files on the device and expose substantial amounts of sensitive information.

7. Advanced File Inclusion

 

If you think local file inclusion ends there, you’d be wrong. Attack techniques often involve a combination of small tricks and programmer oversight to succeed. Local file inclusion, when used merely for file viewing, lacks significant value. It gained popularity for a reason.

Imagine a scenario where file upload functionality exists. What could we do?

We could upload a backdoor script and include it within the current page to execute it. This would allow us not only to view files but also to run commands.

Locally, create such a PHP file (note this is done on the local system, i.e., the Shiyanlou user terminal, not the virtual machine, as this file is to be uploaded):

Use the terminal command vim test.php to create and edit the file:

Then input the following content:

    ';

?> 

The first line uses cmd to execute commands, while the second line provides an input field to enter commands, so you don’t need to edit the URL every time (the URL in the second line can be determined later).

Save the file using :wq.

Now, log back into DVWA and access the Upload environment:

Select “Browse,” upload the test.php file, and then click upload. After successful upload, you’ll see the following message:

The success message provides the file path of the uploaded file. Such messages are unwise as they make inclusion attacks much easier.

Now, access the File Inclusion environment again. This time, modify the value of the page parameter in the GET request to the path of the uploaded file:

Certainly! Below is the translated version of the text, with all HTML structure, tags, and formatting preserved:

We can see that the PHP script we submitted was executed successfully.

We can try entering simple shell commands in the input box:

For example, pwd

Just like that, isn’t the risk of local file inclusion quite significant? Here, it’s only a pseudo web shell, so it can only execute simple commands that don’t require interaction because this demonstration lacks interactive capabilities.

8. Local File Inclusion Prevention

 

Using the same method, we adjust the Security level to medium:

Then we return to view the source code, and we find these two additional lines:

     $file = str_replace("http://", "", $file);
    $file = str_replace("https://", "", $file); 

These two lines are meant to prevent remote file inclusion by replacing occurrences of http:// and https:// in the retrieved variables with blank values. However, for local file inclusion prevention, there are additional measures, though this platform version is slightly outdated and doesn’t address them:

1. The relative path method—this method is somewhat limited in effectiveness.

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

This replaces all ../ instances in the variable with blank values. For example, in our previous example, ../../robots.txt would become robots.txt, thus preventing access. However, using absolute paths would bypass this issue entirely.

If you still want to use relative paths, you could use a nested approach to bypass it:

 ..././..././robots.txt

After replacing ../, the path remains valid.

2. Another prevention method is adding a suffix to the retrieved variable name:

  include("$file"."php");

Or adding a filter condition requiring the suffix of GET parameters to be .php.

For such filtering conditions, in PHP versions below 5.3.4 and with the Magic_quote_gpc option turned off, you can use %00 to truncate and bypass the filter.

The %00 null-byte character causes content following it to be ignored. For example:

 http://192.168.122.102/dvwa/vulnerabilities/fi/?page=/var/www/dvwa/robots.txt%00test.php

Even if there’s a .php suffix, or if you add another .php suffix afterward, the effective URL will still be:

 http://192.168.122.102/dvwa/vulnerabilities/fi/?page=/var/www/dvwa/robots.txt

Essentially, everything after %00 is ignored.

So, does it seem difficult to solve local file inclusion vulnerabilities?

The simplest method is to hardcode an absolute path to a specific file, which guarantees no such vulnerabilities will occur.

Another approach is to reference the high-level code:

     if ( $file != "include.php" ) {
        echo "ERROR: File not found!";
        exit;
    } 

This allows only include.php as the variable value. You could also use a switch statement to match multiple values. This approach is essentially similar to hardcoding.

These are several ways to handle local file inclusion vulnerabilities.

9. Summary

 

In this lab, we have learned the following topics. If you have any questions, feel free to discuss with us at the Shiyanlou Q&A section:

• Introduction to Local File Inclusion
• Basic Local File Inclusion
• Advanced Local File Inclusion
• Local File Inclusion Prevention

Please ensure you can complete the entire lab on your own. Simply reading the text is easy; the actual hands-on work presents various challenges, and solving those challenges is where the real learning happens.

10. Assignment

 

1. Try implementing two prevention methods in a local PHP environment.