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

This article mainly explains "how to solve the Oracle WebLogic RCE loophole". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to solve the Oracle WebLogic RCE loophole.

Find the source of the leak by analyzing the patch

The flaw lies in a Java method that an attacker will be able to call with controlled parameters. In Java, in order to recreate the object graph, the code will automatically call the readObject () or readExternal () methods in a class, and these and other methods can be seen as a valid source of gadget deserialization holes.

The vulnerability patch for CVE-2020-2555 introduces a very interesting modification, which modifies the toString () method in the LimitFilter class:

All calls to the extract () method are removed from the toString () method. Let's not discuss the importance of the extract () method for the time being, but the interesting thing about this modification is that various standard JRE classes can call and access the toString () method through the readObject () method, such as BadAttributeValueExpException:

As we can see from the above code, a serialized instance of the BadAttributeValueExpException class can be used to call the toString () method in any class, and this technique can be used to call the toString () method in the LimitFilter class. Yes, it is the vulnerable LimitFilter class.

For an example of a gadget that uses the toString () method as an entry point, see the CommonsCollections5 gadget for the ysoserial project.

Deep analysis

It is well known that Sink method calls in Java are subject to security risks. For example, the following scenarios:

1. Create any file by calling the FileOutputStream.write () method

2. Execute arbitrary commands by calling the Runtime.exec () method

3. Call any other method by calling the method.invoke () method

In response to this vulnerability, we should focus on a call to Method.invoke (), and the side effect here is that any Java method can be called through reflection. Based on this given information, we can find the call to Method.invoke () caused by the extract () method call, which we identify as the entry point when analyzing the vulnerability patch. For example, there is a serializable class in the Oracle Coherence library that implements serializable and externalizable interfaces:

By analyzing the ReflectionExtractor class, we confirm our conjecture:

ReflectionExtractor provides a security-risky action primitive that allows attackers to call arbitrary methods in other classes, and attackers can even directly control specific methods and related parameters.

Implement remote code execution

In general, an attacker will need to call multiple methods to achieve remote code execution on the target device. For example, for common Apache Commons Collections gadgets, attackers need to use ChainedTransformer classes to concatenate arbitrary methods for remote code execution. Similarly, a class called ChainedExtractor is provided in the Oracle Coherence library, which allows us to concatenate calls to the extract () method:

After sorting out everything we have learned, we can use the following call chain to implement remote code execution:

Therefore, if the target uses the Oracle Coherence library, an attacker can achieve remote code execution in the target environment by sending a malicious serialization object.

At this point, I believe you have a deeper understanding of "how to solve Oracle WebLogic RCE loopholes". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.