文件解析总结

前言：对于文件解析漏洞，一般会结合文件上传漏洞组合利用，通过讲含有恶意代码的合理的上传的文件解析成为可执行的脚本，从而造成危害。文件解析主要依靠常用的三个WEB容器，所以接下来分别总结。

 

0x00 Apache解析特性：

这个解析主要是apache的特性，对于apache而言，他在处理多后缀的文件（如1.txt.php.aed,des）时会按照从右往左解析的特点，直到遇到自己能够正常识别的扩展名。（其他大部分系统，应用都是从左往右）。

那么apache可以识别哪些后缀，这个就要看apache的配置文件了，在apache的安装路径下面有一个“./conf/mime.types”文件，记录了apache能够识别的文件类型。

不过有一点需要注意的是，这个解析规则是apache的特性，而不是apache的漏洞，于是我发现这尼玛不是随便就能成功的，本人实验时就发现不能识别的扩展名直接显示了源代码，没有按照特性进行识别，而且返回包里面返回了一个304的状态。并没有按照特性向前解析成功。

之后参考了一位博主的博客，最后手动复现一下。

https://blog.csdn.net/wn314/article/details/77074477

 

至于原因嘛，其实很简单。就是我们要知道，apache服务器是不提供脚本解析的功能的，脚本解析要交给php解释器进行。那么这就是问题原因所在了，php解释器识别文件的时候是否也有apache服务器的这种特性呢？很显然没有。不然第一次解析就成功了。也就是说，虽然apache按照他自己的特性将文件识别成为了php文件，但是在他将文件交给解释器进行解释的时候，php解释器并不认为这是自己能够解析的文件，所以没有将其解析。

我们来看看php解析模块的配置文件，就能明白了。

第九行是原本的文件，可以看出，要想被解析成为php文件，就必须符合正则表达式的匹配，而我们第一次测试时显然不符合，那么我们将匹配的表达式进行修改，第二次进行实验。

成功。

那么其实这个特性在进行解析的时候就特别鸡肋了，因为你有可能还需要去修改整个php解释器的配置文件才能实验攻击。

 

 

0x01 Nginx解析漏洞：

1. Nginx中php配置错误导致的解析漏洞：

实现方法大致如此，将木马文件命名为jpg等合法文件，但是在访问时在路径后面添加任意名称的php文件，就可导致jpg文件被解析成为php文件。

路径里的phpinfo.php文件是不存在的，自己随意添加。

这其中的原理涉及到php的一个选项：”cgi.fix_pathinfo”，该值默认为1，表示开启。这个配置的作用就是对文件路径进行“修理”。举个例子，当php遇到文件路径“/aaa.xxx/bbb.yyy/ccc.zzz”时，若“/aaa.xxx/bbb.yyy/ccc.zzz”不存在，则会去掉最后的“/ccc.zzz”，然后判断“/aaa.xxx/bbb.yyy”是否存在，若存在，则把“/aaa.xxx/bbb.yyy”当做文件“/aaa.xxx/bbb.yyy/ccc.zzz”，若“/aaa.xxx/bbb.yyy”仍不存在，则继续去掉“/bbb.yyy”，以此类推。然后实验将选项设置为0，发现无法解析。

出现Access denied。据说出现这种情况是应为高版本的PHP里面新添加了” security.limit_extensions”这个参数，限制了不安全的扩展名解析。不过实验室并没有找到这个配置选项。

       2、其实php还存在%00截断，不过这个需要非常古老的版本，就算了吧。

      3、之后还有一个便是在CVE-2013-4547中出现的解析漏洞了，具体是有一个jpg文件，那么访问的是使用URL：xx.jpg%20\0.php便可将jpg文件解析为php文件。影响版本：0.8.41～1.4.3， 1.5 <= 1.5.7

                      

     4、畸形解析漏洞：版本Nginx <8.03

       Nginx解析漏洞这个伟大的漏洞是我国安全组织80sec发现的。在默认Fast-CGI开启状况下,上传一个名字为wooyun.jpg，内容为：');?>的文件，然后访问wooyun.jpg/.php,在这个目录下就会生成一句话木马 shell.php。

参考博客：https://blog.csdn.net/wn314/article/details/77388289

 

 

0x02  IIS解析：

第一个是IIS的解析特性：会将”.cer，.asa，.cdx”这些当成asp脚本解析，那么这些扩展名就有可能逃逸上传时的限制。

其次就是IIS的解析漏洞了。这一漏洞有两种完全不同的利用方式：

              /test.asp/test.jpg

               test.asp;.jpg

第一种是新建一个名为“test.asp”的目录，该目录中的任何文件都被IIS当做asp程序执行（特殊符号是“/”）；第二种是上传名为“test.asp;.jpg”的文件，虽然该文件真正的后缀名是“.jpg”，但由于含有特殊符号“;”，仍会被IIS当做asp程序执行。

原理大抵是IIS 5.x/6.0在从文件路径中读取文件后缀时，遇到一个“.”后，便进入了一种截断状态，在该状态下遇到特殊符号——“/”和“;”，都会进行截断，只保留特殊符号前的部分，即：“.asp”，从而认为文件后缀为“.asp”。

 

再然后就是当利用IIS作为php程序的web容器时存在的解析漏洞。

      test.jpg/.php

IIS和Nginx在这一点上是一样的，一看到URL中文件后缀是.php，便无论该文件是否存在，都直接交给php处理，而php又默认开启“cgi.fix_pathinfo”，会对文件路径进行“修理”，何谓“修理”？举个例子，当php遇到文件路径“/aaa.xxx/bbb.yyy/ccc.zzz”时，若“/aaa.xxx/bbb.yyy/ccc.zzz”不存在，则会去掉最后的“/ccc.zzz”，然后判断“/aaa.xxx/bbb.yyy”是否存在，若存在，则把“/aaa.xxx/bbb.yyy”当做文件“/aaa.xxx/bbb.yyy/ccc.zzz”，若“/aaa.xxx/bbb.yyy”仍不存在，则继续去掉“/bbb.yyy”，以此类推。

若有文件test.jpg，访问时在其后加/.php，便可以让IIS把“test.jpg/.php”交给php，php“修理”文件路径“test.jpg/.php”得到“test.jpg”，该文件存在，便把该文件作为php程序执行了。因为实验环境搭建失败，所以没有演示。