上一篇文章主要对 CVE-2022-26134 Confluence OGNL 表达式注入漏洞进行原理分析，并简单描述了沙箱绕过与命令回显的问题。
CVE-2022-26134 Confluence OGNL RCE 漏洞深入分析和高版本绕过沙箱实现命令回显
QCyber，公众号：且听安全CVE-2022-26134 Confluence OGNL RCE 漏洞深入分析和高版本绕过沙箱实现命令回显
本文作为下篇，由漏洞空间站入圈小伙伴 ACyber 分享，主要对比不同版本下 Confluence 的 OGNL 解析的不同，并分享沙箱绕过与命令回显的历程。
熟悉 Confluence 的小伙伴可能在对该漏洞调试时发现一个问题，就是从 7.15 版本开始，无法像低版本一样直接注入 OGNL 表达式来实现命令执行等效果了，深入代码分析可以发现，从 7.15 系列开始，Confluence 在解析 OGNL 表达式的位置添加了沙箱，即在 `com.opensymphony.xwork.util.OgnlValueStack#findValue` 存在黑白名单形式的过滤。
7.14 及以下的版本无过滤：
7.15 及以上的版本存在检查：
所以直接通过调用如 `java.lang.Runtime` 等形式都会被拦截。
既然知道高版本不适用低版本 RCE 的问题所在，那让我们来分析以下沙箱原理尝试绕过。
跟进可以看到安全检查主要分为以下 4 个部分：
（1）首先检查缓存的黑白名单是否能匹配，这里默认为空，所以基本可以认为是无感的。
（2）调用 `isUnSafeClass` 方法进一步检查，跟进如下：
这里采用黑名单方式对调用的类进行检查。
（3）采用白名单的方式进行检查，如果属于白名单的类则直接添加进白名单缓存。
（4）对表达式进行解析，然后递归式的分析表达式 `tree` 的每个结点：
跟进 `containsUnsafeExpression` 方法：
首先采用黑名单方式过滤掉静态变量、创建对象、赋值操作：
然后分别对静态方法调用、属性调用、方法调用、变量调用、常量调用等进行检查，尤其静态方法调用的位置采用白名单对允许调用静态方法的类进行限制，所以 OGNL 表达式常规的通过 `@[类名]@[方法名]` 调用如 `java.lang.Runtime` 的形式无法使用，且 `#request` 、 `#context` 等直接调用 OGNL 上下文变量的形式也在变量调用检查中被禁止。
这里得到了 QCyber 师傅的帮助，解决了高版本沙箱绕过问题。其实分析了上述沙箱机制之后，我们还是可以想到通过反射的方式来调用一些被禁止的类或方法。结合 OGNL 调用静态方法时需要用到 `@` 符号，所以在刚开始调试时，很显而易见的使用了 `@java.lang.Class@forName` 的形式，但可想而知是无法满足过沙箱条件的。
但是 QCyber 师傅提供了一种方法，就是 OGNL 表达式里直接使用 `Class.forName` 的形式，经过测试，这种形式不仅可以绕过沙箱检测（不属于 OGNL 表达式里的静态方法调用形式，所以可以过静态调用的检查，也没有出现 `java.lang` 等形式，满足了黑名单的检查等），还可以被 OGNL 正常解析。
但是直接用 `Class.forName` 调用 `java.lang.Runtime` 等还是不行，因为在沙箱第 4 步对 OGNL 表达式各个 `node` 检查时仍然会检查到黑名单类。经过和各位师傅的探讨和交流，总结出以下 4 种方式：
0x01 方式1：使用正常功能类
调用 Confuence 自带的正常功能类。可以尝试寻找全局变量或者函数进行修改，可能达到恶意目的。比如 `com.atlassian.confluence.util.GeneralUtil` 类不在黑名单中，里面存在多个静态方法，比如可以构造 payload 实现添加任意 Cookie 值：
0x02 方式2：字符串拼接
`Class.forName('java.lang.Runtime')` 这种形式之所以不行，是因为在对常量调用检查时匹配到调用了 `java.lang.Runtime` 黑名单。所以这里可以通过字符串拼接的形式分割 `java.lang.Runtime` ，比如 `Class.forName('jav'+'a.lang.Runtime')` 的形式，直接绕开黑名单匹配。
0x03 方式3：ClassLoader
使用不在黑名单中的 `ClassLoader` 类。分析沙箱黑白名单之后，发现 `com.sun.org.apache.bcel.internal.util.ClassLoader` 类不在黑名单中，既然可以拿到 `ClassLoader` 类那就万事大吉了，通过 `loadClass` 方法加载字节码，就可以自由发挥了。但是在高版本 jdk 中不适用，比如Confluence 如果使用自带的 11 版本的 JDK 就无法使用这个方法。分析发现 Confluence 自带了一个 `org.apache.bcel.util.ClassLoader` ，位于 `xalan.jar` JAR 包中，与 `com.sun.org.apache.bcel.internal.util.ClassLoader` 一样也可以加载 Java 字节码。
0x04 方式4：this
研究沙箱黑白名单发现，虽然过滤了 `#request` 、 `#context` 等变量，但是没有过滤 `this` 。OGNL 表达式是以 ` .` 进行串联的一个链式字符串表达式。而这个表达式在进行计算的时候，从左到右，表达式每一次计算返回的结果成为一个临时的“当前对象”，并在此临时对象之上继续进行计算，直到得到计算结果。而这个临时的“当前对象”会被存储在一个叫做 `this` 的变量中，这个 `this` 变量就称为 `this` 指针。而在本次漏洞触发位置，通过 `this` 获得的是 URL 目标 `Action` 对象，当然具体利用效果取决于获取到的 `Action` 对象。比如利用这种思路可以添加管理员。
到了这一步可以说已经适配出了全版本通杀的命令回显方案，但是就高版本来说不能像低版本一样直接调用 OGNL 上下文的 `context` 来构造回显。
那么思考，能不能还用前文讨论的低版本的回显方法，通过 OGNL 表达式解析取得自身的 `context` 变量，然后用 `context` 中的属性带回命令执行结果。当然是可以的。
首先经过研究发现 OGNL 表达式解析的关键在 `ognl.Ognl#getValue`的第 119 行， `tree` 变量来自于 `com.opensymphony.xwork.util.OgnlUtil#compile` ，所以如果可以直接通过反射调用 `com.opensymphony.xwork.util.OgnlUtil.compile().getValue` 就可以实现低版本命令回显效果。
要满足以下 2 个步骤：
-
实现 OGNL 表达式的套娃解析。就是 payload 中通过 `Class.forName` 反射调用 `OgnlUtil.compile().getValue` ；
-
取得当前 `OgnlValueStack` 的 `context` 和 `root`，保证上下文变量相同。
通过回溯堆栈，可以发现 `OgnlValueStack` 类的实例是在 `com.opensymphony.xwork.ActionChainResult.execute` 方法中通过 `ActionContext.getContext().getValueStack()` 取得，通过静态方法取得这正符合反射调用的需求，细节不再赘述。
通用回显效果如下：
直接利用 Confluence 自带的 `org.apache.bcel.util.ClassLoader` 加载
BCEL 字节码，可以执行任意 Java 代码，效果如下（借用 QCyber 师傅实现的截图）：
原文始发于微信公众号（白帽子社区）：【下篇】CVE-2022-26134 Confluence 多种通用型绕过沙箱姿势可实现命令回显
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论