文件上传漏洞及解析漏洞总结

Posted 2020-08-16

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了文件上传漏洞及解析漏洞总结相关的知识，希望对你有一定的参考价值。

文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。这种攻击方式是最为直接和有效的，“文件上传”本身没有问题，有问题的是文件上传后，服务器怎么处理、解释文件。如果服务器的处理逻辑做的不够安全，则会导致严重的后果。

文件上传后导致的常见安全问题一般有:

1)上传文件是Web脚本语言，服务器的Web容器解释并执行了用户上传的脚本，导致代码执行。

2)上传文件是Flash的策略文件crossdomain.xml，黑客用以控制Flash在该域下的行为（其他通过类似方式控制策略文件的情况类似);

3)上传文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行。

4)上传文件是钓鱼图片或为包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈。

除此之外，还有一些不常见的利用方法，比如将上传文件作为一个入口，溢出服务器的后台处理程序，如图片解析模块；或者上传一个合法的文本文件，其内容包含了php脚本，再通过"本地文件包含漏洞(Local File Include)"执行此脚本；等等。

要完成这个攻击，要满足以下几个条件:

首先，上传的文件能够被Web容器解释执行。所以文件上传后所在的目录要是Web容器所覆盖到的路径。

其次，用户能够从Web上访问这个文件。如果文件上传了，但用户无法通过Web访问，或者无法得到Web容器解释这个脚本，那么也不能称之为漏洞。

最后，用户上传的文件若被安全检查、格式化、图片压缩等功能改变了内容，则也可能导致攻击不成功。

一、从FCKEditor文件上传漏洞谈起

FCKEditor是一款非常流行的富文本编辑器，为了方便用户，它带有一个文件上传功能，但是这个功能却出过多次漏洞。

FCKEditor针对ASP/PHP/JSP等环境都有对应的版本，以PHP为例，其文件上传功能在：

http://www.xxx.com/path/FCKEditor/editor/filemanager/browser/default/browser.html?，配合解析漏洞。

（一）IIS5.x-6.x解析漏洞

使用iis5.x-6.x版本的服务器，大多为windows server 2003，网站比较古老，开发语句一般为asp；该解析漏洞也只能解析asp文件，而不能解析aspx文件。

目录解析(6.0)

形式：www.xxx.com/xx.asp/xx.jpg

原理: 服务器默认会把.asp，.asp目录下的文件都解析成asp文件。

文件解析

形式：www.xxx.com/xx.asp;.jpg

原理：服务器默认不解析;号后面的内容，因此xx.asp;.jpg便被解析成asp文件了。

解析文件类型

IIS6.0 默认的可执行文件除了asp还包含这三种 :

/test.asa

/test.cer

/test.cdx

（二）apache解析漏洞

漏洞原理

Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。比如 test.php.qwe.asd “.qwe”和”.asd” 这两种后缀是apache不可识别解析,apache就会把wooyun.php.qwe.asd解析成php。

漏洞形式

www.xxxx.xxx.com/test.php.php123

其余配置问题导致漏洞

（1）如果在 Apache 的 conf 里有这样一行配置 AddHandler php5-script .php 这时只要文件名里包含.php 即使文件名是 test2.php.jpg 也会以 php 来执行。

（2）如果在 Apache 的 conf 里有这样一行配置 AddType application/x-httpd-php .jpg 即使扩展名是 jpg，一样能以 php 方式执行。

修复方案

1.apache配置文件，禁止.php.这样的文件执行，配置文件里面加入

2.用伪静态能解决这个问题，重写类似.php.*这类文件，打开apache的httpd.conf找到LoadModule rewrite_module modules/mod_rewrite.so

把#号去掉，重启apache,在网站根目录下建立.htaccess文件

（三）nginx解析漏洞

漏洞原理

Nginx默认是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通过正则匹配设置SCRIPT_FILENAME。当访问www.xx.com/phpinfo.jpg/1.php这个URL时，$fastcgi_script_name会被设置为“phpinfo.jpg/1.php”，然后构造成SCRIPT_FILENAME传递给PHP CGI，但是PHP为什么会接受这样的参数，并将phpinfo.jpg作为PHP文件解析呢?这就要说到fix_pathinfo这个选项了。如果开启了这个选项，那么就会触发在PHP中的如下逻辑：

PHP会认为SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就会将phpinfo.jpg作为PHP文件来解析了

漏洞形式

www.xxxx.com/UploadFiles/image/1.jpg/1.php

www.xxxx.com/UploadFiles/image/1.jpg%00.php

www.xxxx.com/UploadFiles/image/1.jpg/%20\0.php

另外一种手法：上传一个名字为test.jpg，然后访问test.jpg/.php,在这个目录下就会生成一句话木马shell.php。

（四）IIS7.5解析漏洞

IIS7.5的漏洞与nginx的类似，都是由于php配置文件中，开启了cgi.fix_pathinfo，而这并不是nginx或者iis7.5本身的漏洞。

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

（1）上传不符合windows文件命名规则的文件名

test.asp.

test.asp(空格)

test.php:1.jpg

test.php:: $DATA

会被windows系统自动去掉不符合规则符号后面的内容。

如图访问ip/Netsys/HtmlEdit/fckeditor/editor/filemanager/connectors/test.html

点击Create Folder新建文件夹

用brup suite进行改包，将%2F改为a.asp。

点击Get Folders获得文件夹。

上传文件，我这里上传了一句话图片木马，然后能看到上传的路径，访问的是1.asp/FI201610191827336199.jpg，会被当作asp执行，用菜刀连接getshell。

二、绕过文件上传检查功能

一般都是通过文件名后缀检查。但是在某些时候，攻击者手动修改了上传过程中的POST包，在文件名后添加一个%00字节额，则可以截断某些函数对文件名的判断。因为在许多语言的函数中，比如在C、PHP等语言的常用字符串处理函数中，0x00被认为是终止符。受此影响的环境有Web应用和一些服务器。比如应用原本只允许上传JPG图片，那么可以构造文件名为xxx.php[\0].JPG,其中[\0]为十六进制的0x00字符，.JPG绕过了应用的上传文件类型判断；但对于服务器来说，此文件因为0x00字符截断的关系，最终却变成了xxx.php。

1.客户端校验　　

一般都是在网页上写一段javascript脚本，校验上传文件的后缀名，有白名单形式也有黑名单形式。

　　判断方式：在浏览加载文件，但还未点击上传按钮时便弹出对话框，内容如：只允许上传.jpg/.jpeg/.png后缀名的文件，而此时并没有发送数据包。

客户端绕过　　

可以利用burp抓包改包，先上传一个gif类型的木马，然后通过burp将其改为asp/php/jsp后缀名即可。

2.服务端校验

2.1 content-type字段校验　　

文件类型绕过

我们可以通过抓包，将content-type字段改为image/gif

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”

文件头绕过　　

在木马内容基础上再加了一些文件信息，有点像下面的结构

GIF89a<?php phpinfo(); ?>

2.3 扩展名验证

MIME验证

MIME(Multipurpose Internet Mail Extensions)多用途互联网邮件扩展类型。是设定某种扩展名的文件用一种应用程序来打开的方式类型，当该扩展名文件被访问的时候，浏览器会自动使用指定应用程序来打开。多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式。

它是一个互联网标准，扩展了电子邮件标准，使其能够支持：

非ASCII字符文本；非文本格式附件（二进制、声音、图像等）；由多部分（multiple parts）组成的消息体；包含非ASCII字符的头信息（Header information）。

这个标准被定义在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 MIME改善了由RFC 822转变而来的RFC 2822，这些旧标准规定电子邮件标准并不允许在邮件消息中使用7位ASCII字符集以外的字符。正因如此，一些非英语字符消息和二进制文件，图像，声音等非文字消息原本都不能在电子邮件中传输(MIME可以)。MIME规定了用于表示各种各样的数据类型的符号化方法。此外，在万维网中使用的HTTP协议中也使用了MIME的框架，标准被扩展为互联网媒体类型。

MIME的作用

使客户端软件区分不同种类的数据，例如web浏览器就是通过MIME类型来判断文件是GIF图片，还是可打印的PostScript文件。 Web服务器使用MIME来说明发送数据的种类，Web客户端使用MIME来说明希望接收到的数据种类。

一个普通的文本邮件的信息包含一个头部分（To: From: Subject: 等等）和一个体部分（Hello Mr.,等等）。在一个符合MIME的信息中，也包含一个信息头并不奇怪，邮件的各个部分叫做MIME段，每段前也缀以一个特别的头。MIME邮件只是基于RFC 822邮件的一个扩展，然而它有着自己的RFC规范集。

头字段：MIME头根据在邮件包中的位置，大体上分为MIME信息头和MIME段头。（MIME信息头指整个邮件的头，而MIME段头只每个MIME段的头。）

常见MIME类型