Using Whitelisting to Remediate an RCE Vulnerability (CVE-2019-2729) in Oracle WebLogic
By: Sivathmican Sivakumaran (Vulnerability Researcher)
Oracle WebLogic has recently disclosed and patched remote-code-execution (RCE) vulnerabilities in its software, many of which were due to insecure deserialization. Oracle addressed the most recent vulnerability, CVE-2019-2729, in an out-of-band security patch on June 18, 2019. CVE-2019-2729 was assigned a CVSS score of 9.8, making it a critical vulnerability. This vulnerability is relatively easily exploitable, but requires Java Development Kit (JDK) 1.6. By default, WebLogic version 10.3.6 is shipped with JDK 1.6.
CVE-2019-2729 is essentially a bypass to CVE-2019-2725. This security issue, however, first surfaced in April 24 2017 as CVE-2017-3506. We took a closer look at CVE-2019-2729 to see how this class of vulnerability has been remediated — particularly via blacklisting or whitelisting — and why it has become a recurring security issue.
The Root Cause of CVE-2019-2725 and CVE-2019-2729
Context propagation in WebLogic servers makes it possible to carry application context information within a supported protocol. This information is carried via extensible markup language-serialized Java (XML) Objects. By default, the following URLs accepts context information via simple object access protocol (SOAP) requests:
The serialized XML data is contained within <work:WorkContext> tags of a SOAP request. The deserialization of the WorkContext information is implemented in the WorkContextXmlInputAdapter class, as shown in Figure 1.
As shown above, the XMLDecoder class is used to deserialize the context information. It should be noted that XMLDecoder is a class that should not be used with untrusted input. As demonstrated in other research efforts, it allows arbitrary method and constructor calls on arbitrary types. Due to the risks of using XMLDecoder and as a mitigation for CVE-2017-3506, a validate() function has been added to WorkContextXmlInputAdapter to filter out malicious tags prior to deserialization.
In the case of CVE-2019-2725, the validate() function prior to the vulnerability is shown in Figure 2.
As shown above, many tags required for RCE are effectively blacklisted. However, validate() fails to account for the <class> tag, which can allow the attacker to initiate any class with arbitrary constructor arguments. This could be used in multiple ways to achieve arbitrary code execution. An example is to initiate a UnitOfWorkChangeSet object, which accepts a byte array as a constructor argument.
As shown in Figure 3, UnitOfWorkChangeSet will indiscriminately deserialize this byte array upon initialization. A byte array with a crafted malicious serialized object, for instance, can be used to achieve arbitrary code execution. A Python snippet, shown in Figure 4, can then be used to generate attack traffic.
Figure 4. Python proof of concept (PoC) capable of generating attack traffic using the Jdk7u21 payload generated by ysoserial
Naturally, since the <class> tag is required for this exploit to work, Oracle proceeds to add this tag to the blacklist as the patch to CVE-2019-2725.
CVE-2019-2729: A Bypass of CVE-2019-2725
On the other hand, it turns out that the bypass for CVE-2019-2725 was not all that complicated. In fact, for JDK 1.6, the functionality of the <class> tag is effectively replaced by using a <array method=”forName”> tag. Simply replacing the <class> tag with the <array method=”forName”> tag effectively bypasses the blacklist.
The more interesting thing in this case is the way CVE-2019-2729 was patched: Oracle opted to use a whitelist instead of a blacklist. This is achieved via the newly introduced validateFormat() function with the whitelist rules being defined in WorkContextFormatInfo.
As can be seen in Figure 7, the <array> tag is still allowed by the whitelist, but it is only allowed to contain “class” attributes with “byte” value or a “length” attribute with any value.
Although at first it may not seem so black and white, generally using a whitelist to block malicious content is more effective than using a blacklist, especially when it comes to preventing bypasses that may reintroduce a security issue. System administrators, developers, and IT/security teams should always adopt best practices and mitigations, which include:
- Upgrading to a non-vulnerable version of the product using Oracle’s emergency patch
- Preventing access to vulnerable components by deleting war and wls-wsat.war then restarting the WebLogic service (prevents access to the vuln URLs).
- Restricting access to the affected communication port to trusted hosts only
- Proactively monitoring, detecting, and blocking malicious traffic through intrusion prevention systems
- Adding layers of security mechanisms such as virtual patching, which preempts exploitation of known, unknown, and undisclosed vulnerabilities; and application control, which prevents unauthorized or suspicious applications from executing
- 1009816 – Oracle Weblogic Server Remote Code Execution Vulnerability (CVE-2019-2729)
The Trend Micro Deep Discovery Inspector protects customers from threats that may exploit CVE-2019-2729 via this DDI rule:
- 2903: Possible Oracle Weblogic Remote Command Execution Exploit – HTTP (Request)
Trend Micro TippingPoint® Threat Protection System has posted a Customer Shield Writer (CSW) file for this vulnerability that are available for customers to download on TMC. The applicable rule is as follows:
- C1000001: HTTP: Oracle WebLogic Server Remote Code Execution Vulnerability
The post Using Whitelisting to Remediate an RCE Vulnerability (CVE-2019-2729) in Oracle WebLogic appeared first on .
Incoming search terms