[Network Security --- web server parsing vulnerabilities] Common parsing vulnerabilities in IIS, Apache, and Nginx middleware

1. Tool and environment preparation

The following are super detailed nanny-level installation tutorials. Just install whatever is missing (mirror tool resources are provided)

2. Server parsing vulnerability

Server parsing vulnerabilities have a relatively long history, but they are still widespread today. Here we record and summarize the parsing vulnerabilities of some common servers (WEB servers), such as IIS6.0, IIS7.5, apache, nginx, etc. for future review.

2-1 IIS5.x-6.x parsing vulnerability

## Servers using iis5.x-6.x versions are mostly windows server 2003. The website is relatively old, and the development statements are generally asp; this parsing vulnerability can only parse asp files, but not aspx files. . Most of win7-win10 are iis7.x-8.x, and the versions are relatively high.

Directory parsing (6.0)
Format: www.xxx.com/xx.asp/xx.jpg
Principle: Server By default, files in the .asp and .asa directories will be parsed into asp files.

File parsing
Format: www.xxx.com/xx.asp;.jpg
Principle: The server does not parse by default; The content after the number, so xx.asp;.jpg is parsed into an asp file.

Parsing file types
IIS6.0 default executable files include these three types in addition to asp:
/test.asa
/test.cer
/test.cdx

Repair plan
1. Currently There is no official patch from Microsoft. You can write your own regular rules to prevent the upload of file names of the xx.asp;.jpg type.
2. Set permissions to restrict users from creating folders.

2-1-1 www.xxx.com/xx.asp;.jpg

We demonstrate a www.xxx.com/xx.asp;.jpg

We open the Fannuo Enterprise Management System website (For shooting range installation, please see the first part of Tools and Environment Preparation)

This home page is index.asp. We copy this index.asp and rename it to show.asp;.jpg as follows:

Then access the browser http://192.168.31.208/show.asp;.jpg

It is found that the access can still be successful. This is a parsing vulnerability. If you find that the ASP website has a place where you can upload pictures, you can use this method to upload the ASP Trojan program to bypass verification.

2-1-2 www.xxx.com/xx.asp/xx.jpg

Principle: By default, the server will parse files in the .asp and .asa directories into asp files.

Browser access 192.168.31.208/xx.asp/index.jpg

We found that an error was reported, but the error was normal, because the homepage must contain some other code files. We moved the homepage to another directory. Of course, we could not find the paths included, so we reported an error. The picture above also shows that it cannot be found. to an included file, but it is definitely index.jpg. When an asp file is executed, an error is reported due to a path problem during execution.

2-1-3 index.asa | index.cer | index.cdx

In addition to asp, the default executable files of IIS6.0 include these three types:
/test.asa
/test.cer
/test.cdx

Choose one to demonstrate. Let’s change the name of index.asp on the homepage to index.cer

The access effect is as follows, you can also access

The cer file is generally a certificate file, and iis can also parse it by default. Let’s look at the website properties.

2-2 apache parsing vulnerability

Principle of the vulnerability
　 The rule of Apache parsing files is to start from right to left to judge the parsing. If the suffix is unrecognizable file parsing, it will judge from the left. For example, test.php.owf.rar ".owf" and ".rar" are two suffixes that apache cannot recognize and parse, and apache will parse xx.php.owf.rar into php. ## Vulnerability form www.xxxx.xxx.com/test.php.php123 This vulnerability killed all websites built by apache at that time. ## Other configuration issues lead to vulnerabilities (1) If there is such a line in Apache's conf to configure AddHandler php5-script.php, then as long as the file name is Contains .php Even if the file name is test2.php.jpg, it will be executed as php. (2) If there is such a line configuration in Apache's conf AddType application/x-httpd-php .jpg, even if the extension is jpg, it can still be executed in php mode. xx.jpg

Example:www.xxxx.xxx.com/test.php.php123

Take the pikachu shooting range as an example (for shooting range installation, please see Part 1 Tools and Environment Preparation)

For example, if we change sql.php to sql.php.xxxx, it cannot be parsed normally, but old versions of apache (apache2.2 and earlier) can parse this file into a php file normally.

I am using a new version of apache and have not built an old version, so you can just remember this vulnerability. Of course, the new version of apache will also cause this vulnerability if it is not configured properly. If you are interested, you can install a low-level version. Let’s play with the new version of apache. If you look at the new version, it will not parse the running code. It will directly show you the source code instead of executing the source code. In the past, everyone used blacklists to defend themselves, but they basically failed because you found that you could write the suffix name at will.

Other configuration issues lead to vulnerabilities

(1) If there is such a line configuration in Apache's conf AddHandler php5-script .php, then as long as the file name contains .php, even if the file name is test2.php.jpg, it will be executed with php.
(2) If there is such a line configuration in Apache's conf AddType application/x-httpd-php .jpg, even if the extension is jpg, it can still be executed in php mode.

These two vulnerabilities are not a problem with Apache itself, but a problem with the configuration of the operation and maintenance personnel.

I won’t demonstrate it here.

Fix

1. Apache configuration file, prohibit the execution of files like .php., add it to the configuration file

<Files ~ “.(php.|php3.)”>
Order Allow,Deny
Deny from all
</Files>

2. Use pseudo-static to solve this problem. Rewrite files like .php.*, open httpd.conf of apache, find LoadModule rewrite_module modules/mod_rewrite.so, remove the # number, restart apache, and create it in the root directory of the website. htaccess file, the code is as follows:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .(php.|php3.) /index.php< a i=3> RewriteRule .(pHp.|pHp3.) /index.php RewriteRule .(phP.|phP3.) /index.php RewriteRule . (Php.|Php3.) /index.php RewriteRule .(PHp.|PHp3.) /index.php RewriteRule .(PhP.|PhP3. ) /index.php RewriteRule .(pHP.|pHP3.) /index.php RewriteRule .(PHP.|PHP3.) /index.php< /span> </IfModule>

2-3 nginx parsing vulnerability

General principle: This vulnerability has nothing to do with nginx and php versions. It is a parsing vulnerability caused by improper configuration.

## When cgi.fix_pathinfo is enabled in the php.ini configuration file, the value defaults to 1, which means it is enabled. Judging from the name, you can probably tell that it is the configuration used to process paths.

## For example, we uploaded a Trojan horse file web.jpg, because web.php cannot be uploaded. Now we want to execute this web.jpg, which can be accessed at the following path
http:/ /192.168.2.104/pikachu/web.jpg/aaa.php

## There is no aaa.php file on the target server. If there is no problem with the configuration of nginx.conf, nginx will first check whether the file exists. If it exists, it will look for the PHP interpreter to interpret the execution code. If it does not exist, , nginx will directly return an error message, saying that the file cannot be found, but if nginx.conf is not configured properly, it will cause nginx to hand over files ending with '.php' to fastcgi for processing. That is to say, first nginx sees that you need to Find aaa.php, oh, it turns out to be a PHP file. Nginx does not look for this file anymore, but directly gives it to fastcgi. Fastcgi then looks for the PHP interpreter to process the path, and PHP turns on cgi.fix_pathinfo, then When the php interpreter processes this path, it finds that there is no aaa.php file, then it will find the file in the upper path in the path and run it as aaa.php. If so, it will find web.jpg and treat web.jpg as aaa.php is run, so the code is executed and you see the following effect

Example: We use phpstudy to change it to nginx (pikachu shooting range)

The function parameter fix_pathinfo is enabled by default, so the impact of this vulnerability is relatively large. Let’s access the phpinfo.php file to see if this function is enabled.

A value of 1 indicates the open state, then this vulnerability exists.

For example, I changed a Trojan file into a .jpg file and placed it in the pikachu folder.

(This Trojan file is given in the tool information for uploading files to pass the shooting range. If you need it, please read my blog below to download it)

[Network Security --- Arbitrary File Upload Vulnerability Range Clearance 6-15 Levels] Arbitrary File Upload Vulnerability Range Clearance, allowing you to have a deeper understanding of file upload vulnerabilities and bypass methods, ideas and skills - CSDN Bloghttps ://blog.csdn.net/m0_67844671/article/details/134114898?spm=1001.2014.3001.5502The article has been viewed and read 901 times, liked 3 times, and collected 2 times. [Network Security--- Arbitrary File Upload Vulnerability Range Clearance 6-15 Levels] Arbitrary File Upload Vulnerability Range Clearance, allowing you to have a deeper understanding of file upload vulnerabilities and bypass methods, ideas and skills

Then access it through a browser

It can be seen that it is inaccessible by default. We only need to add /tu.php after the path, and it can be parsed according to PHP, which is directly a vulnerability. Because we can upload images normally, after uploading, if it is parsed by nginx and the cgi.fix_pathinfo function is turned on, then it is basically taken down by you.

Other forms of vulnerability

www.xxxx.com/UploadFiles/image/1.jpg/1.php, this is the vulnerability mentioned above
www.xxxx.com/UploadFiles/image/1. jpg%00.php #We have tried this 00 truncation. In addition to apache, nginx also has this 00 truncation vulnerability. The effect of this is: 1.jpg will be parsed as a php file.

www.xxxx.com/UploadFiles/image/1.jpg/%20\0.php #It is also considered a type of 00 truncation

xxx.jpg%00.php (Nginx <0.8.03 version has null byte code execution vulnerability)

Repair plan :

1. Modify the php.ini file and set the value of cgi.fix_pathinfo to 0;

2. Add the following code to the Nginx configuration file:

if ( $fastcgi_script_name ~ ..*/.*php ) {
 return 403;
}

What this line of code means is that when a URL like test.jpg/a.php is matched, a 403 error code will be returned.

2-4 IIS7.x parsing vulnerability

The vulnerabilities of IIS7.5 are similar to those of nginx. They are all due to the fact that cgi.fix_pathinfo is turned on in the php configuration file (php.ini file). This is not a vulnerability of nginx or iis7.5 itself, but is caused by improper configuration.

PHP - - phpStudy

After the installation is completed, the default cgi.fix_pathinfo=1 in php.ini. When accessing it, adding the .php suffix after the URL path will be parsed as a php file, and the vulnerability arises.

php.ini file configuration

Although we found that there is this vulnerability through configuration, during the actual testing process, it is not that simple, as follows. Note that the following example is demonstrated using the phpstudy2016 version, win7 and above The system only works, but win2003 does not work. When you check iis, you may be prompted that you have not installed iis 7/8. You can install it yourself. Follow the official website of phpstudy to install: PHP - - phpStudy. Don’t forget to activate the CGI function.

Your phpstudy may report an error

Solution: Install vc9 tool

Put it on our win7 virtual machine

Install

After a while, you will be prompted that the installation is complete, and you can restart phpstudy. If you are prompted that the website running port conflicts, we can change the port. According to the installation and configuration of the document, when we access the picture below our iis website

According to the parsing vulnerability method of iis, write the following access URL:

Still getting an error, you need to perform the following configuration to see the effect.

Find the website code storage directory to deploy the website:

Note: During the actual test, iis was not directly exploitable like nginx, and it was found that the vulnerability was not generated. Later, it was discovered that the restrictions on FastCGI calling should be removed, as follows, and the check mark is removed.

The effect is as follows

So you will find that if you want to use this vulnerability, higher versions require a lot of configuration, so this vulnerability generally does not appear.

This ends the common parsing vulnerabilities in middleware. The next blog file contains vulnerabilities.