Nginx漏洞复现的问题案例解析

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 :80systemctl 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版本无关,属于用户配置不当造成的解析漏洞

到此这篇关于Nginx解析漏洞复现的文章就介绍到这了,更多相关Nginx漏洞复现内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论