Vulnerability Description : Nginx is a high-performance Web server, the use of a very broad, not only often used as a reverse proxy, but also very good support for PHP operation. 80sec found that there is a more serious security problem, by default, may cause the server error will be any type of file in PHP parsing, which will lead to serious security problems, so that a malicious attacker may compromise the PHP-supported Nginx server.
Vulnerability Analysis : Nginx by default in CGI to support the operation of PHP, such as in the configuration file can be
1 location ~. php$ { root html; 3 fastcgi_pass 127.0.0.1:9000; 4 Fastcgi_index index. php; 5 fastcgi_param script_filename/scripts$ Fastcgi_script_name ; 6 include Fastcgi_params; 7 }
To support the parsing of PHP, location to select the request will use the URI environment variable to choose, which passed to the backend fastcgi key variable script_filename generated by Nginx $fastcgi_script_ Name, and through the analysis you can see that the $fastcgi_script_name is directly controlled by the URI environment variable, and here is the point where the problem arises. In order to better support the extraction of path_info, there is a cgi.fix_pathinfo option in the PHP configuration option, which is intended to remove the real script name from the Script_filename.
So suppose there is a http://www.80sec.com/80sec.jpg, and we go to the following way to access
1 http://www.80sec.com/80sec.jpg/80sec.php
You will get a URI
1 /80sec.jpg/80sec.php
After the location instruction, the request will be given to the backend fastcgi processing, Nginx set the environment variable script_filename, the content is
1 /scripts/80sec.jpg/80sec.php
In other webserver such as lighttpd, we find that the Script_filename is correctly set to
1 /scripts/80sec.jpg
Therefore, this problem does not exist.
FastCGI of the backend when this option is accepted, the Fix_pathinfo configuration determines whether additional processing is performed on the Script_filename, in general, if the Fix_pathinfo is not set to affect the use of path_ Info is used for routing, so this option is generally configured to open. PHP through this option will find the real script file name, look for the way to see if the file exists, this time will be separated out script_filename and Path_info respectively
1 /scripts/80sec.jpg and 80sec.php
Finally, with/scripts/80sec.jpg as the script to be executed for this request, an attacker could enable nginx to parse any type of file in PHP.
POC: Access a nginx to support PHP site, in a file of any resources such as robots.txt after adding/80sec.php, this time you can see the following differences:
Visit http://www.80sec.com/robots.txt
1 http/1.1 OK 2 server:nginx/0.6.32 3 Date:thu, 10:05:30 GMT 4 Content-type:text/plain 5 content-length:18 6 Last-modified:thu, 06:26:34 GMT 7 connection:keep-alive 8 keep-alive:timeout=20 9 Accept-ranges:bytes
Access Access http://www.80sec.com/robots.txt/80sec.php
1 http/1.1 OK 2 server:nginx/0.6.32 3 Date:thu, 10:06:49 GMT 4 content-type:text/html 5 transfer-encoding:chunked 6 connection:keep-alive 7 keep-alive:timeout=20 8 x-powered-by:php/5.2.6
The changes in content-type indicate that the backend is responsible for parsing changes, and that the site may be vulnerable.
Vulnerability Manufacturer: http://www.nginx.org
Solution :
We have tried to contact the official, but before you can reduce the loss by the following ways
1 off Cgi.fix_pathinfo to 0
Or
1 if $fastcgi _script_name ~. */.*php) {2return 403; 3 }
PS: Thanks to laruence Daniel's help in the analysis process.
Original source: http://www.80sec.com/nginx-securit.html
Nginx file type Error parsing vulnerability