WebLogic coherence远程代码执行漏洞(CVE-2020-2555)

Insecure deserialization vulnerabilities have become a popular target for attackers/researchers against Java web applications. These vulnerabilities often lead to reliable remote code execution and are generally difficult to patch. In this blog post, we will investigate CVE-2020-2555 ([ZDI-20-128](https://www.zerodayinitiative.com/advisories/ZDI-20-128/)), which was reported to the ZDI by Jang from VNPT ISC. This critical vulnerability (CVSS score of 9.8) affects the Oracle Coherence library, which is used in popular products such as Oracle WebLogic Server. It was patched in [January](https://www.oracle.com/security-alerts/cpujan2020.html) along with 333 other bugs. **Studying the patch to find the source** Sources are Java method that can be invoked by an attacker with controlled parameters. In Java, the `readObject()` or `readExternal()` method of a class is automatically called in order to recreate the object graph. These two methods, and any other methods reachable from within them can be considered valid sources for deserialization gadgets. The patch for CVE-2020-2555 introduced a very interesting change to the `toString()` method of the `LimitFilter` class:  All calls to the `extract()` method have been removed from `toString()`. The significance of the extract() method will be addressed in the following section. This change is particularly interesting because `toString()` can be reached via the `readObject()` method of various standard JRE classes such as `BadAttributeValueExpException`:  As shown by the code above, a serialized instance of the `BadAttributeValueExpException` class can be used to call the `toString()` method of an arbitrary class. This technique can be used to reach the `toString()` method of the `LimitFilter` class affected by this patch. For examples of gadgets that use `toString()` as an entry point see the CommonsCollections5 gadget of the [ysoserial](https://github.com/frohoff/ysoserial) project. **Looking for a sink**. Sinks are Java method calls known to have hazardous side effects. Examples of such side effects are: ​ -- Arbitrary file creation via a call to `FileOutputStream.write()`. ​ -- Arbitrary command execution via a call to `Runtime.exec()`. ​ -- Arbitrary method invocation via a call to `Method.invoke()`. For this vulnerability, our focus is a call to `Method.invoke()` which has the side effect of calling arbitrary Java methods via reflection. Given this information, we can look for all instances where an `extract()` method call, which we identified as an entry point in our analysis of the patch, results in a call to `Method.invoke()`. There appears to only be one instance of such a serializable class (implementing the `Serializable` or `Externalizable` interface) in the Coherence library.  A look at the `ReflectionExtractor` class confirms our suspicion.  `ReflectionExtractor` offers a dangerous primitive by allowing us to call arbitrary methods, where both the method and parameter can be controlled by the attacker. **Road to RCE** Typically, more than one method call is required to achieve remote code execution. For example, in the popular Apache Commons Collections gadgets, this is achieved by chaining arbitrary method invocations using `ChainedTransformer`. In a similar fashion, there is a class in the `Coherence` library that allows us to chain `extract()` calls, which is conveniently named `ChainedExtractor`:  Putting all this together means that the following chain can be used to achieve remote code execution:  Any project that uses the `Coherence` library in which you are able to deliver a malicious serialized object can hence be exploited for remote code execution. For our purposes, we demonstrate an attack against WebLogic’s T3 protocol in the following video: <iframe src="https://www.youtube.com/embed/VzmZTYbm4Zw?wmode=opaque&amp;enablejsapi=1" height="480" width="854" scrolling="no" frameborder="0" allowfullscreen="" id="yui_3_17_2_1_1583459446713_71" style="position: absolute; top: 0px; left: 0px; width: 700px; height: 393.438px;"></iframe> **Conclusion** Ever since a talk at [AppSecCali](https://frohoff.github.io/appseccali-marshalling-pickles/) by Chris Frohoff and Gabriel Lawrence led to the so-called Java Deserialization Apocalypse of 2015 and 2016, researchers have looked to deserialization bugs for reliable code execution. We’ve seen many bugs of this class submitted to the program and used during the Pwn2Own Miami event against SCADA applications. It’s also one of the reasons we drew special attention to deserialization bugs in the Trend Micro Security Predictions for 2020 [report](https://www.trendmicro.com/vinfo/us/security/research-and-analysis/predictions/2020). Thanks again to Jang from VNPT ISC for submitting this bug to the program, and we hope to see more reports from him in the future. You can find me on Twitter at [@zebasquared](https://twitter.com/zebasquared), and follow the [team](https://twitter.com/thezdi) for the latest in exploit techniques and security patches.