前言：
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中间件常见安全漏洞总结
网友评论