首先来看一个历史漏洞，Ognl表达式注入导致RCE，具体payload如下

POST /common/common_sort_tree.jsp;.js HTTP/1.1
Host: xx.xx.xx.xx
Accept-Encoding: gzip, deflate
Content-Length: 174
Accept-Language: zh-CN,zh;q=0.8
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0 info
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Connection: close
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded

rootName={%25Thread.@fe.util.FileUtil@saveFileContext(new%20java.io.File("../web/fe.war/123.jsp"),new%20sun.misc.BASE64Decoder().decodeBuffer("d2hvYW1p"))%25}

首先该系统在未登录的状态下默认是无法直接访问一些jsp文件的

在web.xml中可以看到对jsp的使用的过滤器

查看ControllerFilter5中的doFilter

发现会判断uri的结尾是否是.jsp，判断jsp是否在白名单列表里，如果不在则返回302重定向到登陆页面，可以可以利用tomcat特性使用;绕过，因为 在URL中遇到;号会将;xxx/中的分号与斜杠之间的字符串以及分号本身都去掉，当然也可以用url编码绕过，这点在这里不做过多分析。

然后通过payload可以看到漏洞点在common_sort_tree.jsp，并且Ognl表达式通过rootName参数传递并执行，然后查看具体代码：

通过查看该jsp文件可以看到rootName通过传参得到，然后传入builder.buildExp方法

传入的语句首先会进行compiler生成一个列表，这个方法的主要功能是将输入的表达式进行编译，生成子表达式的列表，并在必要时替换原始表达式中的子表达式。该方法使用了一些标签和映射（startMap 和 stopMap）来辅助解析和替换。

然后在bean.xml中定义了一个parseMap 它表示了每个标签所对应的类方法，例如在payload中使用的是{%%}就对应使用的是objectValueParseImplbean 的标识符

然后使用该类的实现作为 bean 的实例。.

然后在初始化方法的时候，遍历parseMap，并且取前两个字符和后两个字符分别作为start(起始符)和stop(结束符)

然后使用this.analyse.addParse，生成mapValue

然后使用tanalyse.analy进行分析并返回结果

在analy中提取开始标签和结束标签和内容content

然后再这个analy方法中，首选会确定需要调用的函数，使用this.mapValue通过stop也就是尾部标识符获取对应的类名，这里的this.mapValue是一个hashmap，然后使用最下面的p.load调用对应的方法。在该方法中然后调用了getValue，这里代码就省略了

最终到达Ognl.getValue并执行Ognl语句造成RCE。

0x02 其他漏洞发现

了解完了历史漏洞触发的流程，可以发现漏洞的根本原因是最开始的builder.buildExp方法对参数过滤不严格造成的，如果按照这个思路去找漏洞，可以看看还有哪里调用了这个方法，并且参数是否可控。

分别在jsp和jar包中搜索相关关键字，发现没有其他的引用。

但是当我们回头看这个类中所定义的其他方法时，发现了其他和buildExp相似的方法

例如build，他和buildExp除了方法名不一样内容都是一样的

包括其他方法，也有简介的调用了build方法，例如：

所以这就大大扩大了我们的寻找范围，通过正则[.| ]+builder.build，找到了很多调用的地方，接下来就是看看哪些参数可控

这里找到其中一个，也就是上图搜索结果中的第一个：

但是这里的event会经过loginInvokeCtrl.formatLogic的格式化，在这个函数中，会在logic前后加上标识符，

但这并不影响，因为在build中的compiler会一层一层剥离语句，首先会执行最内层的标签里的语句。

接着继续追踪executeLogic看哪些地方调用了

在execute中，这两处均被调用了，并且参数时通过request.getParameter获得的，也是可控的。

但是该语句是在一个if判断条件中，需要满足用户登录或者指定的methodName和springId，这两个值也是通过request.getParameter直接获取到的

然后继续向上追踪，终于找到了触发的地方doPost

同样找到了它的url映射路径。至此，请求路径，以及所有的请求参数都是可控的，且请求参数可以直接传递到具有漏洞的方法里。

文章来源：奇安信攻防社区

链接：https://forum.butian.net/share/2701

作者：Duck

黑白之道发布、转载的文章中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用，任何人不得将其用于非法用途及盈利等目的，否则后果自行承担！

如侵权请私聊我们删文

END

原文始发于微信公众号（黑白之道）：某oa命令执行漏洞挖掘思路