解析漏洞小结及BP插件开发

前言：

---

4月底离职以后在学习BP插件开发，断断续续也写了几个插件，后面再慢慢优化把。临近毕业了，近期越来越感到颓废了……

Apache：

---

Apache Httpd多后缀解析漏洞：

Apache的解析漏洞依赖于一个特性：Apache默认一个文件可以有多个以点分割的后缀，当最右边的后缀无法识别（不在mime.types文件内），则继续向左识别，直到识别到合法后缀才进行解析。利用Apache httpd这个特性,就可以绕过上传文件的白名单。

该漏洞和apache版本和php版本无关,属于用户配置不当造成的解析漏洞

漏洞原理：

由于管理员的错误配置, AddHandler application/x-httpd-php .php,在有多个后缀的情况下,只要一个文件含有.php后缀的文件即将被识别成PHP文件

漏洞环境搭建：

win7 + phpstudy 2014 + apache + php5.2

在根目录上添加一个.htaccess文件，内容如下：

AddHandler application/x-httpd-php .php

在根目录下上传一个info.php.abc文件，内容如下：

<?php phpinfo();?>

漏洞复现：

防御措施：

• 1、使用SetHandler,写好正则
  <FileMatch ".+.php$">
  SetHandler application/x-httpd-php
  </FileMatch>
• 2、禁止.php这样的文件执行
  <FileMatch ".+.ph(p[3457]?|t|tml).">
  Require all denied
  </FileMatch>

Apache HTTPD 换行解析漏洞（CVE-2017-15715）：

Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。其2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，1.php\x0A将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。

此漏洞形成的根本原因，在于不仅匹配字符串结尾位置，也可以匹配\n 或 \r
影响范围：

2.4.0~2.4.29版本

漏洞环境搭建：

kali + docker

漏洞复现：

上传一个名为123.php的文件，被拦截，在123.php后面插入一个\x0A，不再拦截：

查看docker容器内是否成功上传：

成功访问：

IIS 7.x 解析漏洞：

IIS7 及IIS7.5 在使FastCGI方式调用php时，在php.ini里设置：

cgi.fix_pathinfo=1

使得访问任意文件URL时，在URL后面添加“/x.php”等字符时，该文件被IIS当php文件代码解析

利用条件：

• 1、php.ini里cgi.fix_pathinfo=1(默认为1)
• 2、在请求限制中勾选下图红框内的选项

漏洞环境搭建：
win7 + phpstudy 2014 + IIS7.5 + php5.2

IIS启动对CGI的支持：

漏洞复现：

Nginx：

---

Nginx 解析漏洞：

该漏洞与Nginx、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”，以此类推。

但在高版本的php中，由于security.limit_extensions的引入，使得该漏洞难以被成功利用。
说明：限制了fastcgi解析文件的类型(即指定什么类型的文件当做代码解析),此项设置为空的时候才允许fastcgi将’.png’等文件当做代码解析

漏洞原理：

• 1、当攻击者访问/info.jpg/xxx.php时， Nginx将查看URL，看到它以.php结尾，并将路径传递给PHP fastcgi处理程序。
• 2、但是fastcgi在处理’.php’文件时发现文件并不存在,这时php.ini配置文件中cgi.fix_pathinfo=1 发挥作用，如果当前路径不存在则采用上层路径。为此这里交由fastcgi处理的文件就变成了/info.jpg
• 3、fastcgi将.jpg文件当做代码解析

漏洞环境搭建：

win7 + phpstudy 8.1.0.7 + nginx

漏洞复现：

防御措施：

• 1、 将php.ini文件中的cgi.fix_pathinfo的值设置为0,这样php再解析1.php/1.jpg这样的目录时,只要1.jpg不存在就会显示404页面
• 2、 php-fpm.conf中的security.limit_extensions后面的值设置为.php

Nginx 文件名逻辑漏洞（CVE-2013-4547）

nginx会把所有后缀名为php的文件交给fastcgi处理，在存在CVE-2013-4547的情况下,我们请求1.gif[0x20][0x00].php,这个URI可以匹配上正则.php$,可以进入这个Location块；但进入后,Nginx却错误地认为请求的文件是1.gif[0x20],就设置其为SCRIPT_FILENAME的值发送给fastcgi。

Fastcgi根据SCRIPT_FILENAME的值进行解析,最后造成了解析漏洞。所以,我们只需要上传一个空格结尾的文件,即可使PHP解析之。

影响版本：

Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

漏洞复现：

成功解析：

php解析正常图片：

说明：该漏洞不受cgi.fix_pathinfo影响，当其为0时，依旧解析，在Windows上有所限制。

防御措施：

• 1、设置security.limit_extensions = .php
• 2、升级Nginx

BP插件开发：

---

最初的想法是打造一个被动检测插件，用于检测nginx解析漏洞和IIS 7.x解析漏洞，大概的实现思路如下：

• 1、只监听响应包，并获取其Content-Type
• 2、当Content-Type为JPEG或者PNG或者GIF时，进行被动检测
• 3、构造一个特定的URI，形如：abc.jpg/zxc813.php
• 4、构造一个GET型的HTTP请求并获取分析响应包
• 5、将响应包的body部分转变成16进制，匹配是否存在png、jpg、gif的文件头，并判断响应码是否为200，Content-Type是否为HTML
• 6、若均满足条件，则添加至issues列表并返回

部分代码：

if str(resp_contentType) in ['JPEG', 'GIF', 'PNG']:
    print 'Passivecan'
    if '.jpg?' in str(request_Path) or '.gif?' in str(request_Path) or '.png?' in str(request_Path):
        request_Path = str(request_Path).split('?')[0]

newRequest = self._helpers.buildHttpRequest(new_url)
newIHttpRequestResponse = self._callbacks.makeHttpRequest(httpService, newRequest)
target_response = newIHttpRequestResponse.getResponse()
analyzedIResponseInfo = self._helpers.analyzeResponse(target_response)

if str(target_contentType) == 'HTML' and str(target_status) == '200' and '474946383961' in target_bodys_hex or 'FFD8FFE00010' in target_bodys_hex or '89504E470D0A' in target_bodys_hex:
    issues.append(CustomScanIssue(newIHttpRequestResponse.getHttpService(),self._helpers.analyzeRequest(newIHttpRequestResponse).getUrl(), [newIHttpRequestResponse],"Nginx Analytical Vuln","Nginx Analytical Vuln","High"))
    return issues

最终实现效果：

参考如下：

---

apache httpd多后缀解析漏洞复现
IIS 7.5 解析错误 命令执行漏洞解决方案
nginx解析漏洞复现
Web中间件常见安全漏洞总结