cms自助建站系统
声明
以下内容,均为文章作者原创,由于传播,利用此文所提供的信息而造成的任何直接或间接的后果和损失,均由使用者本人负责,长白山攻防实验室以及文章作者不承担任何责任。
长白山攻防实验室拥有该文章的修改和解释权。如欲转载或传播此文章,必须保证此文章的副本,包括版权声明等全部内容。声明长白山攻防实验室允许,不得任意修改或增减此文章内容,不得以任何方式将其用于商业目的。
0x01 前言
在漏洞挖掘时发现了一个RCE漏洞,这个漏洞的发掘,利用过程比较有趣,和大家分享一下~实际上在半个月前,本人发布了一篇关于DedeCMS前端RCE分析并扩展RCE挖掘思路的文章。这篇文章中DedeCMS这个前端RCE出现的问题在于,浏览器发送至服务器数据包中的referer并没有进行过滤,并且将referer中的内容写入cache,然后include包含至当前文件,造成了代码注入,实现了RCE。在这里,执行并没有用eval,shell_exec,exec之类的危险函数,而是在于include。思路是referer的内容可以注入的可执行的php文件中。在这个思路下,我就在想能不能也挖掘一个RCE出来,于是有了今天这篇文章。注:如果想直接了解RCE过程可以直接从4.1开始。0X01 初探74CMS
进入网站第一眼就看见了登录处。尝试SQL注入后无果,但是这里存在一个遍历用户名的问题:
这个问题就可以想到,他的后台是否也存在变量用户名的问题,访问后台发现确实如此…….
在未设定登陆尝试的次数下可以和轻易的爆破出用户名和密码。
在简单爆破后,就发现了后台的账号密码:
admin/admin
登录后台。
0x02 后台漏洞挖掘
在后台,发现了一处配置网站标题,公司电话的位置,一般这些内容由于需要在前端显示,开发人员会选择存储在服务器数据库中,而也有一部分的应用会选择将这些信息生成到一个config文件,为了确定这一点,将这个“00省00市00路00号0大厦00楼”的信息在
phpstrom中全局搜索。发现在
data/Runtime/Data/config.php这个文章中存在这个字段。
这样的用户自定义内容既然可以出现在php文件中,那么我是不是就可以尝试通过注入代号获取shell呢?在尝试过程中发现了如下问题:
1、将“00省00市00路00号0大厦00楼“修改为“00省00市00路00号0大厦00楼‘”后,这个config.php文件消失了!
文件虽然消失了,但是发现数据确实在前端正常显示了。源码定位分析后发现,这些内容被写入到了数据库中,RCE失败:
请求的url定位到
Application/Admin/Controller/ConfigController.class.php中的edit()方法,方法的最后在后面的调用了_edit()方法
_edit()方法在10行获取了post的数据,并且是12行save()方法存入了数据库。
0X03 RCE失败总结,新的思路
很显然,程序在开发时,开发人员也意识到了这个问题,将上面的模板信息存入数据库是很安全的做法,但是为啥我们在最开始的时候可以搜索到这个config.php文件呢?从程序设计的角度猜测,在应用刚刚安装在服务器中时,数据库中被没有对应数据,所以需要一个config.php文件作为初始化的内容,当应用正常执行后,config.php作为初始化的作用就不存在了,所以config.php就不需要了。同时,当我们再次刷新的时候,这个config.php文件出现了,但是输入的’被转义了。0x04 从任意文件删除到RCE
通过分析,发现包含可控参数的php文件成为主要方向后,立刻就有一个文件出现在了我们的视线内,那就是数据库配置文件:
这个文件作为程序连接数据库的根本,是功能文件的同时,内部的全部字段均有我们控制,想通过这个文件实现RCE便有两个前提:
我们可以通过任意文件删除漏洞导致应用重装。
在写入db.php的工程中,程序没有对我们输入的数据进行判断。
4.1任意文件删除漏洞
为了实现应用重装,就需要删除应用中的install.lock文件。
定位QSCMS_DATA_PATH常量确定了delete()方法的执行目录
访问
url:?m=admin&c=Baiduxml&a=index
点击删除所选获取请求包。
修改数据包内容:
成功删除install.lock文件导致应用重装。
4.2: 重新安装中的RCE
在这一步中的输入的内容便是数据库配置文件db.php中的内容。
在这个输入的过程中有两点需要注意:
1、数据需要在数据库连接测试后才能写入文件,当然在实战中我们不可能有他的数据库账号密码,所以需要我们在vps开启一个mysql服务,在数据库账号密码地址中填写我们远端的信息即可,当然,这里也可以造成一个低危的SSRF,同时数据库主机字段,数据库用户名字段,数据库密码字段也都不能作为注入对象。
2、由于写入的文件是在return的array中的,导致不能通过闭合array()来执行恶意代码,恶意代码必须在array中执行。
在程序安装的过程中数据库名,或者数据库表前缀修改成abc_’.phpinfo().’
点击下一步依旧出现了安装成功的页面,这里很明显程序并没有对是否在数据库中写入数据进行校验,这也是出现这个RCE的一部分原因。
最后再次访问主页执行phpinfo()
可以正常的写入shell
0X05 总结
通过之前的DedecmsRCE复现获得了一种RCE的思路,并且很快在这次漏洞挖掘中实践,同时分析了config,php文件被恶意代码注入带来的危害和产生的原因,并且将中危的任意文件删除变成RCE,在这整个过程的最后,也算是获得了新的RCE挖掘方向。
▇ 扫码关注我们 ▇
长白山攻防实验室
学习最新技术知识
真正免费的cms系统