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文件出现了，但是输入的’被转义了。猜测这是因为应用在模块化开发时，并没有和数据库对接，同时又需要对模块进行测试，因此开发人员选择了生成cache文件config.php用来导入前端，这样即做到了从数据库导入，同时也做到了无数据库时对功能进行测试。总结：原因主要就是config.php中的内容作为被展示在前端是数据，无重要功能，是由于应用的模块化开发出现的产物，因此，在这个CMS有没有作为功能文件的php文件中存在可以控制的内容，就成为主要寻找目标。0x04 从任意文件删除到RCE
通过分析，发现包含可控参数的php文件成为主要方向后，立刻就有一个文件出现在了我们的视线内，那就是数据库配置文件：
这个文件作为程序连接数据库的根本，是功能文件的同时，内部的全部字段均有我们控制，想通过这个文件实现RCE便有两个前提：
我们可以通过任意文件删除漏洞导致应用重装。
在写入db.php的工程中，程序没有对我们输入的数据进行判断。
4.1任意文件删除漏洞
为了实现应用重装，就需要删除应用中的install.lock文件。
非常巧的时候，通过代码审计，我还真就发现了任意文件删除漏洞！在全局搜索unlink方法时，我发现了baudixml下的delete()，很明显这个方法获取了POST中的file_name后在147行无过滤就放入了unlink()方法，造成了任意文件删除。所以通过这个方法便可以删除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系统
