一,工具及环境准备
以下都是超详细保姆级安装教程,缺什么安装什么即可(提供镜像工具资源)
1-1 VMware 16.0 安装
1-2 Windows server 2003 安装
1-3 pikachu靶场安安装
1-4 凡诺企业管理系统靶场安装
二,服务器解析漏洞
服务器解析漏洞算是历史比较悠久了,但如今依然广泛存在。在此记录汇总一些常见服务器(WEB server)的解析漏洞,比如IIS6.0、IIS7.5、apache、nginx等方便以后回顾温习。
2-1 IIS5.x-6.x解析漏洞
## 使用iis5.x-6.x版本的服务器,大多为windows server 2003,网站比较古老,开发语句一般为asp;该解析漏洞也只能解析asp文件,而不能解析aspx文件。win7-win10中多为iis7.x-8.x了,版本比较高。
目录解析(6.0)
形式:www.xxx.com/xx.asp/xx.jpg
原理: 服务器默认会把.asp,.asa目录下的文件都解析成asp文件。
文件解析
形式:www.xxx.com/xx.asp;.jpg
原理:服务器默认不解析;号后面的内容,因此xx.asp;.jpg便被解析成asp文件了。
解析文件类型
IIS6.0 默认的可执行文件除了asp还包含这三种 :
/test.asa
/test.cer
/test.cdx
修复方案
1.目前尚无微软官方的补丁,可以通过自己编写正则,阻止上传xx.asp;.jpg类型的文件名。
2.做好权限设置,限制用户创建文件夹。
2-1-1 www.xxx.com/xx.asp;.jpg
我们打开凡诺企业管理系统网站***(靶场安装请看第一部分工具及环境准备)***
这个首页就是index.asp ,我们复制一份这个index.asp,重命名为show.asp;.jpg 如下:
然后浏览器访问 http://192.168.31.208/show.asp;.jpg
发现依然能访问成功,这就是一个解析漏洞,如果发现asp网站有能上传图片的地方,可以使用这种方法上传asp木马程序来绕过验证
2-1-2 www.xxx.com/xx.asp/xx.jpg
原理: 服务器默认会把.asp,.asa目录下的文件都解析成asp文件。
浏览器访问 192.168.31.208/xx.asp/index.jpg
我们发现报错了,不过报错也正常,因为首页肯定包含一些别的代码文件,我们把首页移动到了别的目录,当然找不到这些包含的路径了,所以报错,而上图也显示确实找不到一个包含文件,但是肯定的是index.jpg当一个asp文件执行了,只是执行的时候由于路径问题报错了而已
2-1-3 index.asa | index.cer | index.cdx
IIS6.0 默认的可执行文件除了asp还包含这三种 :
/test.asa
/test.cer
/test.cdx
选一个演示一下,我们把首页的index.asp改名字改为index.cer
访问效果如下,也能进行访问
cer文件一般是证书文件,iis默认也是可以解析的,我们来看网站属性
2-2 apache 解析漏洞
漏洞原理
Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。比如test.php.owf.rar ".owf"和".rar" 这两种后缀是apache不可识别解析,apache就会把xx.php.owf.rar解析成php。
**## 漏洞形式
www.xxxx.xxx.com/test.php.php123这个漏洞当时通杀了所有的apache搭建的网站。其余配置问题导致漏洞**
(1)如果在 Apache 的 conf 里有这样一行配置 AddHandler php5-script .php 这时只要文件名里包含.php 即使文件名是 test2.php.jpg 也会以 php 来执行。
(2)如果在 Apache 的 conf 里有这样一行配置 AddType application/x-httpd-php .jpg 即使扩展名是 jpg,一样能以 php 方式执行。xx.jpg
示例:<www.xxxx.xxx.com/test.php.php123>
以pikachu靶场为例(靶场安装请看第一部分工具及环境准备)
比如我们将sql.php改为sql.php.xxxx,正常来讲的话是不能解析的,但是老版本的apache(apache2.2版本及之前的)是能够正常将这个文件解析为php文件的
我用的是新版本的apache,没搭建老版本的,所以这个漏洞大家就记住他就行了,当然,新版本的apache如果配置不当也会引起这个漏洞,有兴趣的大家可以去安装一个低版本的apache来玩玩,你看新版本的就不解析运行代码了,直接把源代码给你看,而不是将源代码执行了。以前大家通过黑名单的方式来防御的,基本都挂了,因为你发现后缀名你随意写
其余配置问题导致漏洞
(1)如果在 Apache 的 conf 里有这样一行配置 AddHandler php5-script .php 这时只要文件名里包含.php 即使文件名是 test2.php.jpg 也会以 php 来执行。
(2)如果在 Apache 的 conf 里有这样一行配置 AddType application/x-httpd-php .jpg 即使扩展名是 jpg,一样能以 php 方式执行。
这两个漏洞不是apache自身的问题,而是运维人员进行配置时,自己配置的出了问题。
这里就不演示了
修复方案
1.apache配置文件,禁止.php.这样的文件执行,配置文件里面加入
<Files ~ ".(php.|php3.)">
Order Allow,Deny
Deny from all
</Files>
2.用伪静态能解决这个问题,重写类似.php.*这类文件,打开apache的httpd.conf找到LoadModule rewrite_module modules/mod_rewrite.so把#号去掉,重启apache,在网站根目录下建立.htaccess文件,代码如下:
<IfModule mod_rewrite.c>
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
</IfModule>
2-3 nginx解析漏洞
大致原理:该漏洞与nginx、php版本无关,属于配置不当造成的解析漏洞。
当php.ini配置文件中开启了cgi.fix_pathinfo,该值默认为1,表示开启。看名字大概知道是处理路径用的配置。
比如我们上传了一个木马文件web.jpg,因为web.php不能上传,现在我们想执行这个web.jpg,可以如下路径访问
http://192.168.2.104/pikachu/web.jpg/aaa.php
而目标服务器上没有aaa.php文件,本来如果nginx.conf的配置没有问题的话,nginx会先去找下这个文件是否存在,如果存在,在找php解释器来解释执行代码,如果不存在,nginx会直接返回错误信息,说找不到该文件,但是如果nginx.conf配置不当会导致nginx把以'.php'结尾的文件交给fastcgi处理,也就是说首先nginx看到你路径中要找aaa.php,哦,原来是php文件,nginx不去找这个文件了,而是就直接交给了fastcgi,fastcgi又去找php解释器去处理该路径,而php开启了cgi.fix_pathinfo,那么php解释器处理这个路径的时候,发现没有aaa.php文件,那么他会找路径中上一层路径的文件作为aaa.php来运行,如是乎就找到了web.jpg,将web.jpg当作aaa.php来运行了,所以代码被执行,看到如下效果
示例:我们通过phpstudy来改成nginx运行 (pikachu靶场)
fix_pathinfo这个功能参数默认是开启的,所以这个漏洞影响也是比较大的,我们访问一下phpinfo.php文件,看看这个功能是否开启了。
值为1表示开启状态,那么就存在这个漏洞
比如我将一个木马文件,改为.jpg文件,放到pikachu的文件夹下
(这个木马文件在文件上传闯关靶场的工具资料里给过,需要的看我下面这篇博客下载)
然后通过浏览器来访问一下
能看出,默认是不能访问的,我们只要在路径后面加上一个 /tu.php ,就能够按照php来解析了,直接就是漏洞。因为图片我们是正常能够上传的,上传过去之后,如果是nginx来解析的,并且开启了cgi.fix_pathinfo功能,那么基本上属于被你拿下了。
其他漏洞形式
www.xxxx.com/UploadFiles/image/1.jpg/1.php,这是上面说的漏洞
www.xxxx.com/UploadFiles/image/1.jpg .php #我们试过这个00截断,除了apache之外,nginx也有这个00截断漏洞,这个导致的效果是:1.jpg会被当成php文件来解析。
www.xxxx.com/UploadFiles/image/1.jpg/ \0.php #也算是00截断的一种
xxx.jpg%00.php (Nginx <0.8.03版本 存在空字节代码执行漏洞)
修复方案 :
1.修改php.ini文件,将cgi.fix_pathinfo的值设置为0;
2.在Nginx配置文件中添加以下代码:
php
if ( $fastcgi_script_name ~ ..*/.*php ) {
return 403;
}
这行代码的意思是当匹配到类似test.jpg/a.php的URL时,将返回403错误代码。
2-4 IIS7.x解析漏洞
IIS7.5的漏洞与nginx的类似,都是由于php配置文件(php.ini文件)中,开启了cgi.fix_pathinfo,而这并不是nginx或者iis7.5本身的漏洞,都是配置不当引起的。
当安装完成后, php.ini里默认cgi.fix_pathinfo=1,对其进行访问的时候,在URL路径后添加.php后缀名会当做php文件进行解析,漏洞由此产生
php.ini文件配置
虽然通过配置上看,我们发现是有这个漏洞的,但是实际测试过程中,并不是那么简单,如下,注意,下面的示例是用的phpstudy2016版本来演示的,win7及以上的系统才行昂,win2003不行的,勾选iis的时候,可能会提示你,说你没有尚未安装iis 7/8,大家自行安装一下即可。按照这个phpstudy的官网来安装:PHP - - phpStudy,其中要激活CGI功能,别忘了。
你的phpstudy可能会报错
解决方法:安装vc9工具
放到我们的win7虚拟机上
安装
一会就提示你安装好了,在重启phpstudy即可。如果提示你网站运行端口冲突了,我们改个端口即可,按照文档的安装和配置,我们访问我们的iis网站下面的图片时
根据iis的解析漏洞方式来写如下访问网址:
还是报错了,要进行如下配置才能看到效果。
找到网站代码存放目录,来部署网站:
注:在进行实际的测试的时候,iis并不像nginx似的直接可以利用,发现漏洞并没有产生,后来发现要将FastCGI的调用情况取消限制,如下,将对勾去掉。
效果如下
所以你会发现,这个漏洞如果想用的话,高版本需要进行很多的配置,所以一般不会出现这个漏洞
中间件常见解析漏洞就讲到这里,下一篇博客文件包含漏洞