文件解压引发的getshell

阅读量    878564 | 评论 8

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

声明!

本文仅供学习和研究,由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,海青实验室及文章作者不承担任何责任。

安全狗海青实验室拥有此文章的修改和解释权,如欲转载或传播,必须保证此文的完整性,包括版权声明在内的全部内容,未经海青实验室同意,不得任意修改或者增减此文章内容,不得以任何方式将其用于商业目的。

攻击者可以快速的从文件上传功能点获得一个网站服务器的权限,所以一直是红蓝对抗中的“兵家必争之地“。而随着对抗不断升级,开发人员的安全意识的不断提高,多多少少也学会了使用黑名单或者白名单等一些手段进行防御,但刁钻的攻击者,依然发现了疏忽之处。本文以两个实例,简单介绍文件解压功能导致的getshell问题。

 

PHPOK CMS后台任意文件上传

首先,准备一个包含了一个PHP文件的zip文件,然后在导入模块中将zip文件上传。

在尝试的时候发现,导入模块失败了,但是查看文件夹内容,可以发现文件已经成功被写入了。

流程分析

接下来我们从代码层面来看看整个流程是怎样的。

当我们点击导入模块时,浏览器会发送两条请求。先看第一条POST请求。根据PHPOK CMS路由分发的规则,可以定位到upload控制器中的zip方法。

而在43行处,引入了libsupload.php文件并且调用zipfile()函数。

在第135行处,设定了文件后缀类型为zip,由于137行处的if条件不成立,流程进入140行,调用_save()方法。继续跟进_save()方法。

_save()方法在276行处使用file_ext()方法对传入的name参数也就是文件名进行后缀判断,而如果判断通过,则会在之后将压缩文件保存下来。跟进一下file_ext()方法。

在该方法中设置了一个白名单,文件名只能是jpg,gif,png,zip中的其中一种。为什么包含zip呢?不管是程序执行到第186或者189行处,在前面就已经给这两个变量设置值为zip了,所以在白名单中自然包含了zip。目前到此为止,整个上传流程没有什么问题,并且使用了白名单来限制后缀,所以只能上传zip压缩文件。

接着再来看第二处请求:

admin.php?c=module&f=import&zipfile=_cache%2Fa9414ae41044fc5a.zip&_=1570603538199

同样根据路由规则,可以定位到module控制器下的import方法

程序会接受到zipfile参数,是刚刚压缩包保存在缓存文件夹里的文件名。在第705行处判断了是不是存在这个压缩包,如果存在则在708行处进行解压。其中引入了libs/phpzip.php中的unzip函数进行解压。跟进unzip函数,程序实例化了ZipArchive类进行解压,而目标路径$to则是缓存文件夹。

到此不难看出问题,程序将压缩包中的文件解压出来之后,并未进一步的进行判断,以至于里面包含的 PHP文件可以绕过上传文件的限制,使得原本建立的安全防御土崩瓦解。

 

ZZZCMS 后台解压文件导致任意文件上传

依照上文漏洞发掘方式,同样的在zzzcms的后台中找到了同样的问题。在项目中搜索关键字unzip。就可以找到解压功能的所在点,从而进行仔细的分析。

流程分析

定位到解压功能的所在之处,具体代码如下。

由于关注点在于解压功能,因此其他的case情况不去过多深究,只需要分析unzip处是否有问题即可。可以看到unzip的功能写在了up_data()函数之中,和上文所写到的一样,在解压完毕之后并未对解压出来的文件进行检测,因此不难考虑到压缩包里隐藏一个PHP文件的方法。

在784-785行处,分别定义了解压文件的保存路径(/runtime/updata/)和压缩包文件的存放路径(/runtime/zip/)。在第801行处,使用getfiles()函数来获取指定文件夹下的文件,也就是获取/runtime/zip/下的所有zip文件。然后在第803行处判断是否存在zip文件,如果存在则将压缩包里的文件解压出来。

分析至此,自然而然的可以想到如果能在/runtime/zip/中放置一个包含了PHP文件的压缩包,就可以在网站中植入webshell。因此,需要找到一个上传点,这个上传点的要允许上传zip文件,并且可以将上传文件保存到任意目录下。在整个项目里查找,找到了一个up_load()函数满足需求,具体代码如下所示:

在第651-652行,定义了文件上传的类型和保存的路径,然后在660行处调用upload函数来进行上传的具体操作。跟进upload查看。

在upload函数之中,由于传入的$type值为zip,因此程序流程进入到709行处,于是zip就成为允许上传的文件类型。在718行处会对文件后缀进行对比,如果后缀名在黑名单之中,则允许上传。在第725行处调用handle_upload()函数将上传文件保存下来,继续跟进该函数。

根据配置文件的设置值datefolder默认为0,当该值为0则不会再多一层以时间戳命名的文件夹,注意$folder是可控的,并且没有过滤跳转符号../就在750行处直接拼接构造了路径。紧接着covermark值默认为1,如果该文件路径已经存在则删掉原有的路径,目的是为了覆盖写入。$newname是新的文件名,由于$format的值为NULL,所以新文件名的格式是以时间戳+随机数的方式命名的。也正是因为如此,新的文件名变得不可猜测,所以无法直接上传一个webshell。而在解压功能中,新的文件名被保存成什么并不重要。

整个利用链已经十分清晰了,通过上传功能上传一个包含PHP文件的压缩包路径穿越保存到/runtime/zip/文件夹下,然后再触发解压功能,即可将webshell植入。

在save.php中,当$act为upload时,调用上传文件的功能,为updata时调用解压功能。由于并没有找到相应的前端页面,而且提交表单并没有检查refere值和设置csrf_token,因此可以自己编写一个上传页面,内容如下:

以GET方式设置好文件类型和保存路径,然后将zip文件上传即可。

当文件上传成功,可以看到文件成功被保存在了/runtime/zip/文件夹之下。接着触发解析功能。

可以发现文件已经被成功解压,并且保存在了/runtime/updata/文件夹之中。访问效果如下:

 

总结

从上述两则实例来看,压缩包里包含着webshell颇有些特洛伊木马的味道。当程序对上传后缀限制的相当严格,例如上文提到的PHPOK CMS,已经使用白名单的机制只能上传四种后缀的文件,却依然因为对压缩文件的处理不当,导致整个防御机制的失效。在ZZZCMS中的实例,猜测开发者的本意是zip文件夹内的内容应该别可控的,但在目录穿越的加持下,超出了开发者的预期从而防御机制土崩瓦解。

那么如何防御呢?建议开发者在实现文件解压功能时考虑以下要点:

1)限制文件的扩展名(如采用白名单的方式);

2)限制文件的名称(以较为严谨的黑名单约束文件名);

3)限制文件的大小(以免遭受压缩包炸弹的DDoS攻击)。

因此,在开发的各个环节,都要将安全意识贯彻其中。千里之堤毁于蚁穴,也正是这种细微之处的小问题,才使得攻击者有机可乘。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多