0x01 前言

最近疫情形势开始好转了，为了在漫长假期中保持学习，对CmsEasy的7.3.8版本进行了代码审计，也为之后自动化审计积累经验

CmsEasy是一个企业建站管理系统，是一个半开源的建站系统，其中部分核心代码被加密混淆过。审计时最新版本是更新于2019-12-30的7.3.8版本，审计中发现这个CMS出现了多个类型的安全问题，整体安全性有待提高。（下文分享的安全问题均已上报并修复，目前官网最新版是V7.5.3_20200209，更新于 2020-02-09）

通过搜索引擎发现使用该系统的站点数量还是比较多的

0x02 任意文件操作

“无需代码，自由拖拽布局，适应所有设备”是这个系统宣传的特色，后台自然地存在自定义网站模板功能，这种功能中如果处理不当很可能造成文件任意读、写或者删除的脆弱性问题，需要着重注意。

观察模板编辑功能，存在对模板的html文件的读取操作，对应到HTTP请求可以明显看到可控参数

看到功能不急着看代码，首先想到黑盒测试一下，手动修改id参数后观察发现可以这个接口果然没有做好限制和过滤，可以读取任意传参文件

观察接口URL中的参数，猜测除了fetch之外应该还有保存和删除的功能，但是功能接口的接收参数就不知道了，因此需要去看源码以进行下一步操作

定位到接口的功能函数文件后，发现经过了加密混淆处理。。。

经过一番操作后，最终得到了文件删除的接口函数大致内容，很明显地存在文件删除路径可控问题

同理，文件写也存在问题，这里就不详细列出了，感兴趣的朋友可以再看看

0x03 SQL注入

漏洞代码位于lib/admin/language_admin.php的add_action函数

在测试后发现CmsEasy V7.3.8框架已经对SQLi进行了转义和过滤，包括（select、* 、sleep等等），为了确定具体的过滤名单，从源码中查找检测函数

但是经过一番搜索后，源码中发现实际调用的注入检测函数并没有被定义，仔细研究后确定是在几个加密混淆的核心代码中实现了。。（闭源一定意味着安全吗？）——通过一番周折后得到函数

显而易见，这样简单的过滤很容易被部分SQLi关键组成字符绕过，导致SQL注入，例如，可以使用benchmark函数来代替sleep以达到基于时间的注入。除了通过得到源码来明确黑名单的，用fuzz同样可以得到过滤的黑名单，之后再想办法绕过

而类似的漏洞成因在同一个文件的edit_action函数中也存在

这两处接口都存在SQL注入漏洞，提交的payload绕过过滤黑名单后可以进行利用

0x04 本地文件包含

CmsEasy V7.3.8框架后端的语言编辑功能函数接口对include的文件路径没有做安全性校验，攻击者可以通过该接口包含上传的带有PHP代码内容的任意后缀（合法）文件，导致远程代码执行

漏洞代码位置是位于CmsEasy_7.3.8_UTF-8_20191230/lib/admin/language_admin.php文件中的edit_action函数

\$lang_choice是从用户的GET请求参数中直接获取的，\$langurlname是从数据库中获取的langurlname字段。后面将这两个参数直接拼接路劲赋值给\$path，这里的$lang_choice拼接在最后，可以任意赋值（为后面文件包含导致命令执行奠定基础）。

接着由于266行判断POST参数是否有submit，我们可以直接不传这个参数来绕开这一段的代码执行，到299行直接通过inlcude函数包含我们任意传递的值，导致文件包含

CmsEasy对于任何用户存在文件和图片上传功能，虽然我们不能直接上传php文件（默认禁止），但是可以上传内容为php代码的图片后缀文件，因此可以通过这一处文件包含达到最后高危的命令执行问题

这处安全问题其实是比较浅显的，可以通过污点传播直观地得出来，这类问题对于自动化审计来说应该属于比较容易发现的一类

0x05 小结

本文记录的几个审计过程中发现的安全问题都属于容易和浅显的，旨在起到抛砖引玉的作用。审这个CMS的一个感受就是，开源开一半或者闭源的产品其实某种程度上更容易存在安全问题。。。一叶障目并不是提高应用安全性的首选

冰山下还有更多的审计点和面等待深入的挖掘，目前官网最新版本已经更新到7.5.3，后续还有很多的问题等待大家去发现，感谢阅读