Nginx解析漏洞复现

一、搭建环境

环境需求：ubuntu虚拟机，docker环境，vulhub-master环境

这里我使用的Linux系统为Ubuntu22.04版本，已经准备完毕（比如换源，安装docker等操作）

1、通过FTP将vulhub-master.zip环境包上传并进行解压

这里我已将环境包上传至root主目录下，下面进行解压：

unzip vulhub-master.zip

2、进入vulhub-master/nginx/nginx_parsing_vulnerability此目录下制作镜像

cd /root/vulhub-master/nginx/nginx_parsing_vulnerability
docker-compose up -d

这里我们可能会碰见几种报错，实则不难，网上查下便知。下面我罗列一种：
如果出现下图这种情况：

这里其实是因为80端口被占用，冲突了，所以我们可以查下是哪个进程占用导致的：

lsof -i :80
systemctl stop nginx

我们可以看到是nginx占用了80端口，所以我停止了nginx的进程并再次查看，可以看到已经没有了，下面我们继续重新启动容器。

到这里我们的环境也已经搭建完毕。

二、复现过程

1、访问http://your-ip/uploadfiles/nginx.png

这里我们可以看到是正确显示的。

2、访问http://your-ip/uploadfiles/nginx.png/.php来查看效果

这里我们可以看到被解析为PHP文件了。
这里其实原本一张图片怎么会解析为php代码呢，按理说就比如自己上传一张图片然后去查看并解析为php可以试下，即如下图所示：

这里我们可以看到是报错了，所以我们再来看看nginx这张图片：

这里我们很明显看到里面添加了一句话木马。所以这里其实是执行了这个一句话木马，我们可以有一个思路便是自己创建图片并加入一句话木马去执行，然后使用蚁剑连，所以这里肯定是存在上传漏洞的。

三、漏洞原理及防范

这里我第一个想到的便是nginx的配置文件，如下图所示：

root@zyan-virtual-machine:/etc/nginx/conf.d# docker ps -a
CONTAINER ID   IMAGE     COMMAND                  CREATED             STATUS             PORTS                                                                      NAMES
1da527cab3cc   nginx:1   "/docker-entrypoint.…"   About an hour ago   Up About an hour   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   nginx_parsing_vulnerability_nginx_1
556fe6cc6fda   php:fpm   "docker-php-entrypoi…"   About an hour ago   Up About an hour   9000/tcp                                                                   nginx_parsing_vulnerability_php_1
root@zyan-virtual-machine:/etc/nginx/conf.d# docker exec -it 1da527cab3cc /bin/bash
root@1da527cab3cc:/# cd /etc/nginx/conf.d/
root@1da527cab3cc:/etc/nginx/conf.d# ll
bash: ll: command not found
root@1da527cab3cc:/etc/nginx/conf.d# cat default.conf 
server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /usr/share/nginx/html;
        index index.html index.php;
        server_name _;
        location / {
                try_files $uri $uri/ =404;
        }
        location ~ \.php$ {
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param  REDIRECT_STATUS    200;
                fastcgi_param  SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
                fastcgi_param  DOCUMENT_ROOT /var/www/html;
                fastcgi_pass php:9000;
        }
}root@1da527cab3cc:/etc/nginx/conf.d# 

其实这里我们可以看到是没有问题的。~是匹配任意值，同目录在/var/www/html上，同时监听PHP端口在9000上。虽然说这个漏洞我知道是由于配置不当导致的，但是我在这里并没有找到配置不当的地方。
下面我想到了php-fpm，php的支持环境嘛，这里我们可以看到它的配置文件：

我们进去配置文件里面即可看到：

这里其实就是后缀安全限制为空的意思，同时php的解析过程其实是从最后一个php开始解析的，最后一个没有，那么就解析上一级的，如下图：

所以说如果我们在这里最后加上.php我们就会看到这里先解析最后一个，发现没有，解析上一级，就会发现是png，然后就一解析了，也就不会造成这一样的漏洞。说明这个配置文件是nginx解析漏洞造成的原因之一。
当然啦，这个配置文件默认其实是有.php的，这个肯定是有这样的需求。
其实还有一个原因，那就是php主配置文件中的cgi.fix_pathinfo;选项，这里我们可以从下图看到这个选项是打开的：

cgi.fix_pathinfo 是 PHP 主配置文件中的一个选项，用于处理 FastCGI 请求中的 PATHINFO 信息。PATHINFO 是在执行 CGI 程序时从 URL 中提取的附加路径信息，常用于通过 URL 传递参数。
具体而言，cgi.fix_pathinfo 的作用是控制是否修复 FastCGI 请求中的 PATH_INFO。当设置为 1 时，表示启用修复，当设置为 0 时，表示禁用修复。

• 当 cgi.fix_pathinfo 启用（设置为 1）时：
  • 如果 PHP 接收到的 FastCGI 请求中没有 PATHINFO 信息，它会尝试根据 SCRIPTNAME 和 REQUESTURI 推断出 PATHINFO。
  • 这种情况下可以使得像 example.com/index.php/some/path 这样的 URL 形式能够正常工作，即使服务器没有实际的文件或目录存在。
• 当 cgi.fix_pathinfo 禁用（设置为 0）时：
  • PHP 不会尝试修复 FastCGI 请求中的 PATH_INFO。
  • 如果 PATH_INFO 不存在，它将保持为空。

禁用 cgi.fix_pathinfo 可以提高安全性，因为启用它可能导致一些安全隐患，尤其是在共享主机环境中。攻击者可能尝试通过构造恶意请求来利用路径信息。
在生产环境中，通常建议将 cgi.fix_pathinfo 设置为 0，以降低潜在的安全风险。确保你的应用程序不依赖于 PATH_INFO 的自动修复，并且能够正常处理 URL 中的路径信息。
所以，就是如果开启，那么php解析时候，就会按照从最后到上一级一级解析。

总结一下，这个漏洞其实是由php.ini中cgi.fix pathinfo选项与php-fpm的配置一起导致的，防范的话，只需在php-fpm配置文件中设置security.limit_extensions=.php，重启一下服务即可。
该漏洞与nginx、php版本无关,属于用户配置不当造成的解析漏洞