[Reprint 20131024] The exploit and repair method of Nginx Server vulnerability

This paper is mainly divided into two parts, the first part introduces the causes of some common security loopholes, the use method, and gives the corresponding solutions; the second part introduces the main contents that need to be concerned in the security reinforcement of nginx.
Nginx (pronunciation with engine x) is a lightweight Web server/reverse proxy server and e-mail (IMAP/POP3) proxy Server, developed by Russian program designer Igor Sysoev, which can run stably in Linux, Windows and other operating systems, characterized by low memory consumption, and strong concurrency.
Like other software, Nginx also has a number of security vulnerabilities that can be exploited to penetrate the Web server.
In the following example, we introduce several security vulnerabilities about nginx and the corresponding exploit methods.

　　 An example of nginx vulnerability Analysis
Nginx file type Error parsing vulnerability
In 2010, the domestic security organization 80SEC found an nginx file type parsing vulnerability, but in fact this is not the vulnerability of nginx itself, but because of the security problems caused by the configuration. Let's examine the vulnerability in detail below.
Vulnerability Analysis: Nginx default is to support PHP parsing in a CGI way, the common practice is to set the script_filename through regular matching in the Nginx configuration file. The configuration file will have something like the following.
The location selects the request using the URI environment variable, where the key variable passed to the backend fastcgi Script_filename is determined by the Nginx-generated $fastcgi_script_name. Through the analysis, we can see that $fastcgi_script_name is directly controlled by the URI environment variable, and here is the point that produces the problem. When accessing the URL of http://192.168.1.103/phpinfo.jpg/1.php, the $fastcgi _script_name is set to "phpinfo.jpg/1.php" and then constructed into Script_ FileName is passed to PHP CGI, but why does PHP accept such parameters and parse phpinfo.jpg as PHP files?
This is going to be the fix_pathinfo option.
If this option is turned on, the following logic is triggered in PHP.
Here, PHP will think Script_filename is phpinfo.jpg, and 1.php is Path_info, so will phpinfo.jpg as a php file to parse.
Vulnerability Hazard: Exploiting this vulnerability, an attacker could parse any file type as a PHP file, which an attacker would typically exploit to obtain a webshell.
Exploit: Assuming that the vulnerability exists in a server, an attacker could obtain webshell by uploading a picture containing a PHP backdoor code, which is a common attack pattern, as shown in.
　　

　　
Solution: Here are two solutions:
First, modify the php.ini file, set the value of Cgi.fix_pathinfo to 0;

Second, add the following code in the Nginx configuration file:
if ($fastcgi _script_name ~ \.. *\/.*php) {
return 403;
}
This line of code means that when a URL similar to test.jpg/a.php is matched, a 403 error code is returned.
A directory traversal vulnerability caused by Nginx configuration errors
In Nginx configuration file, if the AutoIndex option is turned on and a configuration similar to the following is used, a directory traversal vulnerability is created.
When accessing the URL of http://192.168.1.103/test/, it is normal to traverse the html/test/directory, but if you access http://192.168.1.103/test../this URL, you will traverse the previous level directory (html/).
Let's illustrate the vulnerability with an example, and look at the pages returned when normal access occurs.
Now let's look at the page returned after the vulnerability is triggered, as shown in.
　　

　　
With the returned results shown, we can see that we have successfully traversed this vulnerability to its top-level directory.
Here are two ways to solve this problem and choose one.
Now let's verify that the server still has a vulnerability when the above code is used to harden the nginx.
The returned result shows that the vulnerability was not triggered, but instead returned a 404 page that the vulnerability was fixed.

　　 nginx Safety Reinforcement
For Nginx security reinforcement, mainly from the following two aspects: first, the Nginx Web server program itself is safe, such as whether there is a security vulnerability; second, Nginx Web server provides the security features that can be used, this is mainly to check the Nginx configuration is appropriate , whether there is a security issue due to configuration errors.

　　 the choice of Nginx version and installation considerations
When choosing an nginx version, you need to be concerned about security vulnerabilities and version stability. Generally choose the latest stable version, which can strike a balance between stability and security. Before upgrading the Nginx version, it is recommended that the test pass in the test environment before the formal upgrade to avoid other unpredictable problems due to compatibility.
About Nginx security vulnerabilities can be followed by the official Nginx Security Bulletin (http://nginx.org/en/security_advisories.html) or to some other vulnerability publishing platform to find.
It is recommended to use a custom installation path when installing Nginx, and if the default installation path is used, it is easy to be guessed by the attacker and some automated attack tools to facilitate the next attack.

　　 nginx Security Configuration
1. Modify/Hide Nginx banner information
Before a penetration attack on the target server, an attacker would typically have a target information gathering phase, which is the task of acquiring information to the target server through various means, such as obtaining the system version of the target server, the Web, the type of database, and related information. The information acquired at this stage will be directly related to the attacker's next attack approach. Therefore, modify/hide Nginx information will be to some extent can increase the attacker's attack difficulty, also can cheat some automated attack tools.
When installing Nginx under the Linux platform, you can modify the information in "src/core/nginx.h" to achieve the purpose of hiding or customizing the banner information.
Let's take a look at the default content in this file, similar to the one shown in Nginx.h.
　　

　　
When we visit the Nginx server, the server field returns the actual banner information.
We now come from defining the content of nginx.h in the banner information.
　　

　　
After the modification is complete, recompile the Nginx and install it. After the installation is complete, we will revisit the Nginx server and find that the contents returned by the server are custom banner information as shown in.

2. Nginx Log Security
The log is a very important part of the server, and we need to protect it. The same is true on Nginx. Nginx log is stored by default in the logs directory of the installation directory, first to modify the default save path of the log, and then set only allow the administrator to have the log directory Full Control permissions.

3. Nginx permission settings
Nginx permission settings are divided into Nginx operation permission settings and the Site Directory permissions settings two parts.
Nginx Run permissions are what permissions Nginx is running, and running with administrator privileges is a very bad decision. The consequence is that once the attacker succeeds, it will gain direct access to a high-privileged webshell. Therefore, we need to set Nginx to run as a low-privileged identity, which can be implemented by modifying the "nginx.conf" configuration file.
The Site Directory permission settings follow these guidelines:
A) Do not assign execute permissions if the directory has write permissions
b) Do not assign write permissions if the directory has Execute permissions
c) Site upload directory and database directory generally need to assign "write" permission, but must not assign execute permission
D) Other directories are generally assigned only "read" Permissions

[Reprint 20131024] The exploit and repair method of Nginx Server vulnerability