关于漏洞:CVE202242889-Apache-Commons-Text-RCE漏洞分析

前言

最近始终在对刚研发进去的自动化 Web/API 破绽 Fuzz 的命令行扫描工具进行保护更新（工具地址：https://github.com/StarCrossP…），目前扫描工具已更新至第三个版本，新增了 5 条 2022 年 CVE 破绽 POC，修复了例如 Content-Type 和 body 类型不统一等问题。最新版本测试稳固，满足 Web/API 的破绽 Fuzz 和多场景的破绽检测，欢送大家试用。

在保护更新扫描器 POC 库时，笔者看到了这个被称为“Textshell”的 CVE 破绽，决定学习剖析一波。

我的项目介绍

Apache Commons Text 是一个低级库，用于执行各种文本操作，例如本义、计算字符串差别以及用通过插值器查找的值替换文本中的占位符。

破绽形容

2022 年 10 月 13 号，官网公布了 Apache Commons Text 的破绽通告，破绽编号：CVE-2022-42889。Apache Commons Text 执行变量插值，容许动静评估和扩大属性。插值的规范格局是“${prefix:name}”，其中“prefix”用于定位执行插值的。

org.apache.commons.text.lookup.StringLookup 的实例。从 1.5 版到 1.9 版，攻击者可结构歹意文本，使得 Apache Commons Text 在解析时执行任意恶意代码。

利用范畴

1.5 <= Apache Commons Text <= 1.9

破绽剖析

环境搭建

IDEA 通过 Maven 导入依赖

pom.xml 如下：

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-configuration2</artifactId>
        <version>2.7</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-text</artifactId>
        <version>1.9</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.12.0</version>
    </dependency>
</dependencies>

测试代码：

package org.text;

import org.apache.commons.text.StringSubstitutor;

public class Main {public static void main(String[] args) {StringSubstitutor interpolator = StringSubstitutor.createInterpolator();
//        String payload = interpolator.replace("${script:js:new java.lang.ProcessBuilder(\"calc\").start()}");
        String payload = "${script:js:new java.lang.ProcessBuilder(\"calc\").start()}";
        interpolator.replace(payload);
    }
}

JDK 版本 1.8

动态分析

在代码剖析之前，咱们先看看官网用户手册（https://commons.apache.org/pr…）中的内容。

这里演示了应用默认查找 StringSubstitutor 来结构简单字符串的用法，而破绽形容中的关键所在就是执行变量插值，其规范格局是 ${prefix:name}。

参考下 StringLookupFactory 的文档（http://commons.apache.org/pro…）

自从 1.5 版本之后，能够满足 script 类型的字符串查找，然而并不是默认包含的。
将代码定位到
org.apache.commons.text.lookup.InterpolatorStringLookup#lookup

这里 lookup 办法会提取”:“后的局部作为 prefix 值，而后依据 stringLookupMap 提取其对应的 lookup 实例化对象。
到 org.apache.commons.text.lookup.ScriptStringLookup#lookup 中。

调用 ScriptEngineManager 执行代码。

理解了破绽后半局部，打下断点，动静调试一下，看看如何调用 lookup 办法。

org.apache.commons.text.StringSubstitutor#createInterpolator

这里就是实例化了 StringSubstitutor 并向其中传入 StringLookupFactory.INSTANCE.interpolatorStringLookup()
org.apache.commons.text.StringSubstitutor#replace

对参数转换类型，而后传入 substitute 解决，后续将通过一系列判断查看。

最初传入 resolveVariable

org.apache.commons.text.StringSubstitutor#resolveVariable

在 getStringLookup 的值之后，就会间接到 org.apache.commons.text.lookup.InterpolatorStringLookup 中调用 lookup 办法。

到这里，正如结尾所剖析的那样 lookup 办法会提取”:“后的局部作为 prefix 值，而后依据 stringLookupMap 提取其对应的 lookup 实例化对象，最初通过调用 ScriptEngineManager 执行代码。

破绽复现

当然，网上曾经有很多大佬对这个进行了剖析，此破绽与 Log4Shell (CVE-2021-44228) 其实是不同的，因为在 Log4Shell 中，能够从日志音讯注释中进行字符串插值，该注释通常蕴含不受信赖的输出。在 Apache Common Text issue 中，相干办法明确用于执行字符串插值并明确记录在案，因而应用程序不太可能在没有适当验证的状况下无心中传递不受信赖的输出。

破绽检测工具

工具地址：https://github.com/StarCrossP…

已更新：

目前扫描工具已更新至第三个版本，新增对 CVE-2022-0885、CVE-2022-1054、CVE-2022-1392、CVE-2022-21500、CVE-2022-23854 破绽的检测，已内置 100+ 破绽 POC，修复了例如 Content-Type 和 body 类型不统一等问题。最新版本测试稳固，满足 Web/API 的破绽 Fuzz 和多场景的破绽检测。
**
继续更新：**

破绽 POC、扫描工具破绽检测优化（检测逻辑，满足对须要间断数据包关联操作破绽场景的检测）