Confluence CVE-2022-26134 OGNL 分析

2022-06-10

发现半年没写文章了。。。

0x01 环境搭建

P🐮的Vulhub 有镜像了，不过调试接口没有开出来，这里稍微补充下。

在vulhub/confluence/CVE2022-26134 目录下

新建Dockerfile

1
2
3

FROM vulhub/confluence:7.13.6

RUN sed "106 iCATALINA_OPTS=\"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 \$\{CATALINA_OPTS\}\"" -i /opt/atlassian/confluence/bin/setenv.sh

更新docker-compose.yml

build: .
# image: vulhub/confluence:7.13.6
ports:
  - "8090:8090"
  - "5005:5005"

1	docker-compose up -d

0x02 漏洞分析

Y4er 师傅关于漏洞的总结得挺好的，漏洞复现这块已经没什么好讲的了。

漏洞的调用栈
黑白名单的绕过

POC: curl -v "http://192.168.1.112:8090/%24%7B1+1%7D/"

1 2	${@com.atlassian.confluence.util.GeneralUtil@setCookie("key","value")}

upload successful

最终的调用栈如下：

findValue:129, OgnlValueStack (com.opensymphony.xwork.util)
translateVariables:39, TextParseUtil (com.opensymphony.xwork.util)
execute:95, ActionChainResult (com.opensymphony.xwork)
executeResult:263, DefaultActionInvocation (com.opensymphony.xwork)
invoke:187, DefaultActionInvocation (com.opensymphony.xwork)
intercept:21, FlashScopeInterceptor (com.atlassian.confluence.xwork)
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
intercept:35, AroundInterceptor (com.opensymphony.xwork.interceptor) [3]
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
intercept:27, LastModifiedInterceptor (com.atlassian.confluence.core.actions)
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
intercept:44, ConfluenceAutowireInterceptor (com.atlassian.confluence.core)
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
intercept:35, AroundInterceptor (com.opensymphony.xwork.interceptor) [2]
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
invokeAndHandleExceptions:61, TransactionalInvocation (com.atlassian.xwork.interceptors)
invokeInTransaction:51, TransactionalInvocation (com.atlassian.xwork.interceptors)
intercept:50, XWorkTransactionInterceptor (com.atlassian.xwork.interceptors)
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
intercept:61, SetupIncompleteInterceptor (com.atlassian.confluence.xwork)
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
intercept:26, SecurityHeadersInterceptor (com.atlassian.confluence.security.interceptors)
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
intercept:35, AroundInterceptor (com.opensymphony.xwork.interceptor) [1]
invoke:165, DefaultActionInvocation (com.opensymphony.xwork)
execute:115, DefaultActionProxy (com.opensymphony.xwork)
serviceAction:56, ConfluenceServletDispatcher (com.atlassian.confluence.servlet)
service:199, ServletDispatcher (com.opensymphony.webwork.dispatcher)
service:764, HttpServlet (javax.servlet.http)

0x03 思路逆向

关于漏洞如何发现的，个人理解可以拆分成3个阶段

如何定位到去挖confluence
如何发现ognl攻击面，也即sink点
如何从sink点推导出source及path

这些都是很有意思的点，值得思考。这里也只尝试逆向分析步骤3的思路，步骤1、2太过宽泛了有时间再做探讨。

sink 到source

sink 点其实很明显，ognl.getValue，在此基础上如何找到完整的触发链？

source点在javax.servlet.http.HttpServlet#service，需要对confluence 结构有一定了解，或者要调试下历史的漏洞，应该能定位到这里。

如何找出中间的链，confluence没有源码，所以tabby 或者 ByteCodeDL？

1	java -Xmx6g -jar build/libs/tabby-1.1.0.RELEASE.jar ../confluence/atlassian-confluence-7.13.6/confluence/WEB-INF/lib/ --isJDKProcess

// confluence CVE-2022-26134
match (source:Method {NAME:"service"}) where source.CLASSNAME =~ ".*ServletDispatcher"
match (sink:Method {NAME:"translateVariables", CLASSNAME:"com.opensymphony.xwork.util.TextParseUtil"}) 
call apoc.algo.allSimplePaths(source,sink,">CALL|ALIAS",9) yield path 
return path

upload successful

Y4师傅提到的一些其他的 *Result#execute，可以看到部分也在路径里面。

sink 点的定位

Semgrep 对于找sink点，和正则相比有一些优势，不过目前规则也不全。

- pattern-either:
    - pattern: |
       ognl.Ognl.getValue(...)
    - pattern: |
       ognl.Ognl.setValue(...)
    - pattern: |
        $X.translateVariables(... , ...)

1	semgrep --config=java/lang/security/audit/ognl-injection2.yaml ~/study/java/confluence/confluence-home/jars/

upload successful

对于jar类型，如果要实现完全自动化还是比较困难。反编译、自动化运行semgrep规则、再从sink点出发用Tabby找路径。目前也没有好的思路，学习《软件分析》吧。

0x04 补丁分析

upload successful
只是修了ActionChainResult 中的translateVariables。但是其他的Ognl 点也没找到触发链。

0x05 小结

本文简略的跟踪了Confluence CVE-2022-26134 OGNL的漏洞调用流程，并在此基础上探索其OGNL调用链的发现思路。分析了补丁，尝试挖掘其他的触发链，但是无果。基本内容Y4师傅的文章基本都有了，本文没什么新的东西。

总的来说这个洞原理并不难，st2 的ognl也是经典的漏洞了，但是为什么是黑产走在了技术前沿？纯技术而言，原理不难，但是较难自动化，主动挖掘也需要一定的漏洞历史知识。

老样子留个坑吧

只根据补丁，能够独立分析出POC吗？PS：业内谁最先搞出poc的
怎么会想到到去挖confluence的？
如何发现OGNL攻击面？

未完待续。。。

0x01 环境搭建

0x02 漏洞分析

0x03 思路逆向

sink 到source

sink 点的定位

0x04 补丁分析

0x05 小结

0x06 参考