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版本无关,属于用户配置不当造成的解析漏洞
文章来源
您阅读本篇文章共花了：
发表评论