Log4Shell : A 9D Moment in The IT Industry

15 Dec Log4Shell : A 9D Moment in The IT Industry

It has been 4 years and almost 3 months that on September 19th (19s as it is commonly known due to the day 19th and S of September) of 2017 at 1:15 PM CT México City got hit by one of the deathliest earthquake. México City is still in the process of removing and fixing buildings that were damaged by that earthquake.

On an analogy of an earthquake, the IT industry on Friday December 9th,2021 ( 9D) got shook by the security vulnerability with the given the descriptor “Log4Shell”. It is being called one of the most susceptible security flaws of the last decade. With the lasting outcome of this vulnerability to last for years, Tenable mentions that “attackers will go after the low-hanging fruit exposed by the vulnerability, will evolve over time to take the form of more complex attacks“.

Understanding the Security Vulnerability

Apache Log4j is a Java-based open source logging utility. It is part of the Apache Logging Services and Log4j is one of several Java logging frameworks. Log4j is used in everything from online games to enterprise software and cloud data centres. Log4Shell was identified in Microsoft’s Minecraft and the Log4j team was made aware of this security vulnerability, CVE-2021-45046.

The vulnerability makes it possible for any attacker to be able to inject text into log messages or log message parameters into server logs that load code from a remote server. The targeted server will then execute that code via calls to the Java Naming and Directory Interface (JNDI). JNDI interfaces with a number of network services

• DNS (Domain Name Service)
• LDAP (Lightweight Directory Access Protocol )
• LDAPS (Secure LDAP )
• RMI (Remote Method Invocation )

Log4Shell, brings in to light two practices of concern:

1. How organizations capture and protect massive troves of log data
2. The use of open-source code libraries as the building blocks for enterprise applications.

What can I do to limit my exposure

Apache release Log4j 2.16.0. This version disables by default the Java library’s primarily exploitable functionality: JNDI message lookups, it also disables all JNDI support by default, and removes message lookup handling entirely, hopefully preventing further exploitation. Log4j 2.16.0 requires Java 8. For that reason, organizations that use Java 7 will need to upgrade to Java 8 before being able to update to the patched version of Log4j.

Apache advises that if patching is not immediately possible, there are three mitigation routes that can be taken to thwart attempts to exploit this vulnerability:

What can I do to limit my exposure (For My Oracle Products)

Oracle released  Oracle Security Alert Advisory – CVE-2021-44228 and MOS note Apache Log4j Security Alert CVE-2021-44228 Products and Versions (Doc ID 2827611.1), where it details the impact of the security vulnerability to its products and the patches that are available to them. There are about 160 products which are either under investigation or with a patch already available, I do want to highlight that the Oracle Database is not affected by this CVE, but products like EM,TFA,EBS, API Gateway and ODI are. As this MOS note is evolving as vulnerabilities are identified and patched, my recommendation would be that you monitor it frquently and that you apply the patch to your environment as soon as possible.

I also want to highlight what the MOS note mentions regarding OCI

“The Oracle Cloud operations and security teams are evaluating this Security Alert as well as all relevant third-party fixes as they become available. They will apply the relevant patches in accordance with applicable change management processes. This MOS article will be updated to reflect the application of the required patches in the Oracle clouds.”

Conclusion

It is estimated that Log4j has about 400,000 github requests, meaning that this logging feature is included in a high number of web applications and used by a variety of cloud services like Apple,Amazon and Google (documented in Log4jAttackSurface), and similar to the earthquake in México City the full scope and impact of this vulnerability will be seen throughout the years. The biggest recommendation is to patch or minimize the vulnerability of your products that use Log4j as soon as possible so that you won’t be the low hanging fruit for Evil Bob to hack your environment.