Nginx错误配置引发的解析漏洞复现

Nginx错误配置引发的解析漏洞复现

首先说明,漏洞与Nginx、php版本无关,属于用户配置不当造成的解析漏洞,也就是增加`/.php`后缀,被解析成PHP文件。还是用的vulhub的漏洞环境,先看提供的图片。

图片最后是写入了phpinfo的代码的,我们浏览器打开这张图片。这里我就不演示文件上传部分了,因为漏洞本身不在上传部分。

图片是正常加载的,但是如果在图片url后增加`/.php`后缀会怎样呢?

现在看看nginx的配置文件时如何写的,漏洞出现在哪里。

    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;
   }

根据这段错误配置可见nginx把以’.php’结尾的文件交给fastcgi处理,所以我们构造的http://ip/uploadfiles/nginx.png/.php也是交给fastcgi处理的。

通过phpinfo查看cgi.fix_pathinfo=1,PHP里经常要获取当前请求的URL路径信息。一般可以通过环境变量$_SERVER[‘PATH_INFO’]获取,而配置文件中的cgi.fix_pathinifo选项则与这个值的获取相关。

cgi.fix_pathinfo的默认值是1。nginx默认是不会设置PATH_INFO环境变量的的值,需要通过正则匹配设置SCRIPT_FILENAME,但这样会带来安全隐患,需要把cgi.fix_pathinfo=0设置为0。但是一旦关闭这个,PHP就获取不到PATH_INFO信息,那些依赖PATH_INFO进行URL美化的程序就失效了。

所以fastcgi在处理’.php’文件时发现文件并不存在,这时php.ini配置文件中cgi.fix_pathinfo=1 发挥作用,这项配置用于修复路径,如果当前路径不存在则采用上层路径。这里’/nginx.png’就交由fastcgi处理了。

另外php-fpm.conf中的security.limit_extensions配置项限制了fastcgi解析文件的类型,此项设置为空的时候才允许fastcgi将’.png’等文件当做代码解析。所以我们可以限制fpm允许解析的脚本扩展名,这样就能预防web服务器配置的错误。

我们修改配置文件后再重启环境,此时相当于设置了白名单,仅允许php的后缀可以解析执行。

所以对于该漏洞的处理办法,如果实在不能关闭cgi.fix_pathinifo选项的情况下,就将php-fpm.conf中的security.limit_extensions后面的值设置为.php,尽可能降低漏洞危害。

zgao

如果有什么技术上的问题,可以加我的qq 1761321396 一起交流。