环境搭建

漏洞审计

路由分析：

在index.php文件中包含 coreframe 框架下core.php文件并调用load_class加载

然后在application.class.php 文件、core.php 框架核心文件

调用了load_class加载类。然后通过load_class()类实例化wuzhi_application类

通过 load_class() 类实例化 WUZHI_application 类。

实例化 WUZHI_application 类调用下面构造方法

调用 WUZHI_application 类下 run() 方法获取路由信息

抓包查看他的路由访问规律

1.sql注入

漏洞路径/coreframe/app/member/admin/group.php

下的 del() 函数

在代码133行判断是否传入groupid参数且参数是否为空，条件满足在134行代码中判断传入的groupid是否为数组。

跟进delete()函数，在db.class.php中找到对应函数。

而下面223行的delete()函数才是真正去操作数据库的函数，我们跟进这个delete()

在这个过程中我们传入的sql语句并没有进行任何过滤就直接拼接到$sql并通过query()执行，所以这里存在SQL注入漏洞。

在query()函数中如果出现SQL语句错误会直接爆出SQL语句，所以这里存在报错注入。

漏洞复现：

2.任意文件写入

使用工具或者全局搜索file_put_contents函数

通过Seay的审计结果，翻找到一处可能存在任意文件写入的地方。

通过翻找发现一处可以直接控制 $data 的文件：

oreframe/app/attachment/admin/index.php

这里的 ueditor() 函数调用了 set_cache() 并且这里的 $GLOBALS['setting'] 参数可控。

假如不设置submit，则会通过 get_cache() 读取缓存文件内容。

漏洞复现：

通过前面路由分析以及上面SQL注入的路由，我们可以构造出调用ueditor()的路由：

/index.php?

m=attachment&f=index&v=ueditor&_su=wuzhicms&submit=XXX&setting=payload

文件已被成功写入到缓存文件中

读取缓存中文件内容