Using Contrast to prevent the Weblogic Remote Code Execution (RCE) Deserialization Vulnerability - CVE-2019-2725

On April 17, 2019, Oracle released a Critical Patch Advisory with 254 patches. One of the vulnerabilities addressed was for CVE-2019-2725. The vulnerability associated with CVE-2019-2725 allows any anonymous attacker with internet access to submit a malicious request to the Oracle WebLogic Server component of Oracle Fusion Middleware that would result in remote code execution on the server.

The great news is our Contrast customers are protected from this vulnerability!

The vulnerability is due to untrusted deserialization. Mitre defines untrusted deserialization in CWE-502 as “The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.” In the case of theWebLogic vulnerability, there were no restrictions on the “gadget chains” allowing for self execution during the deserialization process. Gadget chains are a series of method invocations and in this case those method invocations are not properly restricted during the deserialization process.

This specific RCE allows the attacker to submit any system commands allowing the commands to run dynamically on the server side. The associated CVSS score is a 9.8 CRITICAL. The score is accurate as it allows full attacker control to write and execute system commands dynamically on the backendWebLogic server.

A sample attack payload for the WebLogic vulnerability looked like:

<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:wsa=\"http://www.w3.org/2005/08/addressing\" xmlns:asy=\"http://www.bea.com/async/AsyncResponseService\"> <soapenv:Header> <wsa:Action>xx</wsa:Action><wsa:RelatesTo>xx</wsa:RelatesTo><work:WorkContext xmlns:work=\"http://bea.com/2004/06/soap/workarea/\"><java version=\"1.4.0\" class=\"java.beans.XMLDecoder\">\r\n <void class=\"java.lang.ProcessBuilder\">\r\n <array class=\"java.lang.String\" length=\"3\">\r\n <void index=\"0\">\r\n <string>/bin/bash</string>\r\n </void>\r\n <void index=\"1\">\r\n <string>-c</string>\r\n </void>\r\n <void index=\"2\">\r\n <string>%s > %s</string>\r\n </void>\r\n </array>\r\n <void method=\"start\"/></void>\r\n </java>\r\n</work:WorkContext></soapenv:Header><soapenv:Body><asy:onAsyncDelivery/></soapenv:Body></soapenv:Envelope>" % (cmd,favicon_ico)

This above payload took an input command and then output the command to a file called “favicon.ico”. Once run, the attacker could anonymously browse to the favicon.ico file and see the results of the command they ran.

What does the exploit look like?

1. Attacker finds an Internet exposed WebLogic instance running.
2. Attacker crafts and sends a malicious SOAP payload to the WebLogic instance /_async/AsyncResponseService endpoint. Payloads can be found here.
3. The result is the system command evaluating on the WebLogic backend server.

Has it been fixed?

The vulnerable versions of Oracle WebLogic Server have been patched with the most recent Oracle Critical Patch Update (CPU). We highly recommend anyone using the Oracle WebLogic Server to apply the CPU.

How does Contrast Protect keep you safe?

Contrast Protect is equipped "out of the box" to detect and block the WebLogic untrusted deserialization vulnerability. To show how this works, our internal security researchers ran the vulnerable version of WebLogic in a Docker container and added our Contrast Protect agent by simply adding the following to the startWeblogic.sh script:

export JAVA_OPTIONS="$JAVA_OPTIONS -javaagent:/path/to/contrast.jar -Dcontrast.config.path=/path/to/contrast_security.yaml -Dcontrast.agent.java.standalone_app_name=weblogic"

Our researchers then started WebLogic and ran the exploit with “ps” while Contrast was just in monitor mode. The attack succeeded and we were able to browse to the “favicon.ico” file and see the resulting output from “ps.” The attack also showed up in the Contrast UI as “Exploited” and we were able to see the details of the attack. After this, our researchers turned Contrast Protect to “Block” mode and reran the attack, but this time with the “whoami” command (which would return the current user who is running the command). The request was sent but the favicon.ico file was not created and the command was not run. Contrast Protect successfully blocked the malicious request, and the Contrast UI provided the details. See the video of this sequence below:

To enable Block mode on untrusted deserialization, within the Contrast UI browse to “Policy Management” -> “Protect Rules” -> “Untrusted Deserialization”. Verify the environment running your WebLogic instance is in “Block” mode.

To learn more about managing Protect Rules, read the article in Contrast OpenDocs.