浅谈“Web服务器解析漏洞”

一：漏洞名称：

Web服务器解析漏洞

描述：

服务器相关中间件存在一些解析漏洞，攻击者可通过上传一定格式的文件，被服务器的中间件进行了解析，这样就对系统造成一定危害。常见的服务器解析漏洞涉及的中间件有IIS，apache、nginx、等

检测条件：

Web业务运行正常。

检测方法：

以下为常见的各大web服务器所出现过的解析漏洞汇总，在检测时刻参考：

1、IIS 6.0

目录解析：/xx.asp/xx.jpg  xx.jpg可替换为任意文本文件(e.g. xx.txt)，文本内容为后门代码 IIS6.0会将 xx.jpg 解析为 asp 文件。

后缀解析：/xx.asp;.jpg     /xx.asp:.jpg(此处需抓包修改文件名) IIS6.0都会把此类后缀文件成功解析为 asp 文件。

默认解析：/xx.asa    /xx.cer   /xx.cdx IIS6.0默认的可执行文件除了 asp 还包含这三种此处可联系利用目录解析漏洞/xx.asa/xx.jpg 或/xx.cer/xx.jpg 或 xx.asa;.jpg

2、IIS 7.0/IIS 7.5/Nginx <8.03

IIS 7.0/IIS 7.5/Nginx<8.03 在默认Fast-CGI开启状况下,在一个文件路径(/xx.jpg)后面加上/xx.php会将/xx.jpg/xx.php 解析为 php 文件。常用利用方法：将一张图和一个写入后门代码的文本文件合并将恶意文本写入图片的二进制代码之后，避免破坏图片文件头和尾:

copy xx.jpg/b + yy.txt/a xy.jpg

/b 即二进制[binary]模式/a 即ascii模式   xx.jpg为正常图片文件  

yy.txt 内容：');?>

意思为写入一个内容为名称为shell.php的文件

找个地方上传 xy.jpg ,然后找到 xy.jpg 的地址，在地址后加上/xx.php 即可执行恶意文本。然后就在图片目录下生成一句话木马 shell.php 密码 cmd

3、Nginx <8.03

在Fast-CGI关闭的情况下，Nginx<8.03依然存在解析漏洞在一个文件路径(/xx.jpg)后面加上%00.php会将/xx.jpg%00.php解析为 php 文件，这就是%00截断，具体实验可参考：（博客正在准备着）

4、Apache

后缀解析：test.php.x1.x2.x3  Apache将从右至左开始判断后缀，若x3非可识别后缀，再判断x2，直到找到可识别后缀为止，然后将该可识别后缀进解析  test.php.x1.x2.x3 则会被解析为php 经验之谈：php|php3|phtml 多可被Apache解析

5、其他一些可利用的：

在windows环境下，xx.jpg[空格]或xx.jpg.这两类文件都是不允许存在的，若这样命名，windows会默认除去空格或点，这也是可以被利用的！在向一台windows主机上传数据时，你可以抓包修改文件名，在后面加个空格或点，试图绕过黑名单，若上传成功，最后的点或空格都会被消除，这样就可得到shell。我记得FckPhp2.6就存在加空格绕过的漏洞。{Linux主机中不行，Linux允许这类文件存在}如果在Apache中.htaccess可被执行（默认不执行，这是90sec里的一位朋友说的，当初我并不知道），且可以被上传，那可以尝试在.htaccess中写入:SetHandler application/x-httpd-php shell.jpg换成你上传的文件，这样shell.jpg就可解析为php文件。

漏洞修复：

1.针对IIS解析漏洞（另详见本文末尾，其他补充说明中详细方法）：

程序方面：

1、对新建目录文件名进行过滤，不允许新建包含.的文件夹。

2、取消网站后台新建目录的功能,不允许新建目录。

3、及时打取中间件补丁。

服务器方面：

1、限制上传目录的脚本执行权限，不允许执行脚本。

2、过滤.asp/xm.jpg,通过ISApi组件过滤。 在httpd.ini加入了以下规则 ASP

RewriteRule (.*).asp/(.*) /no.gif RewriteRule (.*).Asp/(.*) /no.gif RewriteRule (.*).aSp/(.*) /no.gif RewriteRule (.*).asP/(.*) /no.gif

2.针对Nginx解析漏洞：

1、修改php.ini，设置cgi.fix_pathinfo = 0;然后重启php-cgi。此修改会影响到使用PATH_INFO伪静态的应用，例如我以前博文的URL：http://blog.zyan.cc/read.php/348.htm 就不能访问了；

2、在nginx的配置文件添加如下内容后重启：if ( $fastcgi_script_name ~ \..*\/.*php ) {return 403;}。该匹配会影响类似 http://www.domain.com/software/5.0/test.php（5.0为目录），http://www.domain.com/goto.php/phpwind 的URL访问.

3、对于存储图片的location{...}，或虚拟主机server{...}，只允许纯静态访问，不配置PHP访问。例如在金山逍遥网论坛、SNS上传的图片、附件，会传送到专门的图片、附件存储服务器集群上（pic.xoyo.com），这组服务器提供纯静态服务，无任何动态PHP配置。各大网站几乎全部进行了图片服务器分离，因此Nginx的此次漏洞对大型网站影响不大。

4、修改nginx.conf配置文件的临时解决方法，兼容“http://blog.zyan.cc/demo/0day/phpinfo.php/test”的PATH_INFO伪静态，拒绝“http://blog.zyan.cc/demo/0day/phpinfo.jpg/test.php”的漏洞攻击，代码如下：

location ~* .*\.php($|/)
{
      if ($request_filename ~* (.*)\.php) {
            set $php_url $1;
      }

      if (!-e $php_url.php) {
            return 403;
      }

      fastcgi_pass  127.0.0.1:9000;
      fastcgi_index index.php;
      include fcgi.conf;
}

 

3.针对Apache解析漏洞：

用伪静态能解决这个问题，重写类似 .php.*这类文件：

打开apache的httpd.conf

找到LoadModule rewrite_module modules/mod_rewrite.so

把#号去掉，重启apache，在网站根目录下建立 .htaccess文件，代码如下：



RewriteEngine On
RewriteRule .(php.|php3.) /index.php
RewriteRule .(pHp.|pHp3.) /index.php
RewriteRule .(phP.|phP3.) /index.php
RewriteRule .(Php.|Php3.) /index.php
RewriteRule .(PHp.|PHp3.) /index.php
RewriteRule .(PhP.|PhP3.) /index.php
RewriteRule .(pHP.|pHP3.) /index.php
RewriteRule .(PHP.|PHP3.) /index.php



根据自己要求修改自己定义的执行php的后缀，用|隔开就行。 /index.php可以换成你想要显示的文件。

 

4.其他解决方案：使用McAfee VirusScan软件的访问保护中的自定义规则，新建文件/文件夹阻挡规则，配置：规则名称随便填写，要包含的进程填*，要阻止的文件夹或文件名中写**\*.asp\*.*，以上方法很简单，是对整个服务器进行设置的。

其他补充说明：

Nginx (来自：https://segmentfault.com/a/1190000016026991)

      Nginx默认是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通过正则匹配设置SCRIPT_FILENAME。当访问www.xxx.com/phpinfo.jpg/1.php这个URL时，$fastcgi_script_name会被设置为“phpinfo.jpg/1.php”，然后构造成SCRIPT_FILENAME传递给PHP CGI，但是PHP为什么会接受这样的参数，并将phpinfo.jpg作为PHP文件解析呢?
这就要说到fix_pathinfo这个选项了。如果开启了这个选项，那么就会触发在PHP中的如下逻辑：
PHP会认为SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就会将phpinfo.jpg作为PHP文件来解析了。

Nginx的解析漏洞实质上是实际上是PHP CGI解析漏洞。
这不是Nginx特有的漏洞，在IIS7.0、IIS7.5、Lighttpd等Web容器中也经常会出现这样的解析漏洞。

例如：
可以在后面添加/任意文件名.php 的解析漏洞，比如原本文件名是 test.jpg，可以添加为test.jpg/x.php 进行解析攻击。

还有一种是对低版本的 Nginx 可以在任意文件名后面添加 %00.php 进行截断解析攻击。
例如：test.php%00.jpg
00截断的两种具体操作方式：
 1、更改文件名为xxx.php .jpg，在Burpsuit的Hex选项中将空格对应的20改为00。

 2、更改文件名为xxx.php%00.jpg，在Burpsuit中将%00进行右键转换->URL->URL-decode。

 

（注意：用copy命令制作图片木马：copy 1.jpg/b+1.php/a xxx.php （/b表示二进制文件，/a表示ASCII码文件)，然后，使用菜刀连接市上传的xxx.php文件）

 

 

IIS 6.0畸形文件扩展名解析漏洞修复方案：

漏洞扫描规避

规避方式一

参考配URL整改，取消返回Server:Mircrosoft/IIS 6.0HTTP头。

http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx

 

规避方式二

 该漏洞是基于扫描端口Banner版本报出的，修改IIS Banner信息可以降低该漏洞被发现的概率，修改步骤：

1、复制c:\windows\system32\dllcache\w3core.dll 文件备份两次（方便描述以下用A、B区分——A用于修改，B用来备份）。

2、用Uedit32或者winhex打开复制的w3core.dll（A），直接搜索关键字“6.0”，要勾选“ascii”。搜索到了，将6.0改成8.0后保存。

 

3、将A复制到“c:\windows\system32\dllcache\”替换原有的w3core.dll。

4、停止IIS Admin Service服务，将A复制到“c:\windows\system32\inetsrv\”替换原有的w3core.dll。(此处不停止IIS服务该文件不能被替换。)

5、启动IIS Admin Service服务，然后对该服务再重启次，不行就重启系统。

 

提示：

1、w3core.dll文件记录了IIS的版本，本方法通过修改该文件达到修改IIS Banner目的。

2、Windows对重要dll文件有保护机制，c:\windows\system32\dllcache\中为Windows的dll备份目录，系统发现重要dll被修复时，会将该目录的dll文件，还原替换被修改的dll。故需要先替换该目录下的w3core.dll文件。

 

注意事项：

1、修改、删除或替换dll文件前，做好备份。

2、建议在测试机器上测试是否有效，再对业务机器修改。

以上参考： http://www.2cto.com/Article/201111/110201.html

 

漏洞利用规避

该漏洞经以上方法修改后仍然存在,只有通过平台改造到windowsServer 2008/2012——IIS7以上，或者使用Apahce/Tomcat等其他中间件才能彻底修复这个问题。如部改造，可使用以下方法防止漏洞利用：

1、对网站中上传目录配置限制脚本执行权限，以防止上传到服务器的webshell等恶意文件无法执行。

 

2、应用程序应对上传文件名称进行重命名。如上传恶意文件webshell.asp;.doc，对其重命名成85f9e396cf16200119f100757a6e8da1.doc（可对原文件名进行md5哈希运算值作为新的文件名）。如不进行此文件重命名操作，上传到存在此漏洞的webshell.asp;.doc文件会被解析成webshell.asp来执行。

3、使用IIS Rewirte进行漏洞加固。参考：

http://bbs.qibosoft.com/read-forum-tid-407332.htm