May 19, 2020 | Sree Sakamuri | Senior Solutions Architect
Addressing any security vulnerability warrants a holistic view to the problem, taking a surgical resolution approach that causes minimal disruption. While Oracle takes a reactive patching approach, Spinnaker Support applies a more holistic and proactive Seven-Point Security Solution.
We know that many organisations do not immediately uptake Oracle’s new CPU patches due to logistical, commercial, or business continuity factors. This practice can expose those organisations, making them vulnerable to an exploit. For example:
On April 14, 2020, Oracle released its second-quarter Critical Patch Update (CPU), which contained fixes for 399 security vulnerabilities. Only two weeks later, Oracle’s Director of Security Assurance released a blog post advising customers not to delay applying the recently released CPU patch.
Mention of the specific vulnerability identified as CVE-2020-2883 caught much attention. When Oracle releases an “emergency” blog post asking its customers to expedite a patch application, there is typically an undercurrent of concern.
CVE-2020-2883 comes under the category of RCE (Remote Code Execution) vulnerabilities. Using this method, an attacker has the ability to access a remote computer using an exposed vulnerability and run arbitrary malicious code to gain control of the system and paralyze the entire affected component / application. This can also lead to exposure of business-sensitive data to the attacker, a serious breach of confidentiality and integrity.
What Triggered Oracle to Publish the Blog Post?
One day after the CPU was released, the proof-of-concept code to exploit this vulnerability (CVE-2020-2883) was published on GitHub. Soon after, news of exploitation attempts was rife. We believe this is what prompted Oracle to publish the advisory blog post.
In addition to Oracle’s Apr-2020 CPU advisory post, the two trusted sources for reliable and accurate vulnerability information are the National Vulnerability Database (NVD) and Mitre. Mitre gave CVE-2020-2883 a CVSS base score of 9.8 out of 10, which is quite serious. The score is based on a combination of Confidentiality, Integrity, and Availability impacts.
In layman’s terms, the factors that make this CVE a nightmare for security and database/middleware administrators are:
- This vulnerability can be exploited remotely without the attacker needing an authentication.
- The attacker can succeed in exploiting this vulnerability without the need for specialized access conditions or extenuating circumstances.
- Once exploited, this can result in total loss of confidentiality, integrity, and availability of the components/applications affected.
The product affected by this vulnerability is Oracle WebLogic Server on versions 10.3.6, 12.1.3, 184.108.40.206, and 220.127.116.11, and the exposure is through T3 protocol, WebLogic’s proprietary RMI protocol. This is an important component of WebLogic’s communication with both internal and external services. This protocol is responsible for carrying traffic between the components of WebLogic Server’s ecosystem.
Like HTTP, T3 is Not Secure
Allowing HTTP traffic from external sources is not a security best practice. The same extends to T3. There is an SSL equivalent for T3 called T3S. T3S is the secure version of T3 that uses SSL certificates to encrypt the traffic, similar to HTTPS.
Although disabling any incoming T3 traffic from the Internet is the sensible thing to do, there are other areas of concern that need attention. For example, even with a firewall level block on such traffic, a T3 request can still sneak through under the wrapper of an HTTPS request to find its way into an organisation’s internal infrastructure.
Unfortunately, there is no silver bullet for issues like this. While organisations must follow industry best practices to bolster their security landscape, they also must maintain business continuity.
To completely ring-fence the vulnerability and mitigate it in a consistent manner, we need to take a multi-pronged strategy:
- HTTP/T3 traffic allowed from external sources? Disable it at firewall level.
- Use well–known certificate authorities (CA) like Thawte, Verisign, Entrust to obtain SSL certs to secure your environments using T3S/HTTPS.
- In addition to the firewall, create custom network channels to allow only HTTPS/T3S traffic from external sources.
- Disable tunneling in the defined network channels to avoid any T3 traffic sneaking under the HTTPS protocol.
- a. Select the Server -> Protocols -> Channels.
- Select the channel.
- Untick the “Tunneling Enabled” checkbox.
- Save and activate the changes.
- Restart the server.
- If HTTP/T3 cannot be disabled at the firewall level, a combination of IP whitelisting (firewall) together with WebLogic Connection Filters (weblogic.security.net.ConnectionFilterImpl) can be used to restrict/deny access from both external and internal sources.
Critical CVEs are never going away, and the best solutions are often already built into the software. In this case, we recommend using the less known – but powerful – features of WebLogic to further secure your environments. Some of these include:
- Perimeter Authentication (SAML and SPNEGO)
- Combination of Proxy, Firewall and Load Balancer
- Custom JEP 290 Deserialization Filter
Security and vulnerability management come standard with Spinnaker Support’s third-party software support. We help our customers with specific CVEs, critical issues, and long-term approaches to security. Learn more about our industry-leading Seven-Point Security Solution.