CVE-2021-26084: Confluence Webwork Ognl表达式注入漏洞分析
本文首发于安全客：https://www.anquanke.com/post/id/253398
0x00 前言
本文主要讲述了在复现以及分析CVE-2021-26084过程的遇到的一些疑惑。其次，本文对该漏洞进行了一个相对完整的漏洞链的分析。由于笔者初次分析Confluence的漏洞，难免有所不足，恳请各位看官老爷斧正。
Confluence是一个团队协作软件，用于知识分享(WIKI)和团队协作。Confluence将工作的环境称为空间，比如为每个项目创建一个空间，设置用户权限，通过pages添加wiki、想法、事件等等。1
该漏洞有多个触发点，但不需要授权的触发点位于：pages/createpage-entervariables.vm，本文将围绕该触发点进行分析。2
0x01 环境搭建
本次漏洞分析采用了docker环境Confluence 7.12.4版本。如有需求，请移步：搭建教程。
0x02 Ognl表达式注入分析
从补丁文件：cve-2021-26084-update.sh发现本次补丁只是针对5个.vm结尾的模板文件做了字符串替换，并没对代码逻辑进行更改。具体细节如下：
修改
confluence/users/user-dark-features.vmxxxxxxxxxx11value='$!action.featureKey' => value=featureKey7.12.4版本已经对该文件进行了更改
修改
confluence/login.vmxxxxxxxxxx11value='$!action.token' => value=token7.12.4版本已经对该文件进行了更改
修改
confluence/pages/createpage-entervariables.vmxxxxxxxxxx21value='$!querystring' => value=querystring2value='$linkCreation' => value=linkCreation修改
confluence/template/custom/content-editor.vm对多个input标签进行了value的替换，主要是将value中的$去掉
xxxxxxxxxx11"Hidden" "name='linkCreation'" "value='$isLinkCreation'" => "Hidden" "name='linkCreation'" "value=isLinkCreation"修改JAR文件的中
templates/editor-preload-container.vmxxxxxxxxxx11value='$!{action.syncRev}' => value=syncRev
综合上述5处改动，1和2不存在于7.12.4版本，3和4触发点的input标签相同，但4和5需要授权。所以此处对3号触发点进行分析，3号触发点的input标签如下：
xxxxxxxxxx91<form name="filltemplateform" method="POST" action="doenterpagevariables.action">2#form_xsrfToken()3#tag ("Hidden" "name='queryString'" "value='$!queryString'")4#tag ("Hidden" "name='templateId'" "value='$pageTemplate.id'")5#tag ("Hidden" "name='linkCreation'" "value='$linkCreation'")6#tag ("Hidden" "name='title'" "value=title")7#tag ("Hidden" "name='parentPageId'" "value=parentPageId")8#tag ("Hidden" "name='fromPageId'" "value=fromPageId")9#tag ("Hidden" "name='spaceKey'" "value=spaceKey")
结合github上的分析文章3，出漏洞的点在于queryString、linkCreation。观察这6个标签，我产生了如下问题：
- 为什么queryString可以触发而title触发不了，即$符号扮演的角色？
- pageTemplate.id也有$符号，为什么它不是漏洞触发点？
- 如何绕过单引号限制？
带着这3个问题，我开始深入的分析该漏洞。首先，分析整个漏洞的触发过程，由于漏洞是由Ognl表达式注入造成，所以可以先对含有Ognl.getValue的代码下断点，对WEB-INF/lib进行反编译后，我找到了如下3个地方：
com/opensymphony/xwork/util/OgnlUtil.java#copy()
图1 com/opensymphony/webwork/views/jsp/ui/OgnlTool.java#findValue()
图2 com/opensymphony/xwork/util/OgnlValueStack.java
图3
对这几个点打上断点后，我开始调试Confluence，经过测试发现触发断点的代码在com/opensymphony/xwork/util/OgnlValueStack.java
为了理清整个输入的处理过程，需要从上游开始分析，如图7所示，左侧可以发现此处要进入WebWork的对doenterpagevariablesaction进行处理。
跟进处理函数，来到Velocity模板处理类，如图8所示，首先会通过getTemplate加载finalLocation指定的模板，然后通过处理context，将结果写入writer。
来到Template类的处理逻辑，通过将模板生成的语法树转化为SimpleNode节点进行处理。从图9 右侧的变量区可以看到模板一共生成了8个子树，input标签位于7号子树，如图10 所示。
如图11所示，最终会通过AbstractTagDirective类对标签进行处理。如图12所示，processTag函数通过doEndTag函数调用evaluateParams从OgnlValueStack中获取相关变量的值，如name=queryString。
evaluateParams函数需要关注两个地方，第一是通过nameAttr计算name。即把'queryString'变成name=queryString
重点关注第二处，即value=xxx的计算，如图14所示。
进入findValue函数，在图15中可以看到在真正的去计算Ognl表达式前，会调用静态方法SafeExpressionUtil.isSafeExpression对编译后的结果进行安全检查。一共包括四个方面：
- 第一个hashset限制了构造函数的关键字：new，静态方法调用：@符号
- 第二个和第三个hashset限制了获取classloader，如：xxx.class或者xxx.getClass()
- 第四个hashset限制了编译后的结果中不能出现特定的变量
这里绕过方式可以使用数组进行绕过，如：""["class"].forName4
findvalue通过OgnlValueStack#findValue实现了对表达式的计算，如图16所示，OgnlUtil会正确的识别\u0027为'，将表达式变成一个完整Ognl表达式，最终调用Ognl.getValue计算表达式。
0x03 疑问解答
1. 单引号的处理逻辑
先说答案：处理tag时会从OgnlValueStack中根据nameattr和valueAttr取值并计算，这两个属性通过applyAttributes设置，applyAttributes用Ognl在初始的context上下文中获取到parameters提交的值，经过ConfluenceHtmlEntityEncodingPolicyHTML实体编码类处理。所以'会被实体编码，但由于Ognl表达式可以正常处理unicode编码的单引号\u0027，所以可以用unicode编码替代。
0x02中分析了一个完整的触发流程，但需要注意的是该payload中利用了unicode编码：'=>\u0027。那么为什么'不行呢？看到上文的processTag部分，如图17所示，processTag需要的参数通过object传入。
将输入改为：queryString=aaa'%2b#{2*1}%2b\u0027bbb。跟进applyAttributes函数，该函数用createPropertyMap创建一个MAP对象用于接下来的属性设置，createPropertyMap主要调用putProperty函数，其主要逻辑位于node.value函数。
经过跳转会进入ASTReference的处理逻辑，首先通过execute方法从上下文中取值(这里实际上也是用OgnlValueStack的findValue来做)。此函数先不做分析，继续来到EventHandlerUtil.referenceInsert(this.rsvc, context, this.literal(), value)，该函数中会用HTML实体编码处理单引号，如图19和图20所示。
2. $符号作用
在1中讲到：
applyAttributes函数用createPropertyMap创建一个MAP对象用于接下来的属性设置，createPropertyMap主要调用putProperty函数，其主要逻辑位于node.value函数。
为了知道有无$符号的区别，需要知道node.value具体取值的逻辑。该函数根据节点树的属性：interpolate判断是否该通过Ognl进行计算，如图21所示，此时计算的是queryString的值，queryString的标签为：#tag ("Hidden" "name='queryString'" "value='$!queryString'")，带有$符号，其interpolate属性为true，会通过Ognl计算。
那么title如何呢？
title由于没有设置$，被当成字符串。所以只会原原本本的返回value=title，而最终通过OgnlValueStack进行计算的也只是expr="title"，如图22所示。
3. pageTemplate.id也有$符号，为什么它不是漏洞触发点？
为了弄清$pageTemplate.id没触发的原因，将输入改为：templatePage=aaa\u0027%2b#{2*1}%2b\u0027bbb，在rootString为pageTemplate时截断，如图23所示。此时获取到的值已经为null，证明OgnlValueStack中存放的值也是null，pageTemplate的值在这之前已经被设置为null。当value为null时，会使用nullString替代，如图24所示。
既然之前就已经设置了OgnlValueStack中pageTemplate的值，则需要对OgnlValueStack中setValue函数下断点，如图25所示。
经过多次跳转，来到图26所示，通过OgnlRuntime.hasSetProperty函数判断是否该设置属性。
跟进该函数后，该函数通过getClass方法获取了PageVariablesAction类。然后判断其是否有setxxx的方法，如：queryString=>setqueryString()。如图27所示。而PageVariablesAction类及其继承的父类都不存在setpageTemplate方法，所以pageTemplate只能为null。
参考