这种方式绕过比较简单,直接前端禁用js,或者BP抓包修改文件后缀名
MIME类型检测的概念
所谓MIME类型检测实际上就是客户端在上传文件到服务端的时
候,服务端对客户端上传的文件的Content-Type类型进行检测,
如果是白名单所允许的,则可以正常上传,否则上传失败。
绕过方法:
截包,在包中根据content-type类型,修改所上传文件的后缀
截包,在包中将文件后缀的某个字母大写,用AsP,pHp之类的文件名绕过黑名单检测
1)截包,在包中将文件后缀后增加一个空格或者一个. ,.是利用win主机特性,文件以点结尾会被系统自动删除
php. php[空格]
2)截包,如文件后缀如php被删除了,在包中将文件后缀中双写php绕过,如pphphp
3)特别:xx.jpg a a a 在bp中10-99的URL编码替代变量a,作用类似空格截断绕过
当客户端将文件提交到服务端的时候,服务端会根据自己设定的黑
白名单对客户端提交上来的文件扩展名进行判断,但是当一些在服
务器中不常用的,但是可以被解析的后缀名没有被列入黑名单中时,
我们就可以上传不常用的后缀名文件,实现恶意代码的执行。
常见的不常用但是能执行后缀有
ASP语言类:.asa .cer .cdx
PHP语言类: .php3 .php4 .php5 .phtml
.net语言类:.ashx
截包,将content-type类型改为:image/png 或者image/jpep
文件内容检测的概念
一般文件内容的检测使用getimagesize()函数检测,会判断文件
是否是一个有效的图片文件,如果是,则允许上传,否则的话,
不允许上传
上传一个没有gif文件头的.gif文件进行测试
上传出错,由此推测服务端可能对上传的文件内容进行了检测。
用burp suite进行代理,然后选择图片马进行上传
PHP_pass.gif图片马上传成功
将文件名改回PHP_pass.gif.php,然后重新上传。
制作图片马方法:
将图片和文本整合在一起 copy xx.jpg/b + xx.php 11.jpg,然后将新的图片11.jpg上传,直接访问图片地址,不需要再改后缀。(前提是图片文件可以被当成php文件执行)
分布式配置文件(文件重写)的概念
.htaccess文件(或者"分布式配置文件")提供了针对目录改变配
置的方法, 即,在一个特定的文档目录中放置一个包含一个或
多个指令的文件, 以作用于此目录及其所有子目录。用户可以
利用此文件定义解析文件的后缀,从而进行恶意利用。
.htaccess (文件另存为)
要想使.htaccess文件生效,需要两个条件
1)在Apache的配置文件中写上:AllowOverride All
2)Apache要加载mod_Rewrite模块。加载该模块,需要在Apache的配置文件中写上:LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so
若是在Ubuntu中,可能还需要执行命令:sudo a2enmod rewrite
配置完后需要重启Apache。
需要注意Apache可能有多个配置文件,后加载的配置文件会覆盖先加载的配置文件中的配置。所以在某个配置文件中将AllowOverride设置成All,若是其后加载的某个配置文件中AllowOverride的设置是None,则也是没有用的。一般来说,先加载httpd.conf,再加载conf.d/中的配置文件,最后加载sites-enabled/中的配置文件。
所以,.htaccess并不总是有效的
.htaccess文件内容
SetHandler application/x-httpd-php
这样所有文件都会当成php来解析。
或者
然后再上传一个名字为gg.jpg的脚本,含有一句木马的文件
可参考文件解析漏洞总结-Apache
我先把网上盛行的集中上传截断各自举个例,然后到最后总结一下阶段的核心,首先是0x00截断,00截断是将上传文件名或路径名中使用ascll码值为0的字符(也就是null)来进行截断,%00一般用在URL中用于截断url来进行文件包含,两者原理都一样,都是ascll为0的字符,只是形式不同而已。
0x00是字符串的结束标识符,攻击者可以利用手动添加字符串标识符的方式来将后面的内容进行截断,而后面的内容又可以帮助我们绕过检测。
00截断的限制条件:PHP<5.3.29,且GPC关闭
目录路径检测的概念
目录路径检测一般就是检测上传的路径是否合法,一旦程序员在
写程序的时候对文件的上传路径过滤不严格就很有可能产生
0x00上传截断漏洞。
假设文件的上传路径为:
http://xx.xx.xx.xx/upfiles/cimer.php.gif,通过抓包截断将
cimer.php后面的.换成0x00,cimer.php0x00gif当上传的时候,当文件系统读到
0x00的时候,会认为文件已经结束,从而将cimer.php.gif中的
内容写入到cimer.php,从而达到攻击目的。
文件截断 (验证机制是从后往前,但服务器读是从前往后读,所以可以通过截端绕过)
或者在HEX中直接修改
上传hack.php%00.jpg
然后BP截包,将%00转为URL解码
注意要把%00做一个URL编码
以上方法试用于get方法
如果是post方法,需要在BP截包中修改HEX,在如…1.php后输入空格,然后在HEX中找到空格对应的16进制20,然后用00替换20
当以上方法都不行时候,可以考虑结合文件包含:
1)http://…/index.php?page=uploads/1.jpg%00
2)文件包含查看源码,使用php://filter/read=convert.base64-encode/resource=/etc/passwd
http://106.15.186.69:23336/user.php?page=php://filter/read=convert.base64-encode/resource=index
通过查看源码可以进行代码审计,如源码中如果涉及命令执行函数,则可以进行利用
常见的编辑器存在的上传漏洞
ewebeditor
FCKeditor
Ckeditor
CKFinder
在FCKeditor下创建XX.asp文件夹,上传木马图片至此文件夹内。
访问http://172.16.240.118/userfiles/file/jddd.asp/ch_asp.jpg,发现可以访问
通过菜刀连接提权。
如果运维人员给.php后缀增加了处理器,那么,在有多个后缀的情况下,只要一个文件含有.php后缀的文件即将被识别成PHP文件,没必要是最后一个后缀。利用这个特性,将会造成一个可以绕过上传白名单的解析漏洞。
Apache 是从右到左开始判断文件扩展名来解析文件,如果文件扩展名不被识别,就再往左判断。
比如 cimer.php.owf.rar “.owf”和”.rar” 这两种后缀是
apache不可识别解析,apache就会把cimer.php.owf.rar解析成
php。
如何判断是不是合法的后缀就是这个漏洞的利用关键,测试时可
以尝试上传一个cimer.php.rara.jpg.png…(把你知道的常见后
缀都写上…)去测试是否是合法后缀。
Apache HTTPD是一款HTTP服务器,它可以通过mod_php来运行PHP网页。其2.4.0~2.4.29版本中存在一个解析漏洞,在解析PHP时,1.php\x0A将被按照PHP后缀进行解析,导致绕过一些服务器的安全策略。
在网站下建立文件夹的名字为 .asp /.asa 的文件夹,其目录内的任何扩展名
的文件都被IIS当作asp文件来解析并执行。
如创建目录cimer.asp,那么 /cimer.asp/1.jpg 将会被按照正常的asp文件
进行解析。
在IIS6.0下,分号后面的不被解析,如 cimer.asp;.jpg会被当做cimer.asp
还有iis6.0默认的可执行文件除了asp还包含
• .asa
• .cer
• .cdx
在默认Fast-CGI开启状况下,攻击者上传一个名字为cimer.jpg,
内容为
然后访问cimer.jpg/.php,在这个目录下就会生成一句话木马
shell.php
当在IIS网站配置中分配了写入的权限,及会引起IISput漏洞,导致
用户可以直接上传文件到服务器中,导致恶意代码的执行。
使用扫描工具进行扫描,扫描出来之后使用利用工具进行利用
Nginx <0.8.03 空字节代码执行漏洞
影响版:0.5.,0.6., 0.7 <= 0.7.65, 0.8 <= 0.8.37
Nginx在图片中嵌入PHP代码然后通过访问Xxx.jpg%00.php来
执行其中的代码
Nginx 1.x 最新版
PHP 7.x最新版
访问http://your-ip/uploadfiles/nginx.png和http://your-ip/uploadfiles/nginx.png/.php即可查看效果。
原因:
首先,浏览器去访问了xxx.xxx.xxx/free.jpg会显示解析错误(因为PHP代码放到JPG里,肯定没办法解析的呀~),然后我们访问xxx.xxx.xxx/free.jpg/free.php,报了一个错误(不是404), 而这里free.jpg是文件而不是目录,free.php就根本不存在的文件,没有报404说明这里有戏。
这其中涉及到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 只会返回找不到文件。但关闭该选项很可能会导致一些其他错误,所以一般是开启的。
上面的测试均在Nginx1.4.6中进行。这一漏洞是由于Nginx中php配置不当而造成的,与Nginx版本无关,但在高版本的php中,由于“security.limit_extensions”的引入,使得该漏洞难以被成功利用。
为何是Nginx中的php才会有这一问题呢?因为Nginx只要一看URL中路径名以.php结尾,便不管该文件是否存在,直接交给php处理。而如Apache等,会先看该文件是否存在,若存在则再决定该如何处理。cgi.fix_pathinfo是php具有的,若在php前便已正确判断了文件是否存在,cgi.fix_pathinfo便派不上用场了,这一问题自然也就不存在了。
具体可参考Nginx中的解析漏洞
1.针对上传的文件迚行后缀名判断,文件类型判断,并利用
time()函数迚行时间重写(重命名)
归纳起来就是:白名单+重命名
2.安装第三方防护软件
3.文件上传目录禁止脚本解析
想练习的小伙伴可以到自行搭建文件上传靶场练习,靶场名称:upload-labs。
upload-labs源码地址:https://github.com/c0ny1/upload-labs
解题思路可以参考以下这位博主链接~(此处先引用博主图片,总结的很好)
https://blog.csdn.net/weixin_44677409/article/details/92799366