One of the many issues that should have been addressed by Oracle’s Critical Patch Update for April 2018 was a fix for a flaw affecting versions 10.3.6.0, 220.127.116.11, 18.104.22.168 and 22.214.171.124 of the Oracle WebLogic Server (WLS) Java Enterprise Edition (EE) application server. This vulnerability, which has been assigned CVE-2018-2628 (CVSS Base Score: 9.8), is a critical issue that can be exploited by an attacker with network access via the T3 protocol. The T3 protocol is used to transport information between WebLogic servers and other types of Java programs. However, the patch was unsuccessful and this issue can still be exploited.
With the recent discovery of the Oracle vulnerability, attackers are scanning the internet for Oracle WLS installations on Transmission Control Protocol (TCP) port 7001 to exploit. Once discovered, a remote attacker can target an Oracle WLS system and may execute arbitrary commands.
This vulnerability is nothing new. WebLogic has been affected by a number of Java deserialization vulnerabilities since FoxGlove Security published their wonderful article, “What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.” In fact, Tenable® has released five different research advisories regarding deserialization attacks over T3:
WebLogic’s T3 protocol relies on serialized Java objects for communication, making it particularly vulnerable to this bug class. These vulnerabilities arise when a program attempts to use data that was serialized (converted to another format for transportation). When a program deserializes untrusted serialized Java objects, the serialized objects can control code flow and eventually take over execution entirely. Oracle hasn’t done themselves any favors by choosing to “fix” these attacks by creating a list of objects that can’t be deserialized (also known as a blacklist).
Before you panic though, let’s look at what CVE-2018-2628 actually is. This vulnerability is a blacklist bypass. That means an attacker can sidestep the blacklist to deserialize any object on the target classpath. And that’s the catch. Oracle has done a good job of mitigating all the publicly disclosed Java deserialization RCE gadgets. Therefore, even though Oracle has released an ineffective patch for CVE-2018-2628, a patched server may not be vulnerable to a remote code execution (RCE) in all cases.
For example, take a look at the proof of concept on exploit DB. When you run the exploit against 126.96.36.199, you’ll find this output in the WebLogic log:
<Apr 30, 2018 8:23:49,869 AM PDT> <Warning> <RMI> <BEA-080003> <A RuntimeException was generated by the RMI server: weblogic.common.internal.RMIBootServiceImpl.authenticate(Lweblogic.security.acl.UserInfo;)
java.lang.ClassCastException: com.sun.proxy.$Proxy160 cannot be cast to weblogic.rjvm.ClassTableEntry.
java.lang.ClassCastException: com.sun.proxy.$Proxy160 cannot be cast to weblogic.rjvm.ClassTableEntry
Truncated. see log file for complete stacktrace
This log shows that the initial connect back was successfully deserialized. However, because ysoserial (a proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization) is configured to execute CommonsCollections1, the attacker can’t achieve RCE because the object that allowed RCE in the past can no longer be serialized or deserialized.
Oracle removed the vulnerable Apache Commons Collections from the classpath in 2017.
Similarly, there have been tweets about using the ysoserial payload Jdk7u21, which is a deserialization endpoint in the Java runtime environment. However, that was patched in Java 7 in 2013 and in Java 8 in 2014. If you’re running Java versions that old then, yeah, you’ve got problems and this exploit may be an issue.
We haven’t seen reports of servers being attacked using the vulnerabilities identified in CVE-2018-2628 yet. But the attention this vulnerability is getting increases the chances that we’ll see attacks soon. This is an easily exploitable vulnerability that requires no authentication. Successful attacks of this vulnerability can result in takeover of Oracle WLS. Prevalence could be high if running one of the affected versions. It should be noted that Oracle WebLogic servers have been a target in the past. Previously, a vulnerability identified by CVE-2017-10271 was used by threat actors to deliver cryptocurrency miners.
Urgently required actions
Oracle has issued a fix as part of the April 2018 Critical Patch Update that was supposed to address this concern. Unfortunately, it fails to do so. While the patch update misses the mark, organizations should still apply the update, as many other security concerns are addressed.
In the meantime, vulnerable systems should be identified and the risk should be managed according to your organization’s security policies. Tenable offers several methods to assist organizations in detecting this vulnerability.
Identifying affected systems
This Nessus® plugin detects if the version of Oracle WLS installed on the remote host is affected by multiple vulnerabilities:
The following Nessus plugins are for all T3 deserialization attacks:
Tenable.io® Container Security also detects the issue, and will detect affected version of WebLogic automatically.
Get more information
- Oracle Critical Patch Update Advisory – April 2018
- Learn more about Tenable.io, the first Cyber Exposure platform for holistic management of your modern attack surface
- Get a free 60-day trial of Tenable.io Vulnerability Management
Special thanks to Jacob Baines for contributing to this blog post.
*** This is a Security Bloggers Network syndicated blog from Tenable Blog authored by Josef Weiss. Read the original post at: http://feedproxy.google.com/~r/tenable/qaXL/~3/zQbN7SMioM4/critical-oracle-weblogic-server-flaw-still-not-patched