Apache、Nginx、IIS文件解析漏洞_nginx容器存在的漏洞?

目录

1、文件解析漏洞介绍

2、Apache相关的解析漏洞

（1）多后缀解析漏洞

（2）Apache配置问题

（3）换行符解析漏洞

（4）罕见后缀解析

3、Nginx相关的解析漏洞

（1）Nginx PHP CGI 解析漏洞(fix_pathinfo)

（2）空字节代码执行漏洞

（3）nginx文件名逻辑漏洞(CVE-2013-4547)

4、IIS相关的解析漏洞

（1）IIS 5.x和IIS 6.x解析漏洞

1目录解析(6.0)

2.文件解析(6.0)

3.解析文件类型(默认解析后缀)

（2）IIS 7.0/7.5 CGI解析漏洞

---

最近在学习解析漏洞，在这里参考几个大佬写好的文章来进行一个学习+练习

1、文件解析漏洞介绍

文件解析漏洞主要由于网站管理员操作不当或者 Web 服务器自身的漏洞，导致一些特殊文件被 IIS、apache、nginx 或其他 Web服务器在某种情况下解释成脚本文件执行。

其中存在的大部分的解析漏洞是由于web服务器自身配置错误的漏洞，导致特殊文件被当成脚本文件执行。

2、Apache相关的解析漏洞

（1）多后缀解析漏洞

漏洞描述：在存在多后缀解析漏洞版本的Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断，直到找到可以解析的文件。

所以可上传一个test.php.qwzf文件绕过验证且服务器在解析test.php.qwzf不成功后，依然会向前进行查找，找到了tet.php，可以解析，那么就会将test.php.qwzf作为php来进行解析。

Apache 能够识别的文件在mime.types文件里。

影响版本：

Apache 2.0.x <= 2.0.59

Apache 2.2.x <= 2.2.17

Apache 2.2.2 <= 2.2.8

测试：

这里测试使用vulhub靶场，进入到下列路径中，使用docker-compose拉取环境：

/root/vulhub-master/httpd/apache_parsing_vulnerability

拉取完环境后，进入到容器中查看apache版本

尝试在浏览器中访问：

可以看到是一个文件上传漏洞，那么尝试上传一个php文件看看：

可以看到提示我们上传的文件类型不支持，因此尝试上传一个jpg文件

可以看到上传成功了，尝试访问：

可以看到也是陈工国的访问到了，那么下面就可以尝试对一个php文件进行处理，修改名称为phpinfo.php.jpg后再次上传：

可以看到成功上传了，尝试访问但是却没有解析成功

看了靶场的官方文档，是这样说的：如果运维人员给.php后缀增加了处理器：

AddHandler application/x-httpd-php .php

那么，在有多个后缀的情况下，只要一个文件含有.php后缀的文件即将被识别成PHP文件，没必要是最后一个后缀。利用这个特性，将会造成一个可以绕过上传白名单的解析漏洞。

那么应该是配置文件的问题，查看配置文件：

发现配置文件并没有问题啊，按道理应该是可以解析的啊

后来看到网上的案例才发现是操作错了

应该是上传一个php文件的同时使用burpsuite抓包，尝试上传php文件会发现不支持：

然后这里尝试修改后缀如下后再次上传：

可以看到上传成功了，尝试访问上传成功的图片

可以看到成功解析了

（2）Apache配置问题

注：很多中间键导致的漏洞都是运维人员手动配置时配置不当导致的

漏洞描述：

apache中的/etc/apache2/apache2.conf里如果有这样的配置

<FilesMatch "qwzf.jpg">  SetHandler application/x-httpd-php</FilesMatch>

这时只要文件名是qwzf.jpg，会以php 来执行。

或者如果在Apache的 conf 里有这样一行配置

AddHandler php5-script .php

这时只要文件名里包含.php 即使文件名是qwzf.php.jpg也会以php 来执行。

或者如果在 Apache 的 conf 里有这样一行配置

AddType application/x-httpd-php .jpg

这时即使扩展名是.jpg，也会以php来执行。

Apache提供了一种很方便的、可作用于当前目录及其子目录的配置文件——.htaccess(分布式配置文件)

前提条件

将Apache的/etc/apache2/sites-available/default里AllowOverride None改为

1.AllowOverride All

AllowOverride All

2.开启rewrite_mod

a2enmod rewrite

这样.htaccess文件才会生效。

（3）换行符解析漏洞

Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。

其2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，1.php\x0A将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。

漏洞描述：上传一个后缀末尾包含换行符的文件，来绕过FilesMatch。绕过FilesMatch不一定能被PHP解析。

这个漏洞可以用来绕过文件上传黑名单限制。即：

1.php\x0a => 1.php

apache通过mod_php来运行脚本，其2.4.0-2.4.29中存在apache换行解析漏洞，在解析php时xxx.php\x0A将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。

该漏洞属于用户配置不当产生的漏洞，与具体中间件版本无关。

影响版本：Apache 2.4.0-2.4.29

测试：

这里还是用vulhub中的环境，移动到下列目录中，使用docker-compse拉取环境：

/root/vulhub-master/httpd/CVE-2017-15715

环境拉取完成后，我们尝试在浏览器中访问一下：

可以看到这里我们可以上传文件，并且可以命名文件的名字，尝试上传一个php文件

可以看到返回 bad file

这里在phpinfo.php后面插入一个+：

在Hex中对插入的值进行修改，修改为

修改完成后，可以看到这里确实是有一个换行的操作，然后再次尝试发送：

可以看到发送成功了

访问上传后的文件：

可以看到成功的解析了

（4）罕见后缀解析

Apache配置文件中会有.+.ph(p[345]?|t|tml)此类的正则表达式，被当php程序执行的文件名要符合正则表达式。

也就是说php3，php4，php5，pht，phtml等文件后缀也是可以被当作php文件进行解析的。

这里就可以用uploads-labs靶场的第3关来进行测试

尝试上传php文件

会发现不能上传，尝试上传php3文件

可以看到上传成功了，尝试访问发现也成功的解析了

3、Nginx相关的解析漏洞

（1）Nginx PHP CGI 解析漏洞(fix_pathinfo)

漏洞描述：

（1）Nginx默认是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通过正则匹配设置SCRIPT_FILENAME。

当访问http://x.x.x.x/phpinfo.jpg/1.php这个URL时，$fastcgi_script_name会被设置为phpinfo.jpg/1.php，然后构造成SCRIPT_FILENAME传递给PHP CGI。

（2）但PHP为什么会接受这样的参数，并将phpinfo.jpg作为PHP文件解析呢? 这就涉及到fix_pathinfo选项了。

如果PHP中开启了fix_pathinfo这个选项，PHP会认为SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就会将phpinfo.jpg作为PHP文件来解析了。

简单来说，由于Nginx的特性，只要URL中路径名以.php结尾，不管该文件是否存在，直接交给php处理。

注：新版本php引入了security.limit_extensions，限制了可执行文件的后缀，默认只允许执行.php文件 使得该漏洞难以被成功利用

相关知识：

（1）通过phpinfo查看cgi.fix_pathinfo=1，PHP里经常要获取当前请求的URL路径信息。

一般可以通过环境变量$_SERVER[‘PATH_INFO’]获取，而配置文件中的cgi.fix_pathinifo选项则与这个值的获取相关。

（2）在PHP的配置文件中有一个关键的选项cgi.fix_pathinfo默认是开启的，当URL中有不存在的文件，PHP就会向前递归解析。

影响版本：漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞

测试：

这里测试的环境还是使用vulhub靶场，移动到如下目录中，然后拉取环境：

/root/vulhub-master/nginx/nginx_parsing_vulnerability

环境拉取完成后，尝试在浏览器访问：

只是一张图片，没有进行解析，这里就需要利用nginx  php cgi解析漏洞的，我们访问如下链接：

图片url/.php

可以看到这里就成功的进行了解析

修复方法：

1.修改php.ini文件，将cgi.fix_pathinfo的值设置为0(慎用); 若实在将cgi.fix_pathinfo的值设置为0，就将php-fpm.conf中的security.limit_extensions后面的值设置为.php

2.在Nginx配置文件中添加以下代码：

if ( $fastcgi_script_name ~ ..*/.*php ) {return 403;}

代码的意思：当匹配到类似test.jpg/a.php的URL时，将返回403错误代码。

3.使用Apache服务器的，在相应目录下放一个 .htaccess 文件，内容为：

<FilesMatch "(?i:\.php)$">    Deny from all</FilesMatch>

4.不提供上传的原文件访问，对文件输出经过程序处理。5.图片单独放一个服务器上，与业务代码数据进行隔离。

（2）空字节代码执行漏洞

漏洞描述：Ngnix在遇到%00空字节时与后端FastCGI处理不一致，导致可以在图片中嵌入PHP代码然后通过访问xxx.jpg%00.php来执行其中的代码

影响版本: Nginx 0.5.x Nginx 0.6.x Nginx 0.7-0.7.65 Nginx 0.8-0.8.37

测试流程：

1.上传一个xxx.jpg图片文件

2.访问http://x.x.x.x/xxx.jpg％00.php

3.就会将xxx.jpg作为PHP文件进行解析

修复方法：

1.升级nginx

2.禁止在上传文件目录下执行php文件

3.在nginx配置或者fcgi.conf配置添加下面内容：

if ($request_filename ~* (.*)\.php) {    set $php_url $1;}if (!-e $php_url.php) {    return 403;}

（3）nginx文件名逻辑漏洞(CVE-2013-4547)

漏洞描述：

1.漏洞产生原因：错误地解析了请求的URL,错误地获取到用户请求的文件名,导致出现权限绕过、代码执行的连带影响。

2.漏洞原理：Nginx匹配到.php结尾的请求，就发送给fastcgi进行解析，常见写法：

location ~ \.php$ {    include        fastcgi_params;    fastcgi_pass   127.0.0.1:9000;    fastcgi_index  index.php;    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;    fastcgi_param  DOCUMENT_ROOT /var/www/html;}

（1）在关闭fix_pathinfo的情况下(即cgi.fix_pathinfo=0)，只有.php后缀的文件才会被发送给fastcgi解析

（2）存在CVE-2013-4547时，请求qwzf.jpg[0x20][0x00].php，这个URI可匹配到正则\.php$，进入到Location块；

（3）进入后，Nginx错误地认为请求的文件是qwzf.jpg[0x20]，然后设置其为SCRIPT_FILENAME的值发送给fastcgi。

（4）fastcgi根据SCRIPT_FILENAME的值，将qwzf.jpg[0x20]以php文件的形式进行解析，从而造成了解析漏洞。也就是说，我们只需要上传一个空格结尾的文件，即可用PHP进行解析。

影响版本: Nginx 0.8.41-1.4.3 Nginx 1.5 -1.5.7

测试：

这个还是使用vulhub靶场，移动到如下路径，然后拉取环境

/root/vulhub-master/nginx/CVE-2013-4547

拉取环境后，在浏览器中尝试访问，可以看到是一个上传文件的功能

上传一个jpg文件，文件名为pp.jpg，文件内容为(或者上传图片马)：

使用burp添加aa.php

使用burp的hex功能，对aa的十六进制进行修改：

发包，可以看到成功上传：

尝试访问该文件：

还是同样的操作需要增加aa.php并且修改aa的hex值->20 00 

可以看到成功的访问到，并且解析了

4、IIS相关的解析漏洞

（1）IIS 5.x和IIS 6.x解析漏洞

使用iis5.x-6.x版本的服务器，大多为windows server 2003，网站比较古老，开发语言一般为asp；该解析漏洞也只能解析asp文件，而不能解析aspx文件。

测试环境：因为找不到相关环境，所以这里只阐述相关原理和相关知识。

1目录解析(6.0)

形式：http://www.xxx.com/xx.asp/xx.jpg

原理: 服务器默认会把.asp，.asa目录下的文件都解析成asp文件。

2.文件解析(6.0)

形式：http://www.xxx.com/xx.asp;.jpg

原理：服务器默认不解析;号后面的内容，因此xx.asp;.jpg便被解析成asp文件。

3.解析文件类型(默认解析后缀)

有的网站会设置黑名单上传限制 ,IIS6.0 默认的可执行文件除了asp还包含这三种 :

/xx.asa/xx.cer/xx.cdx

iis把asa，cdx，cer解析成asp文件的原因：这四种扩展名都是用的同一个asp.dll文件来执行。

修复方法：

1.阻止创建.asp和.asa类型的文件夹

2.阻止上传xx.asp;.jpg类型的文件名

3.阻止上传.asa、.cer和.cdx后缀的文件

4.设置权限，限制用户创建文件夹

（2）IIS 7.0/7.5 CGI解析漏洞

漏洞描述：IIS7/7.5的漏洞与nginx的类似，都是由于php配置文件中，开启了cgi.fix_pathinfo，而这并不是nginx或者iis7/7.5本身的漏洞。

漏洞产生的条件：php.ini里的cgi.cgi_pathinfo=1 IIS7在Fast-CGI运行模式下

常用利用方法：上传图片马

到此，Nginx/Apache/IIS相关的解析漏洞就暂时学习完成了

参考链接：

浅谈解析漏洞的利用与防范-安全客 - 安全资讯平台

文件解析漏洞-CSDN博客

Nginx常见的中间件漏洞_nginx常见漏洞-CSDN博客

Vulhub - Docker-Compose file for vulnerability environment

文件上传漏洞：upload-labs靶场通关_文件上传漏洞靶场闯关教程-CSDN博客