Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Oracle WebLogic RCE Deserialization Vulnerability (CVE-2018-2628)

DZone's Guide to

Oracle WebLogic RCE Deserialization Vulnerability (CVE-2018-2628)

Oracle recently released its critical patch update (CPU) for the quarter. Read on to get a security experts view on the vulnerabilities included.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

On April 17, Oracle released the quarterly Critical Patch Update (CPU) advisory. Among the 254 new security fixes, the CPU also contained a fix for the critical WebLogic server vulnerability CVE-2018-2628. This is a Java deserialization vulnerability in the core components of the WebLogic server and, more specifically, it affects the T3 proprietary protocol.

According to the advisory, the CVE-2018-2628 is a high-risk vulnerability that scores 9.8 in the CVSS v3 system. This score is typical for RCE vulnerabilities that allow attackers to fully compromise a system by remotely executing code without authentication. The vulnerability was reported by Liao Xinxi of the NSFOCUS Security Team as well as a researcher by the name loopx9.

On April 18, multiple users on GitHub released proof of concept (POC) exploit code against this flaw. Soon after, reports indicated increased scanning activity for vulnerable, unpatched servers.

According to Oracle, the following WebLogic server releases are affected:

  • 10.3.6.0
  • 12.1.3.0
  • 12.2.1.2
  • 12.2.1.3

In order to apply Oracle's CPU, WebLogic customers must download the corresponding PSU updates from Oracle's support site and install the patch using Smart Update or OPatch. The following PSUs correspond to Oracle's April 2018 CPU:

  • PSU 10.3.6.0.180417
  • PSU 12.1.3.0.180417
  • PSU 12.2.1.2.180417
  • PSU 12.2.1.3.180417

For more information please consult Doc ID 1470197.1 from the Oracle support site.

This is not the first time that WebLogic was found to be vulnerable to a deserialization vulnerability. In November 2015, Oracle fixed CVE-2015-4852, another Java deserialization flaw in WebLogic. In October 2017, Oracle fixed CVE-2017-10271, an XML deserialization vulnerability which attackers have been exploiting to download cryptocurrency miners in victim systems.

Despite the fact that the April CPU contained a fix for the newly discovered CVE-2018-2628, researchers found ways around this patch. The protection bypass was inevitable because Oracle patched WebLogic by implementing a blacklist.

Using a blacklist approach has certain benefits such as easy configuration and is less likely to cause functional issues. However, blacklisting is a terrible security strategy. A blacklist is bound to be incomplete (see CWE-184) and requires constant maintenance. When adopting a blacklist approach for protection, developers are playing the Whac-a-Mole game and are committing to maintain the blacklist for every known exploit in order to be effective at scale.

Technical Analysis

Let's see how Oracle's blacklist works for CVE-2015-4852 and CVE-2018-2628.

The following packages are blacklisted and are not allowed to be deserialized:

  1. org.apache.commons.collections.functors
  2. com.sun.org.apache.xalan.internal.xsltc.trax
  3. javassist

Initially, as a protection to CVE-2015-4852, only the following classes were blacklisted:

  1. org.codehaus.groovy.runtime.ConvertedClosure
  2. org.codehaus.groovy.runtime.ConversionHandler
  3. org.codehaus.groovy.runtime.MethodClosure

In subsequent releases, this blacklist was extended to disallow these classes as well:

  1. org.springframework.transaction.support.AbstractPlatformTransactionManager
  2. sun.rmi.server.UnicastRef

Note that these are the packages and classes that are blacklisted by default. WebLogic administrators have the option to extend these lists.

These packages and classes were blacklisted because they are used as gadgets by known gadget chains (exploits). Blacklisting these gadgets allows Oracle to protect WebLogic against known POC exploits but this action does not remediate the issue but does avoid re-architecting the whole component.

Sophisticated attackers can bypass the blacklist by creating gadget chains with different sets of gadgets. One exploitation technique that authors have in their arsenal is the use of dynamic proxies.

Specifically for CVE-2018-2628, Oracle added one more protection based on a blacklist approach. This time, a specific blacklist was added at the deserialization of InboundMsgAbbrev instances that terminates the process if the instance implements the java.rmi.registry.Registry interface.

In other words, this protection disallows the use of exploits (gadget chains) that use dynamic proxies that implement the Registry interface in place of a legitimate InboundMsgAbbrev instance.

The use of the dynamic proxy can be seen in the following stack trace that shows the RCE attack in action:

java.lang.Runtime.exec()
sun.reflect.NativeMethodAccessorImpl.invoke()
sun.reflect.DelegatingMethodAccessorImpl.invoke()
java.lang.reflect.Method.invoke()
org.apache.commons.collections.functors.InvokerTransformer.transform()
org.apache.commons.collections.functors.ChainedTransformer.transform()
org.apache.commons.collections.map.LazyMap.get()
sun.reflect.annotation.AnnotationInvocationHandler.invoke()
$Proxy56.entrySet()
sun.reflect.annotation.AnnotationInvocationHandler.readObject()
sun.reflect.NativeMethodAccessorImpl.invoke()
sun.reflect.DelegatingMethodAccessorImpl.invoke()
java.lang.reflect.Method.invoke()
java.io.ObjectStreamClass.invokeReadObject()
java.io.ObjectInputStream.readSerialData()
java.io.ObjectInputStream.readOrdinaryObject()
java.io.ObjectInputStream.defaultReadFields()
java.io.ObjectInputStream.readSerialData()
java.io.ObjectInputStream.readOrdinaryObject()
java.io.ObjectInputStream.readObject()
sun.rmi.transport.StreamRemoteCall.executeCall()
sun.rmi.server.UnicastRef.invoke()
sun.rmi.transport.DGCImpl_Stub.dirty()
sun.rmi.transport.DGCClient$EndpointEntry.makeDirtyCall()
sun.rmi.transport.DGCClient$EndpointEntry.access$1600()
sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run()
java.lang.Thread.run()
java.lang.Thread.begin()
java.lang.Thread.invokeRun()
java.lang.Thread$ThreadHandler.invokeRun()

The above stack trace was captured in a POC attack that uses the JRMPClient and CommonsCollections1 ysoserial payloads on a Java 6u21 and WebLogic 10.3.6 system.

In a vulnerable system, WebLogic administrators can identify possible Java deserialization attacks if similar exceptions are seen in their WebLogic logs:

  • java.lang.ClassCastException: $Proxy56 cannot be cast to weblogic.rjvm.ClassTableEntr
  • java.io.InvalidObjectException: Unauthorized proxy deserialization

The problem with blacklisting the java.rmi.registry.Registry interface from the deserialization of the InboundMsgAbbrev instance is that attackers can simply replace the blacklisted interface with another interface. Deserialization gadget chains are like words in a Scrabble game. If a particular word cannot be used, another word can potentially be used to achieve the same goal.

On April 29, several security researchers, such as @pyn3rd, claimed that they have successfully bypassed WebLogic's Registry interface blacklisting by using different gadgets.

Remediation

As of now, Oracle has not released another patch update for this CVE. Despite the fact that researchers claim to have bypassed Oracle's April CPU fix for CVE-2018-2628, users should by no means be discouraged from installing the April CPU.

One way to harden the system against gadget chains is to use the latest JDK. The publicly available RCE POC exploits depend on older versions of the JDK. Upgrading the JDK is not a complete remediation of the issue but it is highly advisable to do since it deactivates the known POC exploits. Based on experiments, the minimum JDK versions that should be used are the ones that were released as part of the October 2015 CPU; namely: 6u111, 7u91, and 8u65. Note that it is recommended to install the JDK of the latest April 2018 CPU.

Another reason to upgrade the latest JDK is that it will allow you to use the JEP-290 Serialization Filtering mechanism. Using the process-wide global filter administrators can define their own whitelists for deserialization. WebLogic also has its own system properties that allow users to specify their own filters. Consult the Oracle documentation on how to set up the weblogic.oif.serialFilter property.

Security administrators could even consider blocking or filtering incoming connections to WebLogic's admin port, which, by default, is 7001.

The use of a Web Application Firewall could also be helpful but beware of the false positives since most of these solutions use pattern and signature matching. These heuristic approaches are never fully accurate and, in effect, they simply offer another way of performing filtering (blacklisting and/or whitelisting). This type of filtering is even less accurate compared to the JEP-290 Serialization Filtering mechanism of the JRE.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,cybersecurity ,web application security ,java security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}