Unc1e
Unc1e
WeCenter V3.0.1 代码审计

WeCenter代码审计

WeCenter代码审计

针对WeCenter 3.0.1的老版本作代码审计,学下mvc架构)

概览

  • 全局的防注入函数,没毛病。不过假如数据库编码为gbk时,可用宽字节搞一波
    > 用了mysql_real_escape_string,我们需要在执行sql语句之前调用一下mysql_set_charset函数,设置当前连接的字符集为gbk。否则仍然不能抵御宽字符注入。

  • cookie前面的三个字母前缀G_COOKIE_PREFIX,其实是cms自动生成的随机盐, 理论上这个值在不同的网站中必然不同

image.png

image.png

框架扫描1:gaudit

采用这套名为[gaduit](https://github.com/wireghoul/graudit/)的框架,对源代码进行静态扫描,排除了jssql文件

image.png

跟进漏洞报告分析,发现以下问题

0x01 /app/topic/ajax.php #70 topic_id参数sql注入

问题就出在$action_list = $this->model('topic')->get_topic_best_answer_action_list($_GET['topic_id'], $this->user_id, intval($_GET['page']) * get_setting('contents_per_page') . ', ' . get_setting('contents_per_page'));
直接将$_GET['topic_id']传入了get_topic_best_answer_action_list函数,跟进get_topic_best_answer_action_list

发现只对$topic_id进行了打散、合并的操作,相当于什么事情都没做,更不要说对sql语句进行过滤了
ref:漏洞标题: WeCenter SQL注射(ROOT SHELL)

框架扫描2:seay代码审计系统

0x02 /app/m/weixin.php #115 反序列化导致sql执行

参考了奶权师傅这篇文章里的叙述,对整个过程进行下分析

由于SQL语句的执行发生在析构函数__destruct()中,并且_shutdown_query没有被静态关键词static修饰。于是很自然可以想到利用反序列化的方式,重置$this->_shutdown_query的值。

首先/app/m/weixin.php #115存在可控的反序列化点。ps:反序列化会将字符串转换为对象。对象被创建时,会自动调用构造函数__construct;而对象被销毁时(如程序运行结束),会自动调用析构函数__destruct

image.png

那么我们找找能利用的析构函数,/system/aws_model.inc.php中,query函数对_shutdown_query变量进行了遍历,跟进query函数

image.png

query函数对$sql未加过滤,直接带入数据库中执行
image.png

因为没对_shutdown_query变量使用static修饰符进行修饰,因此_shutdown_query变量可以被我们控制
所以这就直接导致了任意sql代码的执行
构造payload的代码如下

具体利用,看这段乌云上的payload,报错注入

发表评论

textsms
account_circle
email

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据

Unc1e

WeCenter V3.0.1 代码审计
WeCenter代码审计 WeCenter代码审计 针对WeCenter 3.0.1的老版本作代码审计,学下mvc架构) 概览 全局的防注入函数,没毛病。不过假如数据库编码为gbk时,可用宽字节搞一…
扫描二维码继续阅读
2020-03-28
%d 博主赞过: