[R1] Oracle WebLogic ClassFilter.class ServerChannelInputStream Bypass Java Deserialization Remote Code Execution

On November 6, 2015 FoxGlove Security released an article titled “What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability” by Stephen Breen. The article detailed a variety of applications that were vulnerable to the deserialization of unauthenticated data that could lead to remote code execution. Breen built upon the tool “ysoserial” by Chris Frohoff and Gabriel Lawrence to demonstrate that he could gain execution on these various platforms using various Java gadgets (using Commons Collections, Groovy, or Spring) and the deserialization vulnerability.

On November 10, 2015 Oracle released a security advisory indicating that a CVE had been assigned (CVE-2015-4852) and that patches would be released. Oracle released patches to fix CVE-2015-4852 in WebLogic on November 25, 2015. Oracle WebLogic 12.1.3 with patch 21370953 (WLS Patch set update 12.1.3.0.5) and patch 22248372 (WebLogic Server CVE-2015-4852 Security Alert Patch) was installed and used in our tests.

The Fix

The patch introduced a “blacklist” of classes that would not be deserialized after the class had been determined. Specifically, this list, by default, consists of:

1. org.apache.commons.collections.functors*
2. com.sun.org.apache.xalan.internal.xsltc.trax*
3. javassist*
4. org.codehaus.groovy.runtime.ConvertedClosure
5. org.codehaus.groovy.runtime.ConversionHandler
6. org.codehaus.groovy.runtime.MethodClosure

The blacklist (ClassFilter.class) is applied in three locations where object deserialization occurs:

1. weblogic.rjvm.InboundMsgAbbrev.class::ServerChannelInputStream
2. weblogic.rjvm.MsgAbbrevInputStream.class
3. weblogic.iiop.Utils.class

The use of the blacklist on ServerChannelInputStream stops the exploit script released by Stephen Breen.

Circumventing the Blacklist

As mentioned above, the fix checks the class in the InputStream and determines if it is in the blacklist or not. However, if we could find an object that creates its own InputStream in its readObject or readExternal that is not ServerChannelInputStream or MsgAbbrevInputStream and calls readObject() than we can use one of the ysoserial gadgets to gain code execution. It just so happens that WebLogic itself has such an object. In the readExternal() function of weblogic.jms.common.StreamMessageImpl, an ObjectInputStream is created based off of the InputStream internal to the member object “payload” (type of PayloadStream). Shortly after the InputStream creation readObject() is called. This leads down the path of exploitation where an attacker can craft a PayloadStream to gain code execution.

Note that CVE-2015-4829 was assigned via email during the disclosure process, but the public Oracle advisory on April 19, 2016 assigned CVE-2016-0638 instead.