某OA接口绕过后任意文件上传分析

Delina

最近公开了某OA的任意文件上传POC，想着来分析一下，下面截图代码为github找到。
上传漏洞的利用接口如下所示：

/weaver/weaver.common.Ctrl/.css?arg0=com.cloudstore.api.service.Service_CheckApp&arg1=validateApp
看POC注意到接口后面多了一个.css,根据以往的经验应该是用于权限认证绕过。抓包进行验证结果如下所示：
当接口后面跟.css,请求返回状态码为200，如下所示：
​
当接口后面不跟.css时，返回状态码为403，如下所示：
​
由此可以判断.css是用于权限绕过。接下来通过POC入口逆向来分析该漏洞成因。
翻阅资料知道该系统写了全局安全防护规则，当用户请求触发相应防护规则时会记录触发规则及IP等信息。查看日志发现触发了该条规则weaver.security.rules.SecurityRuleQX20
​
该规则防护源码如下所示：
​
当请求URL中包含字符weaver，common ,ctrl等字符时就会触发该条防护规则。这时就又有一个疑惑。绕过访问控制的POC/weaver/weaver.common.Ctrl/.css中不是同样存在这些字符嘛为啥没有触发该规则。根据经验判断可能是该系统的全局过滤器在处理URL后缀为.css时，进行了白名单验证放过，不进入防护规则判断。
查看web.xml文件中的安全防护规则filter入口为weaver.filter.SecurityFilter,匹配过滤全局路径，如下所示：
​
weaver.filter.SecurityFilter源代码中的initFilterBean函数用于初始化系统防火墙即加载所有防护规则:
​
跟入weaver.security.filter.SecurityMain的initFilterBean函数启动并导入所有规则类：
​
weaver.filter.SecurityFilter中初始化系统防火墙后之后进行doFilterInternal用于过滤校验前端传入数据是否满足安全要求：
​
请求数据及FilterChain传入weaver.security.filter.SecurityMain的process函数继续跟入，idea反编译失败wtf：
​
使用JD进行反编译发现如下所示代码：

1. Object localObject7 = str2.toLowerCase().trim();         
   
2. if ((((String)localObject7).endsWith(".cur")) || (((String)localObject7).endsWith(".ico")) || (((String)localObject7).endsWith(".css")) || (((String)localObject7).endsWith(".png")) || (((String)localObject7).endsWith(".jpg")) || (((String)localObject7).endsWith(".gif")))
   
3.           {
   
4.             if (!localSecurityCore.null2String(localSecurityCore.getRule().get("OA-Server")).equals("")) {
   
5.               localHttpServletResponse.addHeader("Server", localSecurityCore.null2String(localSecurityCore.getRule().get("OA-Server")));
   
6.             }
   
7.             localSecurityCore.addHeader(localHttpServletRequest, localHttpServletResponse);
   
8.             paramFilterChain.doFilter(paramHttpServletRequest, paramHttpServletResponse);

复制代码

str2为获取的请求URL，故上述代码为URL后缀为cur、ico、css、png、jpg、gif时即可跳过该filter链校验即不用进行上述weaver.security.rules.SecurityRuleQX20的校验，之后跟进调用paramFilterChain.doFilter进入下一条filter链：​

将POC中的绕过.css换成.cur发现同样绕过访问限制，如下所示：
​
web.xml之后的filter并未对器防护过滤故直接进入最终的resource处即weaver.common.Ctrl方法：
​
前台传入arg0，arg1参数，并调用doInvoke以arg0参数为类对象，arg1参数为相应类的方法。跟进POC中的arg0=com.cloudstore.api.service.Service_CheckApp&arg1=validateApp,获取前端数据流导入zip压缩包再进行文件解压：
validateApp函数
​
createLocalApp函数
​

decompress函数
​