Vulnerability Description
On January 15, 2020, Oracle released Critical Patch Update (CPU) for January 2020 that fixes 334 vulnerabilities of different risk levels, including a remote code execution vulnerability (CVE-2020-2555) with the CVSS score of 9.8 in the deserialization by Oracle Coherence deserialization. This vulnerability allows an unauthenticated attacker to launch attacks via a crafted T3 request. A successful exploitation of this vulnerability could lead to arbitrary code execution on the target host. Products that use Oracle Coherence are affected by this vulnerability. The installation package of WebLogic Server 11g Release 10.3.4 and later has the Oracle Coherence library integrated by default.
Coherence is a key component for Oracle to implement highly reliable and scalable cluster computing. It provides replicated and distributed (partitioned) data management and caching services on top of a reliable, highly scalable peer-to-peer clustering protocol. Currently, the proof of concept (PoC) of this vulnerability is already publicly available. Affected users should apply the related security update for protection. The following is a screenshot of successful vulnerability reproduction.
For details of this vulnerability, visit the following link:
https://www.oracle.com/security-alerts/cpujan2020.html
https://docs.oracle.com/cd/E18686_01/coh.37/e18692/activecache.htm#COHTU725
Scope of Impact
Affected Versions
- Oracle Coherence 3.7.1.17
- Oracle Coherence 12.1.3.0.0
- Oracle Coherence 12.2.1.3.0
- Oracle Coherence 12.2.1.4.0
Vulnerability Analysis
Oracle’s this official security update fixes the deserialization issue caused by the LimitFilter class.
According to the LimitFilter code analysis, the extract method in ValueExtractor is invoked by the toString method.
Invoking the extract method of the ReflectionExtractor class could reflect the command by passing a parameter. This is similar to the Gadget chain of CommonsCollections1.
Mitigation
-
Patch Installation
Currently, Oracle has released security updates to fix this vulnerability in system versions supported by Oracle. Affected users should apply these updates as soon as possible for protection. These updates are available at the following link:
https://support.oracle.com/rs?type=doc&id=2602410.1
-
Workarounds
Users, which cannot apply security updates currently, can block attacks based on this vulnerability in the T3 protocol, by controlling T3 access. WebLogic Server provides a default connection filter named weblogic.security.net.ConnectionFilterImpl. This filter accepts all inbound connections. It is advisable to configure a rule through this filter to control T3 and T3S access.
- Access the administration console of WebLogic Server. Click base_domain in the left pane and then click the Security and Filter tabs successively to open the filter configuration page.
- Type security.net.ConnectionFilterImpl in the Connection Filter field. Configure connection filter rules that suit the actual situation of enterprises.
| 127.0.0.1 * * allow t3 t3s
IP * * allow t3 t3s IP * * allow t3 t3s * * * deny t3 t3s |
| Connection filter rules should be specified in the format of “target localAddress localPort action protocols”, where
l target indicates one or more servers to be filtered. l localAddress specifies the host address of the server. (An asterisk (*) indicates all local IP addresses.)) l localPort specifies the port that the server is listening on. (An asterisk (*) indicates all ports available on the server.) l action specifies the action to be taken. (The value must be allow or deny.)) l protocols specifies the protocols to be filtered. (The value must be http, https, t3, t3s, giop, giops, dcom, and/or ftp.) If no protocol is specified, all protocols will be filtered. |
- Restart the WebLogic service if such rules fail to take effect after you save them. Restarting this service may cause business interruptions, and therefore users should evaluate the risk before performing this operation. Here the Windows environment is used as an example to describe how to restart the WebLogic service:
- Access the bin directory under the directory of the domain and run the stopWebLogic.cmd file in the Windows system (or stopWebLogic.sh in the Linux system) to stop the running of the WebLogic service
- After the service termination script is executed, run startWebLogic.cmd or startWebLogic.sh to start the WebLogic service.
Statement
This advisory is only used to describe a potential risk. NSFOCUS does not provide any commitment or promise on this advisory. NSFOCUS and the author will not bear any liability for any direct and/or indirect consequences and losses caused by transmitting and/or using this advisory. NSFOCUS reserves all the rights to modify and interpret this advisory. Please include this statement paragraph when reproducing or transferring this advisory. Do not modify this advisory, add/delete any information to/from it, or use this advisory for commercial purposes without permission from NSFOCUS.
About NSFOCUS
NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks. The company’s Intelligent Hybrid Security strategy utilizes both cloud and on-premises security platforms, built on a foundation of real-time global threat intelligence, to provide multi-layered, unified and dynamic protection against advanced cyber attacks.
NSFOCUS works with Fortune Global 500 companies, including four of the world’s five largest financial institutions, organizations in insurance, retail, healthcare, critical infrastructure industries as well as government agencies. NSFOCUS has technology and channel partners in more than 60 countries, is a member of both the Microsoft Active Protections Program (MAPP), and the Cloud Security Alliance (CSA).
A wholly owned subsidiary of NSFOCUS Information Technology Co. Ltd., the company has operations in the Americas, Europe, the Middle East and Asia Pacific.
